[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] What does VM SIZE means when entering qemu-img info xx.
Re: [Qemu-devel] What does VM SIZE means when entering qemu-img info xx.qcow2
Tue, 21 Aug 2018 11:25:21 -0500
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
On 08/21/2018 02:44 AM, lampahome wrote:
I have an qcow2 image and I mount it to /dev/nbd then write somethin.
Then I take internal snapshot in the qcow2.
I enter the command qemu-img info qcow2
file format: qcow2
virtual size: 30G
ID, TAG, VM SIZE, DATE, VM CLOCK
1, snap1, 0, xxxx-xx-xx, 00:00:00
The field of "VM SIZE" is zero in my host machine.
What does it mean and why is it an zero?
That field tracks how much space is occupied in the image by the machine
state (RAM contents and device state) when using the HMP command on a
running qemu instance to take a live snapshot. But when you use
'qemu-img snapshot -c' on an offline image, there is no machine state to
be saved, so the field will always be 0 in that case.
Or, more officially, read docs/interop/qcow2.txt:
32 - 35: Size of the VM state in bytes. 0 if no VM state is
If there is VM state, it starts at the first cluster
described by first L1 table entry that doesn't
regular guest cluster (i.e. VM state is stored like
disk content, except that it is stored at offsets
larger than the virtual disk presented to the guest)
(And don't try to use qemu-img snapshot -c while there is a qemu process
running the live guest, as you are liable to cause data corruption with
two simultaneous writers. Modern qemu should prevent you from
attempting that due to file locking permission checks, but older qemu
would happily let you shoot yourself in the foot - in fact, this is one
of the reasons we added file locking permission checks)
That said, internal snapshots are not necessarily well-tested and
well-supported - there are some performance drawbacks with using live
internal snapshots (among other things, the guest is nonresponsive for
the length of time it takes to migrate the guest state into the qcow2
file, which can definitely be noticeable; and there have been bugs in
the past where adding additional snapshots took additional time with
quadratic growth patterns - while some of these things have been
patched, it has not been a high priority, and you can't guarantee that
such patches are backported to stable distros). Even internal snapshots
taken while offline do not play nicely with backing chains between
multiple files, where a lack of current sanity checking in qemu means it
can be easy to corrupt your guest-visible state if you are not careful.
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org