qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Bug 1810603 <1810603@bugs.launchpad.net>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Bug 1810603] Re: QEMU QCow Images grow dramatically
Date: Tue, 8 Jan 2019 08:46:02 -0600	[thread overview]
Message-ID: <c4b207e5-2b98-1bcf-05e0-1228a548c936@redhat.com> (raw)
In-Reply-To: <154693620998.25278.657579942079364570.malone@gac.canonical.com>

[-- Attachment #1: Type: text/plain, Size: 2299 bytes --]

On 1/8/19 2:30 AM, Lenny Helpline wrote:
> I don't have many commands handy, as we manage almost everything through
> libvirt manager.
> 3) create a snapshot of the lined clone:
> virsh snapshot-create-as --domain <VMNAME> --name "test" --halt
> 4) revert the snapshot every X minutes / hours:
> virsh destroy <VMNAME>
> virsh snapshot-revert --snapshotname test --running --force
> Does that help?

Yes. It shows that you are taking internal snapshots, rather than
external.  Note that merely reverting to an internal snapshot does not
delete that snapshot, and also note that although qemu has code for
deleting internal snapshots, I doubt that it currently reclaims the disk
space that was previously in use by that snapshot but no longer needed.
Internal snapshots do not get much attention these days, because most of
our work is focused on external snapshots.

If you were to use external snapshots, then every time you wanted to
create a point in time that you might need to roll back to, you create a
new external snapshot, turning:



image1 <- temp_overlay

then, at the point when you are done with the work in temp_overlay2, you
reset the domain back to using image1 and throw away the old
temp_overlay (or, recreate temp_overlay to be blank, which is the same
as going back to the state in image1); thus, the size of image1 never
grows because you are doing all work in temp_overlay, and rolling back
no longer keeps the changes that were done in a previous branch of work
the way internal snapshots are doing.

In libvirt terms, you could create an external snapshot by adding
--diskspec $disk,snapshot=external for each $disk of your domain (virsh
domblklist can be used to get the list of valid $disk names).  But
libvirt support for reverting to external snapshots is still not
completely rounded out, so you'll have to do a bit more leg work on your
end to piece things back together.

Asking on the libvirt list may give you better insights on how best to
use libvirt to drive external snapshots to accomplish your setup of
frequently reverting to older points in time.

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-01-08 14:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-05 15:32 [Qemu-devel] [Bug 1810603] [NEW] QEMU QCow Images crow dramatically Lenny Helpline
2019-01-05 16:19 ` Eric Blake
2019-01-05 16:25 ` Eric Blake
2019-01-07 18:38 ` [Qemu-devel] [Bug 1810603] Re: QEMU QCow Images grow dramatically Peter Maydell
2019-01-08  8:30 ` Lenny Helpline
2019-01-08 14:46   ` Eric Blake [this message]
2019-01-08 15:41   ` Eric Blake
2019-01-11 13:06 ` Kevin Wolf
2019-01-18 11:01 ` Lenny Helpline
2019-01-18 12:24 ` Kevin Wolf
2019-01-28  9:46 ` Lenny Helpline
2021-02-03 14:01 ` Thomas Huth
2021-04-05  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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c4b207e5-2b98-1bcf-05e0-1228a548c936@redhat.com \
    --to=eblake@redhat.com \
    --cc=1810603@bugs.launchpad.net \
    --cc=qemu-devel@nongnu.org \


* 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).