Why do you think this is interesting when doing local migration in comparison to the other migration situations in proxmox?
Is this migration possible only with a clustered proxmox installation?
If yes, there is no need to choose the network, as the cluster network is mandatory
If no (and I hope so), users could have more than 1 networks on the server and can choose which is best for the transfer. You could also migrate 2 VMs at once by using two different networks. (this could also be usefull in case of cluster network. The first migration is running through the cluster net, the second migration will run on a different network, in parallel)
If yes, there is no need to choose the network, as the cluster network is mandatory
If no (and I hope so), users could have more than 1 networks on the server and can choose which is best for the transfer. You could also migrate 2 VMs at once by using two different networks. (this could also be usefull in case of cluster network. The first migration is running through the cluster net, the second migration will run on a different network, in parallel)
You will not be able to migrate if you don't have a cluster. Migrate to a non-pve node or a pve-node not part of the cluster is not possible.
Totally agree
Maybe someone could add a new network interface to use as 'migration' network without reconfiguring the whole cluster by changing the cluster network. Is much more easier to add a new network card than reconfigure a cluster on a working environment
This will be the same migrating, so I need to delete old vm, I mean vm configuration from source node.
But I can keep disks.
The problem is how to manage old disks ? (if we want to remove them later).
Currently we can see them in storage management, but we don't have a feature yet to remove them from gui or api.
(for a qcow2 it's pretty simple to remove them manually, but for users with zfs or lvm, an api could be usefull)
Or someone could have configured the cluster network to be on a 100mbit connection (without shared storage, 100mbit would be enough) keeping free the gigabit ports for something else (probably i'll do the same if no shared storage is needed, there is no need to waste a gigabit connection for a corosync "ping"). In this case, forcing migration through the gigabit port could be desiderable.
I can't help you, as I'm new to proxmox, but I know this for sure: DO NOT destroy the old VM. I don't know how, but don't destroy it.
Or you have to check for EVERYTHING and catch any kind of exception that could arise that could block the migration and at the same time destroy the old VM.
As wrote, I had a very bad experience with XenServer. Don't replicate the same in PVE. Rename the VM, delete the VM configuration (but keep a backup file somewhere) or anything else. Do what you want, but do not delete that.
A small stupid uncatched bug could lead to big, big troubles.
there already is non-live migration code that works with local disks - it works exactly like spirit proposes, but offline:
- copy disks that need copying
- move VM (i.e., config file) to target node
- delete source disks
Of course, in case something goes wrong, you don't delete the source disks but the copies on the target node, and the VM stays on the source node. With this order, it's quite easy to make it safe - at the point where the deletion occurs, everything has been copied/moved to the target node. Of course, shared storage makes it even safer, as there is no need to copy/move anything besides the config file, which is only a logical move (it's already synced to all cluster nodes anyway).
Ho do you check that disk transfer is done properly? What happens if VM doesn't boot on the new node due to a disk corruption (but transfer was OK) and you deleted the source image ?
The drive-mirror command will fail in case of error. (network, or destination storage io error) So it should be safe.
This is exactly the same method than "move disk" option, but across the network.
I never have seen error with this method, and I have migrated more than 1000 disks this year
I understand. But even XenServer (the commercial one) should not fail, but I did ONE migration and that single migration suddenly failed.
I think that you should, at minimum, delete source disk if and only if, everything was OK: disk mirror, disk transfer, VM power on, ......
Is just to be on the safe side, nothing more.
I think that you should, at minimum, delete source disk if and only if, everything was OK: disk mirror, disk transfer, VM power on, ......
Is just to be on the safe side, nothing more.
Sounds safe enough to me.
So are you going to provide a patch to Proxmox that gets into the test repository, or how is this going to work?
I will be more than happy to test.
Last edited:
I think you'd need some code to handle this. As fabian stated, leaving the original disk is potentially dangerous, so the process needs to rename the disk as soon as the VM has moved (perhaps append .decommissioned to the filename.) Part of the error handling needs to determine if the VM is up normally on its new node and destroy the renamed disk, or rename it back and switch the VM to its original node on fault.
I have no use for this functionality, but I am curious how you'll solve this.