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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
