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