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