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@xxxxxxxxxxx> 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 :|
