Move image

[Norberto Iannicelli]

Good night people.
I'm looking for a way to migrate 400vm+ from one cluster to another and unfortunately proxmox doesn't have a native tool for that. (cluster 01 for cluster02).
I found this tool, has anyone used it?
https://pypi.org/project/proxmove/

Could I for example move the disk image of a ".raw" vm from one cluster to another with the vm turned on? That way I create the vm again in the new cluster and point to the disk image that was transferred. I want to transfer with as little downtime as possible so as not to disturb the user.

I accept suggestions, thank you all.

 

[t.lamprecht]

I'm looking for a way to migrate 400vm+ from one cluster to another and unfortunately proxmox doesn't have a native tool for that.

Backup locally and then restore remotely natively available. If they're in a LAN you can also (temporarily) cluster nodes.
Native remote migration not using the former too is in the works:
https://lists.proxmox.com/pipermail/pve-devel/2021-November/050664.html

 

[Norberto Iannicelli]

Backup locally and then restore remotely natively available. If they're in a LAN you can also (temporarily) cluster nodes.
Native remote migration not using the former too is in the works:
https://lists.proxmox.com/pipermail/pve-devel/2021-November/050664.html

Good morning, thanks for the reply.
Unfortunately they are not on the same lan, they are even in different regions.
Canada >> Brazil.

Can I move the .raw file with the vm turned on?

 

[t.lamprecht]

Can I move the .raw file with the vm turned on?

No, that will cause you trouble in general as the VM still can actively write to it.

While backup + restore is the safest method you could try doing something like the following for a method with a bit less VM downtime:
Use rsync (need to ensure you got the right CLI options) or a tool like bdsync for a first initial sync while the VM is still running, then stop the VM and do the final sync to ensure you get a consistent and bootable image on the remote.

Whatever you decide to do, I'd heavily recommend testing it on a smaller test VM first, to ensure all is working out as planned.

 

[Norberto Iannicelli]

No, that will cause you trouble in general as the VM still can actively write to it.

While backup + restore is the safest method you could try doing something like the following for a method with a bit less VM downtime:
Use rsync (need to ensure you got the right CLI options) or a tool like bdsync for a first initial sync while the VM is still running, then stop the VM and do the final sync to ensure you get a consistent and bootable image on the remote.

Whatever you decide to do, I'd heavily recommend testing it on a smaller test VM first, to ensure all is working out as planned.

I really appreciate it, this solution seems to be interesting.
The .raw file has 30GB, but the user only uses 10GB, in which case will 30GB or 10GB be transferred?

I'll do it this way, send the .raw with the vm turned on, then hang up and do a bdsync, that way it will actually only be able to send what was changed?

bdsync or rsync do the same function?

 

[hvisage]

if you are on ZFS volumes (not .raw), (and you have FSTRIM'd the data inside the VM) then zrep/syncoid is also and option to only sync differences

(In theory the whole node's ZFS storage could be cloned that way - just not that on the rpool )

 

[Norberto Iannicelli]

se você estiver em volumes ZFS (não .raw), (e você tiver FSTRIM'd os dados dentro da VM), então zrep / syncoid também é uma opção para sincronizar apenas as diferenças

(Em teoria, todo o armazenamento ZFS do nó poderia ser clonado dessa forma - não apenas no rpool )

Eles não estão em zfs, parte está em um ceph remoto e outra pasta está em discos locais. Estou procurando ferramentas eficientes, o bdsync parece ser uma boa opção.