Search results

Hi, Could you give more information please? ~# lsblk ~# fdisk -l ~# pveversion -v Thnk you.

Could you please post your: versions: pveversion -v network: /etc/network/interfaces vm config: /etc/pve/qemu-server/ .conf Thanks.

Example script is in /usr/share/doc/pve-manager/examples/vzdump-hook-script.pl cp /usr/share/doc/pve-manager/examples/vzdump-hook-script.pl /root/bin/vzdump-hook-script.pl To enable echo "script: /root/bin/vzdump-hook-script.pl" >> /etc/vzdump.conf My script making deltas from full backup files...

I've achieved my differential backups just by running xdelta3 from vzdump-hook-script.pl. In that case I don't have to modify gui and still keep it simple.

Might be not a perfect design but here is my plan: [ switch0 (cluster talks) ] vmbr0 | | | | | | | | (bonded links) [ mox1 ] [ mox2 ] [ mox3 ] [ mox4 ] vmbr1 | | | |...

Pair them: first bond for cluster and second bond for storage.

You can try bridge aliases instead: ~# ifconfig vmbr0:0 192.99.198.149 netmask 255.255.255.252 && ping 192.99.198.150 or ~# ifconfig vmbr0:0 192.99.198.150 netmask 255.255.255.252 && ping 192.99.198.149 Also ping and tracerute 192.99.198.149 and 192.99.198.150 from outside the datacenter...

Not just strange, it's nt working. Might be just typo. I think you shold contact them to clarify. If you mind to have one more try: setup laptop with your public ip and try to connect. I remember in my experience the most complicated looking problems was just because of cable not sitting...

Hi, There is like a draft plan: 1) Just in case make backup of your production cluster eg. tar czf pvebackup.tgz /etc/pve && tar czf rootbackup.tgz /root 2) Disconnect new box from the network. 3) Single mode or you can perform normal boot at least if restored node is completely diconnected...

Thanks for all above. Just in case please check logs if there are something interesting in your cisco switch. People report on some strange issues with LACP bonding on different types of switches. You can also monitor how your process is going. Fot little piece of knowledge: I use wonderful...

Hi Raj, What type is you nic teaming? Please post your /etc/network/interfaces there. Just an idea: Can we also confirm that this is not networking ussue. eg. if you have any spare local storage space - just try to backup suspicious vm to that local storage and avoiding use network. What...

http://www.tuxgraphics.org/toolbox/network_address_calculator_add.html This calc might be handy for you. You can also learn and practice in the theory there http://www.linglom.com/networking/how-to-find-subnet-number-ip-addresses-in-the-subnet-in-a-few-seconds/

Nope. I guess gateway should be 192.99.198.150 as this is the only one usable address left 192.99.198.151 will be the broadcast I hope it helps. If that doesn't work - try to run a brand new vm with simple network setup and test it from there.

GlusterFS is just easier to setup for test. It can work on top of the existing filesystem which is handy if you don't have extra disk space or hardware resources for testing. Both containers and qemu images are happy to live on Gluster. No issues with Ceph and moreover I think if you...

I am guessing it might be something with "bond_mode 802.3ad" (LACP) Try to change it to something more simple like "bond_mode active-backup" to see if that's the ussue. And if it is - the next step might be to check other things. eg. Connect hosts directly to see if that not a problem with...

Hi Mac, Please show your /etc/network/interfaces Cheers.

I think you should try a simple GlusterFS setup first. It's much easier. Gluster has option for geo-replication and it well documented. See how it goes - then try ceph. Re your idea of having HA across the Internet: I am afraid it will be significant difference between your local and remote...