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

[nshirokovskiy]

On 26.03.2020 20:50, 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.
>>>>                                                                                 
> 
> 
> 
>>>> 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)
> 
> I've just realized that there is potential overlap between what we're
> discussing in this thread, and in the thread about localhost migration:
> 
>   https://www.redhat.com/archives/libvir-list/2020-February/msg00061.html
> 
> In the localhost migration case, we need to be able to startup a new
> guest with the same name as an existing guest.  The way we can achieve
> that is by thinking of localhost migration as being a pair of domain
> rename operations.
> 
> ie, consider guest "foo" we want to localhost-migrate
> 
>  - Start target guest "foo-incoming"
>  - Run live migration from "foo" -> "foo-incoming"
>  - Migration completes, CPUs stop
>  - Rename "foo" to "foo-outgoing"
>  - Rename "foo-incoming" to "foo"
>  - Tidy up migration state
>  - Destroy source guest "foo-outgoing"

I think local migration does not fit really nicely in this scheme:

- one can not treat outgoing and incoming VMs as just regular VMs as
  one can not put them into same list as they have same UUID
- it is not just mere rename. In example reflected in [1] the path
  given by mgmt is not subjected to rename operation. The switch
  has to be done by local migration specific code.


[1] https://www.redhat.com/archives/libvir-list/2020-February/msg01026.html

> 
> 
> In both this thread and the localhost migration thread, we seem to have
> come towards a view that symlinks are the only viable way to deal with
> the naming problem for resources on disk that are based on VM name.
> 
> IOW, it would be desirable if whatever solution we take for symlink mgmt
> will solve the localhost migration and domain rename problems at the same
> time.

Agree, symlinks approach itself seems to work well in both cases.
We can use naming scheme like UUID-gen for "stable" paths to fit both rename and local
migration cases. Gen here is for generation, like 1 for domain after first
local migration, 2 after second and so on.

I already has a pending patch series [2] to remove some limitation on renaming.
Can I treat this letter as some agreement that it is useful to move
current paths naming towards "uuid based real path" + "name based symlinks" approach?

[2] https://www.redhat.com/archives/libvir-list/2020-March/msg00018.html


Nikolay