XCP: Allow storage Xenmotion to be used for backups (if up, source stays up, but leave target down)
Currently, storage Xenmotion allows either a shut-down VM and its storage to be copied to a new location or live storage Xenmotion takes a running VM + storage and relocates it to a new server/pool/storage location and runs it there and stops the source. Why not also allow the source VM to continue running or the shut down VM to stay shut down and instead of migrating, allow a total copy operation and leave the target VM/storage shut down so as to create a perfect backup snapshot? For disaster recovery or keeping a perfect clone handy of a VM+storage, this would be ideal and involve very little code change to what already exists to accomplish.
Absolutely. The "cheat" given by A. Cooper below is not a very friendly way to have to do this, plus a halted VM would need to be started up to get this mechanism to work.
Any reasonable combination should be possible, in particular, halted to running on the target, halted to halted on the target, and running to halted on the target.
Today storage xenmotion is a Problem if the Operation Fails - we had some VM's which have problems after migration (NTFS Errors, NLA Errors...) - so it would be useful to have the source VM's still there if something failed to have a fall back - if everything goes right we can delete the source VM's!
Has this not been considered yet for a future enhancement? It seems to have garnered quite a bit of interest (and votes).
A. Cooper of Citrix reports on the Citrix forum this trick for getting a (soon to be) shut-down VM to storage Xenmotion: "If you start the migration at the same time as issuing `reboot` in the guest, it will shut down and stay shut down until the migration is complete. Migrating a shut down VM is safe, and does even work when migrating a VM between Intel and AMD cpus". This has to be done via the CLI and requires the "force" option. So, the framework is pretty much already provided for most of the means of creating an off-to-off move, though not with the source already off to begin with. We therefore have on-to-on (shutting down the initial instance when done) and on-to-off (kludged, with the initial instance off at the end), and are missing primarily the means to perform an on-to-off (leaving the source on and the target off), as well as a off-to-on (not requiring to first force the VM to run to pull it off and resulting in a running VM target) migration, as well as a pure off-to-off migration (the VM stays down at all times both on the source and target).
Have recently tried migrating a shut-down VM this way and it appears to not work at all, and apparently requires the VM to be running to initiate the request. Why on earth, why? There is a "--live" (migrate without shutting the VM down) option in the CLI, so why would one not want to be able to migrate a shut-down VM and either bring the copied version up live on the new destination or leave it down, as well, in preparation for bringing up at a desired time? All these seem like little flags that can trigger what state to leave the VM in for both source and target VMs. Please consider broadening the scope of this extremely useful and powerful feature to offer a little more flexibility.
Lars, your point about a migration failing is very well taken, especially with really large VDIs, this can sometimes take hours (and, yes, do sometimes fail). Also, if you want to leave your development VM on your QA server yet want to run it elsewhere without losing the original location, you really do not want to delete your original copy.
Absolutely agree. I've needed this feature many times. In the event of a live migration failing (this happens) being able to move a shut down guest to new storage/server/pool would be worth gold.