Re: [libvirt PATCH 0/6] Introduce Local Migration Support in Libvirt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux