Footnote on the thread, for what it might be worth.
- Zero Downtime live migration here in proxmox, is not any less or more downtime than you might see with Xen, VMware, etc. There is always ~some millisecond level 'cut' in operation when <old is paused> and <new is lit up>. Generally the delay is such that you may, or may not, notice it if you are constantly pinging the target host being live migrated.
As always, live-migration is contingent on the simple reality that
-- activity inside the VM being migrated, generates RAM deltas on the source host. And possibly deltas on attached disk(s) as well (depends if you are using shared-san-style disk; or not).
-- those changes need to be pushed from Source>>Target before the live-migrate-cut-over can happen
-- if the rate of change inside the VM being migrated - exceeds the bandwidth you have between the 2 physical servers who are the source, target -- then your live-migration will 'stretch out' -- source machine will stay online; deltas will be copied; incrementally / iteratively ; until the target 'catches up' with the source.
So: If your source machine "Is too damn busy" when compared to "available bandwidth for pushing the deltas" - then the live migration will in fact never happen. The cut-over time just keeps getting pushed ahead into the future. I've seen this happen on various environments (OpenStack KVM, Proxmox, etc) - it is a matter of not trying to do the impossible. Since - it is impossible.
Note that proxmox, as most KVM implementations now have this feature - allows 'live migration' with non-shared storage. The catch is that - you must wait patiently for disk blocks to be copied first from source to target. Some people dislike waiting so only use shared-storage when they do live migrations. But .. it is doable .. just requires patience, depending on speed of link between proxmox nodes; and the size of the VM images being pushed through the pipe.
Tim
