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