qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v1] hmp: 'info snapshots' not showing the id


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v1] hmp: 'info snapshots' not showing the id
Date: Thu, 21 Dec 2017 17:14:14 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

On 12/19/2017 08:20 AM, Max Reitz wrote:

So there are three things:

(1) We probably should not allow snapshot names that could be IDs.
Easiest way to solve this: Names have to start with a non-digit.

Yes, that would be a nice change. It is not strictly backwards compatible (so we'd still have to cope with images that didn't follow the rule, whether created by older qemu or by non-qemu implementations of qcow2), but would alleviate a lot of confusion.


(2) If we want to print a global snapshot's common ID, we need to affirm
that this ID is indeed the same on all disks before we can print it.
Same for names, but currently the name is always the same on all disks
because that is how we identify global snapshots.

(3) You can give an ID to loadvm and then it will load the snapshot with
that ID from all disks.  So if you have snapshots with a common ID on
all disks, these are kind of global snapshots, too, even though they
don't share a name.  Thus, they should probably be included in the
listing (this is what you have just proposed).
I don't like this at all, though.  A snapshot's ID is not really
user-controlled, it's just some auto-generated number.  Therefore, just
because the ID of a snapshot matches across multiple disks, this doesn't
mean that they are related whatsoever.
So, first, I don't think loadvm should work with IDs (at least not
across multiple disks).  But I don't think this really needs to be fixed.
On the other hand, I really don't think info snapshots should list
snapshots that match by ID, because a matching ID does not mean that
snapshots are actually related.  A matching name usually does, though,
so I think what we currently do is sufficient and the right way to do it.

Max


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]