[libvirt] [PATCH] RFC: Support QEMU live uprgade

Daniel P. Berrange berrange at redhat.com
Wed Nov 13 12:59:57 UTC 2013


On Wed, Nov 13, 2013 at 05:56:44AM -0700, Eric Blake wrote:
> On 11/13/2013 12:42 AM, Zheng Sheng ZS Zhou wrote:
> > As I wrote in previous mails. I find domian UUID very important in
> > libvirt. It causes a lot of troubles if we start the destination domain
> > with the same UUID. Actually I did try to hack libvirt to do this but
> > wasn't successful.
> 
> Unfortunately, starting a domain with a different UUID is guest-visible,
> and a non-starter.  We have to resolve the issue of libvirt being able
> to track two qemu processes both tied to the same uuid.
> 
> > 
> > I discussed with Lei Li in the CC list. We can add a new QEMU monitor
> > command to change the guest UUID. During the migration, we firstly start
> > destination QEMU process with all vCPUs paused, and this QEMU process gets
> > a different temp UUID. After migration, we call that monitor command to
> > change the UUID back, then resume vCPUs. Guest OS should not notice this
> > change.
> 
> I don't know of any qemu monitor command to hotplug in a UUID; and even
> if there were, changing dmidecode information at runtime is not how bare
> metal behaves, so I'm doubtful that qemu will add such a patch.  I
> really think that your attempts to use a fake UUID are going to end in
> disaster, compared to fixing the real problem of teaching libvirt to
> manage two qemu processes at once both tied to the same UUID.

Yep, that's not going to fly. UUID is part of machine ABI and cannot ever
be changed for a guest.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list