Re: RFC: qemu: use uuid instead of name for misc filenames
On Thu, Feb 27, 2020 at 03:57:04PM +0300, Nikolay Shirokovskiy wrote:
Hi, everyone.
I'm working on supporting domain renaming when it has snapshots which is not
supported now. And it strikes me things will be much simplier to manage on
renaming if we use uuid in filenames instead of domain names.
1. Renaming will only involve saving updated config.
The saving is atomic thanx to tmp file and rename(2) approach. In constast
current renaming on error paths can leave config with old or new name. Thus
on libvirt restart extra VM will appear.
And we don't need to rename autostart links, snapshot directories etc.
Yes, renaming is hard due to the non-atomic nature of the problem.
It ought to be possible to recover/rollback from all but the most
serious failure scenarios though. Problems in the most serious
scenarios, are likely to cause failures in other parts of libvirt
already, such as existing VM shutdown/startup.
2. Renaming will be possible for running domains with no efforts.
We only need to pass uuid instead of name in '-name guest=...' command line.
Passing a uuid for the -name arg would be incorrect. This is a user
visible string, for example displayed in the SDL window title or
the VNC display name. UUIDs are not desirable for exposure to users,
they are for machine usage.
3. Mgmt can stop using autogenerated names for domains.
I guess openstack for example uses names like instance-000002ff because we
have many limitations on domain renaming. And if these limitations are removed
then openstack can just use user supplied names for domains.
In openstack the instance names are unique within the scope of a single
project.
In Libvirt the VM names are unique within the scope of a single libvirt
driver connection (effectively a single host).
Even if libvirt didn't use the name for on disk files, it will still have
the requirement for unique names per-host in libvirt.
This is the key reason why openstack uses "instance-$HEX" as the libvirt
guest name.
It could perhaps use "projectname-guestname" as the name, but i'm not
sure there's much appetite for change in this respect, as it is a long
standing convention now.
4. No issues with long domain names and filename length limit
If the above conversion makes sense I guess the good time to apply it is
on domain start (and rename to support renaming with snapshots).
The above has not considered the benefit that using the VM name
has. Essentially the UUID is good for machines, the VM name is
good for humans. Seeing the guest XML files, or VM log files
using a filename based on UUID instead of name is a *really*
unappealing idea to me.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|