Things to consider for replicating two machines with rsync in a Proxmox Cluster.
- Thread starter TheSover
- Start date
Two-node clusters (without a QDevice) are problematic. Promox supports efficient ZFS replication between (all) nodes. Maybe you can describe your final goal for people to advise you on pros and cons?
Last edited:
Yes , We need to know the pros and cons for doing that, nowadays we are trying to make an script that makes a rsync of the disk and when you want to turn on the VM or container use querys like that:
For container:
pct create 889 /var/lib/vz/template/cache/debian-12-standard_12.2-1_amd64.tar.zst --hostname CT888 --cores 1 --memory 512 --rootfs local:889/vm-889-disk-0.raw --net0 name=eth0,bridge=vmbr0,hwaddr=BC:24:11:62:71:43 --password="prova"
For VM:
qm create 888 --name Kerio-Connect-Rocky --memory 2048 --scsi0 /var/lib/vz/images/888/vm-888-disk-0.qcow2 --sockets 1 --cores 2 --cpu 'x86-64-v2-AES' --scsihw virtio-scsi-single --net0 virtio=22:7B:10:FA:A7:02,bridge=vmbr0 --ostype l26 --ide2 none,media=cdrom
If the ID doesn't exist , we can do it safety ? Could you advise us on things we might encounter?
For container:
pct create 889 /var/lib/vz/template/cache/debian-12-standard_12.2-1_amd64.tar.zst --hostname CT888 --cores 1 --memory 512 --rootfs local:889/vm-889-disk-0.raw --net0 name=eth0,bridge=vmbr0,hwaddr=BC:24:11:62:71:43 --password="prova"
For VM:
qm create 888 --name Kerio-Connect-Rocky --memory 2048 --scsi0 /var/lib/vz/images/888/vm-888-disk-0.qcow2 --sockets 1 --cores 2 --cpu 'x86-64-v2-AES' --scsihw virtio-scsi-single --net0 virtio=22:7B:10:FA:A7:02,bridge=vmbr0 --ostype l26 --ide2 none,media=cdrom
If the ID doesn't exist , we can do it safety ? Could you advise us on things we might encounter?
@TheSover why not use the traditional storage replication instead? In that case when you migrate your vm to the other node, it only transfer the delta. Correct me if I am wrong but when you use rsync and then try to migrate the vm afterward then it does not know anything about the disks on the other node and it will then create new disks and the transfer it much longer as it copies the contents all over. The other way would then be copy the vm config and recreate it on the other node when you want to migrate it. Again, this is my thinking when using rsync. Never tested it only tested storage replication and pve-zsync
We cannot use the ZFS system because the disks we have are not fast enough, and as a result, the performance of virtual machines and containers decreases drastically. I understand that pve-zsync can only be used with the ZFS format; that's why we want to create a replication between nodes in a cluster using scripting. It is true that we will have a new ID, but it is entirely acceptable. We have confirmed that rsync can be done on-the-fly and that it only transfers the differences in subsequent transfers after the initial one. Any advice is welcome. If it can be done with pve-zsync without ZFS and is more optimized, we will use it
Running rsync is way slower than ZFS replication and it's not online, so you need to have to stop the VM in order to get a consistent virtual disk rsync job, otherwise you risk corruption. ZFS does not implicitly. In my book, those downsides are MUCH bigger than a little bit slow ZFS in comparison to ext4 or whatever you run now.