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
