[libvirt] [RFC] changing/regenerating domain uuid on migration

Hi all. Consider next usecase. There are active domain DA on host A and active domain DB on host B and the uuids of domains are the same. This is quite uncommon of course but still possible. If we have option to change uuid on migration then migration of DA to host B is possible and if we don't have the option we have to stop/edit/start DA to migrate. What is you opinion on subject? Can this functionality be taken into upstream and in what form? In form of setting uuid as a migration parameter or option to regenerate uuid on destination? Nikolay

On Thu, Apr 21, 2016 at 11:24:11AM +0300, Nikolay Shirokovskiy wrote:
Hi all.
Consider next usecase. There are active domain DA on host A and active domain DB on host B and the uuids of domains are the same. This is quite uncommon of course but still possible. If we have option to change uuid on migration then migration of DA to host B is possible and if we don't have the option we have to stop/edit/start DA to migrate.
What is you opinion on subject? Can this functionality be taken into upstream and in what form? In form of setting uuid as a migration parameter or option to regenerate uuid on destination?
I don't have a particular opinion on this. I think other generated stuff could break, e.g. those domains could have the same MAC address etc. I know it's not someone cares about in this case, but there are few things to keep in mind. We were discussing something similar in other threads here about multiplying domains. I wonder, though, if you can change the name (using 'dname' for virsh), why wouldn't you be able to change the uuid (e.g. with --xml) already? We could have just a '--i-know-what-i-am-doing' kind of flag, like we have that '--unsafe' one already.
Nikolay
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

On 21.04.2016 13:15, Martin Kletzander wrote:
On Thu, Apr 21, 2016 at 11:24:11AM +0300, Nikolay Shirokovskiy wrote:
Hi all.
Consider next usecase. There are active domain DA on host A and active domain DB on host B and the uuids of domains are the same. This is quite uncommon of course but still possible. If we have option to change uuid on migration then migration of DA to host B is possible and if we don't have the option we have to stop/edit/start DA to migrate.
What is you opinion on subject? Can this functionality be taken into upstream and in what form? In form of setting uuid as a migration parameter or option to regenerate uuid on destination?
I don't have a particular opinion on this. I think other generated stuff could break, e.g. those domains could have the same MAC address etc. I know it's not someone cares about in this case, but there are few things to keep in mind. We were discussing something similar in other threads here about multiplying domains. I wonder, though, if you can change the name (using 'dname' for virsh), why wouldn't you be able to change the uuid (e.g. with --xml) already? We could have just a '--i-know-what-i-am-doing' kind of flag, like we have that '--unsafe' one already.
Thank you for stepping in. But after some more investigation on my task the libvirt functionality requirements I need changed. I'll describe them in a different RFC. Nikolay
Nikolay
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

On Thu, Apr 21, 2016 at 11:24:11AM +0300, Nikolay Shirokovskiy wrote:
Hi all.
Consider next usecase. There are active domain DA on host A and active domain DB on host B and the uuids of domains are the same. This is quite uncommon of course but still possible. If we have option to change uuid on migration then migration of DA to host B is possible and if we don't have the option we have to stop/edit/start DA to migrate.
What is you opinion on subject? Can this functionality be taken into upstream and in what form? In form of setting uuid as a migration parameter or option to regenerate uuid on destination?
I consider that to be a deployment bug. If you're generating UUIDs using the RFC spec for generation algorithm, the chance of collision of UUIDs should be effectively zero. Furthermore, the UUID is exposed to the guest via SMBIOS, and you can't change that on the fly, so renaming UUID on the QEMU side is really not an option during migration. Regards, 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 :|
participants (3)
-
Daniel P. Berrange
-
Martin Kletzander
-
Nikolay Shirokovskiy