On 06.03.2020 21:20, Daniel P. Berrangé wrote: > On Fri, Feb 28, 2020 at 10:09:41AM +0300, Nikolay Shirokovskiy wrote: >> On 27.02.2020 16:48, Daniel P. Berrangé wrote: >>> 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. >> >> Yes, this is not convinient. The broader idea was to stop passing name on command >> line as we can't change it after process is started. So instead we can omit name >> parameter altogether and set/update name thru QMP. > > I see no problem in continuing to use -name at startup, but certainly if we > wish to propagate renames, then we'll need a QMP command for that. I use quite regularly 'ps ax | grep $NAME' to check if process is running when debugging so having domain name in command line can be be confusing. > >> Also with domain name in path renaming of an active domain looks really messy >> to implement. > > Yep, this goes to the disk image too, as its normal practice to name the > root disk image, based on the VM name. Admins are not going to like > looking in /var/lib/libvirt/images/ and seeing 100's of UUIDs. > > QEMU can be told to re-open disk images, via the blockjob QMP commands, > which could allow us to rename disk images on running VMs. I wonder > if a simple "rename()" works on UNIX sockets - I can't say I've ever > tried it, but I think it probably would work. Yeah, renaming should work I guess. But together with renaming disk images it is lot of operations thus in case of errors we can end up with some paths renamed and some not. > >>>> 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. >> >> I agree. But we can also keep symlinks with domain names for configs/logs etc >> This can be done as a separate tool as I suggested in the letter or maintain >> symlinks always. The idea is failing in this symlinking won't affect daemon >> functionality as symlinks are for humans) > > Have you faced specific failure scenarios with renaming in the real world > production deployments, or is this largely a theoretical problem ? Just theoretical. > > Given that libvirtd has full privileges over the files in question, it > seems like the most likely causes of failure to rename some of the files > are all scenarios where we'd be doomed no matter what. eg If an I/O > error caused storage to be remounted read-only, the guest is doomed. > If an NFS mount permissions are changed on the server, such that libvirtd > can no longer rename, the guest is probably doomed too. If some bad > admin has created clashing filenames behind the back of libvirt this > is going to be problematic no matter what. > > Regards, > Daniel >
