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

Mon Mar 30 10:41:38 UTC 2020

On Sun, Mar 29, 2020 at 02:33:41PM +0300, nshirokovskiy wrote:
> 
> 
> 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

Yes, that is a tricky issue, but one that we need to solve, as the need
to have a completely separate of list VMs is the thing I dislike the
most about the local migration patches.

One option is to make the target VM have a different UUID by pickling
its UUID. eg have a migration UUID generated on daemon startup.
0466e1ae-a71a-4e75-89ca-c3591a4cf220.  Then XOR this migration UUID
with the source VM's UUID. So during live migration the target VM
will appear with this XOR'd UUID, and once completed, it will get
the real UUID again.

A different option is to not keep the target VM in the domain list
at all. Instead  virDomainObjPtr, could have a pointer to a second
virDomainObjPtr which stores the target VM temporarily.

> - 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

That is true right now, but I'm thinking that we need to solve this
particular case, even for the domain rename operation. For a graphics
backend using UNIX socket, the socket path is almost certainly going
to be based off the guest name. So when renaming a guest we really want
to be able to rename the UNIX socket.

Thus I think that we need to introduce a new way to do UNIX sockets for
graphics, using an "autopath=yes|no" attribute, in the same way that we
have autoport=yes|no for TCP sockets.  With autopath=yes, then the path
can be changed during a domain rename operation,  and also handled for
local migration.

> > 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.

We only really need 2 "generations", as we can oscillate back & forth
between the two after each migration, hence my thought of using a global
migration UUID which we just XOR with the real UUID to get the alternate.

> 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?

Yes, I think we can move forward.

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 :|