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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list