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