From: Max Reitz <mreitz@redhat.com>
To: seeteena <s1seetee@linux.vnet.ibm.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
lma@suse.com
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v1] hmp: 'info snapshots' not showing the id
Date: Fri, 15 Dec 2017 10:18:48 +0100 [thread overview]
Message-ID: <b5c7e566-34f0-adb0-0fcb-bf272cbb0a81@redhat.com> (raw)
In-Reply-To: <e37d8871-544f-3c4f-3a59-bb66dc5c8b67@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3804 bytes --]
On 2017-12-13 05:50, seeteena wrote:
> Hi David,
>
> While creating snapshots when tag name '0' used in the very first and followed by tag name '1' then snapshot created with tag name '0' is getting erased.
> A snapshot is identified by a name computed either from an id, which is basically a numerical counter starting at 1 for qcow2, or from a tag, which is a string (provided
> by the user or automatically computed).
>
> (qemu) savevm 0
>
> This creates a snapshot with tag '0' and id '1'.
That's something someone has complained about already, as far as I
remember, and this is indeed an issue.
>> (qemu) savevm 1
>
> This deletes snapshot with name '1' (ie, with id '1') and creates snapshot with tag '1' and id '1'.
I think this is the issue, not info snapshots.
> From the output of 'info snapshots' id '1' is not seen for tag '0' instead seeing an empty field.
>
> ID TAG VM SIZE DATE VM CLOCK
> -- 0 338M 2017-10-16 13:44:35 00:02:07.491
>
> If an ID shown as '1' in the above then user can understand the above documented stuff i.e "If there is already a snapshot with the same tag or ID, it is replaced".
> The '--' in ID field is annoying.
Maybe, but this patch is wrong still. Commit 3a1ee711904 says exactly why:
> The patch uses snapshot name instead of snapshot id to determine whether a
> snapshot is fully available and uses '--' instead of snapshot id in output
> because the snapshot id is not guaranteed to be the same on all images.
info snapshots first shows a list of snapshots that are present on all
disks. However, those are matched by name and not by ID, so the ID is
not necessarily the same.
Therefore, we can only print it if it is. Sure, we can do that, but
your patch is missing that check.
Example:
$ qemu-img create -f qcow2 foo.qcow2 64M
Formatting 'foo.qcow2', fmt=qcow2 size=67108864 encryption=off
cluster_size=65536 lazy_refcounts=off refcount_bits=16
$ qemu-img create -f qcow2 bar.qcow2 64M
Formatting 'bar.qcow2', fmt=qcow2 size=67108864 encryption=off
cluster_size=65536 lazy_refcounts=off refcount_bits=16
$ qemu-img snapshot -c common_snapshot foo.qcow2
$ qemu-img snapshot -c bar_snapshot bar.qcow2
$ qemu-img snapshot -c common_snapshot bar.qcow2
$ qemu-system-x86_64 -hda foo.qcow2 -hdb bar.qcow2 -monitor stdio
$ qemu-img snapshot -l foo.qcow2
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 common_snapshot 0 2017-12-15 10:09:17 00:00:00.000
$ qemu-img snapshot -l bar.qcow2
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 bar_snapshot 0 2017-12-15 10:09:25 00:00:00.000
2 common_snapshot 0 2017-12-15 10:09:28 00:00:00.000
QEMU 2.9.1 monitor - type 'help' for more information
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- common_snapshot 0 2017-12-15 10:09:17 00:00:00.000
List of partial (non-loadable) snapshots on 'ide0-hd1':
ID TAG VM SIZE DATE VM CLOCK
1 bar_snapshot 0 2017-12-15 10:09:25 00:00:00.000
With your patch:
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
1 common_snapshot 0 2017-12-15 10:09:17 00:00:00.000
List of partial (non-loadable) snapshots on 'ide0-hd1':
ID TAG VM SIZE DATE VM CLOCK
1 bar_snapshot 0 2017-12-15 10:09:25 00:00:00.000
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 512 bytes --]
next prev parent reply other threads:[~2017-12-15 9:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-21 14:09 [Qemu-devel] [PATCH v1] hmp: 'info snapshots' not showing the id Seeteena Thoufeek
2017-12-12 16:41 ` Dr. David Alan Gilbert
2017-12-13 4:50 ` seeteena
2017-12-15 9:18 ` Max Reitz [this message]
2017-12-18 9:24 ` seeteena
2017-12-19 14:20 ` Max Reitz
2017-12-20 4:34 ` seeteena
2017-12-20 13:18 ` Dr. David Alan Gilbert
2017-12-21 23:14 ` Eric Blake
2017-12-22 7:37 ` Markus Armbruster
2018-01-02 6:42 ` seeteena
2018-01-02 8:24 ` Markus Armbruster
2018-01-04 16:24 ` seeteena
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b5c7e566-34f0-adb0-0fcb-bf272cbb0a81@redhat.com \
--to=mreitz@redhat.com \
--cc=dgilbert@redhat.com \
--cc=lma@suse.com \
--cc=qemu-devel@nongnu.org \
--cc=s1seetee@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).