From: Eric Blake <eblake@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Bug 1025244 <1025244@bugs.launchpad.net>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Bug 1025244] Re: qcow2 image increasing disk size above the virtual limit
Date: Wed, 02 Jan 2013 09:07:23 -0700 [thread overview]
Message-ID: <50E45B3B.1090507@redhat.com> (raw)
In-Reply-To: <20130102155011.GA12357@stefanha-thinkpad.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]
On 01/02/2013 08:50 AM, Stefan Hajnoczi wrote:
> On Tue, Dec 18, 2012 at 10:18:20AM -0000, Andy Menzel wrote:
>> Any solution right now? I have a similar problem like Todor Andreev;
>> Our daily backup of some virtual machines (qcow2) looks like that:
>>
>> 1. shutdown the VM
>> 2. create a snapshot via: "qemu-img snapshot -c nameofsnapshot..."
>> 3. boot the VM
>> 4. backup the snapshot to another virtual disk via: "qemu-img convert -f qcow2 -O qcow2 -s nameofsnapshot..."
>> 5. DELETE the snapshot from VM via: qemu-img snapshot -d nameofsnapshot...
>
> It's not safe to modify the qcow2 file while the guest is running. This
> means Step 5 is not really safe and could result in an inconsistent
> image.
>
> This may also be causing the problem: the QEMU process has a variable
> with the next free cluster index. Since Step 5 runs as a separate
> process it does not update the QEMU process' next free cluster index
> variable. QEMU doesn't know that there are now free clusters within the
> image file because you updated the file behind QEMU's back - the result
> is that it grows the file.
>
> Please try deleting the last backup snapshot between Step 1 and Step 2.
> This way you'll free the space while QEMU isn't accessing the image
> file. When you boot up the image file again QEMU should reuse the freed
> clusters.
You might also want to try modifying step 5 to use the HMP delvm monitor
command from within the running qemu rather than going behind qemu's
back with a qemu-img invocation. That's how libvirt deletes internal
snapshots from a running qemu.
Also, there are patches currently under review that are talking about
creating a QMP counterpart to the delvm monitor command.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]
next prev parent reply other threads:[~2013-01-02 16:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120716123031.26191.29124.malonedeb@chaenomeles.canonical.com>
2012-07-17 13:41 ` [Qemu-devel] [Bug 1025244] Re: qcow2 image increasing disk size above the virtual limit Serge Hallyn
2012-12-18 10:18 ` Andy Menzel
2013-01-02 15:50 ` Stefan Hajnoczi
2013-01-02 16:07 ` Eric Blake [this message]
2012-12-19 17:12 ` Serge Hallyn
2013-01-11 13:06 ` Andy Menzel
2014-12-12 16:37 ` Mario
2014-12-14 14:01 ` Michael Tokarev
2014-12-15 16:38 ` Serge Hallyn
2014-12-15 19:40 ` Mario
2014-12-15 20:37 ` Serge Hallyn
2014-12-16 9:23 ` Max Reitz
2014-12-16 12:51 ` Mario
2014-12-17 19:02 ` Serge Hallyn
2018-04-04 17:52 ` Thomas Huth
2018-06-04 4:17 ` Launchpad Bug Tracker
2018-06-04 4:17 ` Launchpad Bug Tracker
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=50E45B3B.1090507@redhat.com \
--to=eblake@redhat.com \
--cc=1025244@bugs.launchpad.net \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.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).