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

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"

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.