[Top][All Lists]

[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.

From: Eric Blake
Subject: Re: [Qemu-devel] What does VM SIZE means when entering qemu-img info xx.qcow2
Date: Tue, 21 Aug 2018 11:25:21 -0500
User-agent: 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
It shows:
image: qcow2
file format: qcow2
virtual size: 30G
disk size:4M
Snapshot list:
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 saved.
                    If there is VM state, it starts at the first cluster
described by first L1 table entry that doesn't describe a regular guest cluster (i.e. VM state is stored like guest disk content, except that it is stored at offsets that are
                    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

reply via email to

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