On Mon, Feb 10, 2020 at 08:45:28AM -0700, Jim Fehlig wrote:
On 2/3/20 5:43 AM, Daniel P. Berrangé wrote:
I'm (re-)sending this patch series on behalf of Shaju Abraham <shaju.abraham@nutanix.com> who has tried to send this several times already.
Red Hat's email infrastructure is broken, accepting the mails and then failing to deliver them to mailman, or any other Red Hat address. Unfortunately it means that while we can send comments back to Shaju on this thread, subscribers will then probably fail to see any responses Shaju tries to give :-( To say this is bad is an understatement. I have yet another ticket open tracking & escalating this awful problem but can't give any ETA on a fix :-(
Anyway, with that out of the way, here's Shaju's original cover letter below....
1) What is this patch series about?
Local live migration of a VM is about Live migrating a VM instance with in the same node. Traditional libvirt live migration involves migrating the VM from a source node to a remote node. The local migrations are forbidden in Libvirt for a myriad of reasons. This patch series is to enable local migration in Libvirt.
2) Why Local Migration is important?
The ability to Live migrate a VM locally paves the way for hypervisor upgrades without shutting down the VM. For example to upgrade qemu after a security upgrade, we can locally migrate the VM to the new qemu instance. By utilising capabilities like "bypass-shared-memory" in qemu, the hypervisor upgrades are faster.
3) Why is local migration difficult in Libvirt?
Libvirt always assumes that the name/UUID pair is unique with in a node. During local migration there will be two different VMs with the same UUID/name pair which will confuse the management stack. There are other path variables like monitor path, config paths etc which assumes that the name/UUID pair is unique. So during migration the same monitor will be used by both the source and the target. We cannot assign a temporary UUID to the target VM, since UUID is a part of the machine ABI which is immutable. To decouple the dependecy on UUID/name, a new field (the domain id) is included in all the PATHs that Libvirt uses. This will ensure that all instances of the VM gets a unique PATH.
Since localhost migration is difficult, and there will likely be some growing pains until the feature is fully baked, perhaps it is best to have a knob for enabling/disabling it. The namespace feature suffered similar growing pains and having the ability to disable it in qemu.conf proved quite handy at times.
Probably an API flag VIR_MIGRATE_SAME_HOST is sufficient, as that shows an opt-in on the part of the person/thing that initiates it. I think we'd want this flag forever, regardless of whether its experimental or production quality, because there are special concerns about clashing host files/resources. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|