RFC: qemu: use uuid instead of name for misc filenames

Nikolay Shirokovskiy nshirokovskiy at virtuozzo.com
Tue Mar 10 07:51:30 UTC 2020



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
> 





More information about the libvir-list mailing list