[Qemu-devel] [Bug 322602] Re: Snapshot usage makes qcow2 image unusable due to large tables

[Qemu-devel] [Bug 322602] Re: Snapshot usage makes qcow2 image unusable due to large tables

[Jes Sorensen]

Hi,

Could you please let us know whether this is still a problem and if it
isn't, lets close this bug.

 In addition, you haven't listed which version of qemu-kvm you are
running. I am guessing it is something Ubuntu based based on the version
number, but since not all of us are running Ubuntu it would be useful to
have more details.

Thanks,
Jes

-- 
Snapshot usage makes qcow2 image unusable due to large tables
https://bugs.launchpad.net/bugs/322602
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
To reproduce with 0.9.1 and svn:
- Create a 20G (or some size much greater than system RAM) qcow2 image
- Inside VM, install some OS, formatting whole drive
- Create snapshot with savevm
- Inside VM, reformat and reinstall OS
- Create snapshot with savevm
[...]

Eventually, qemu crashes, then neither qemu-img nor qemu can open the image because memory is exhausted.  The reason is that the whole refcount_table is loaded into memory, and this refcount_table has now become much bigger than the size of memory due to each snapshot taken after significant changes to the disk image.

The refcount_table really needs to be loaded and used in fixed size chunks to avoid this problem.  It will only get worse as typical storage set modifications during work sessions between snapshots outpace the size of system RAM.

Alternatively, there needs to be a way to "rollback" a snapshot without loading the whole disk image normally, so that a snapshot which has made the image unusable in this way can be reversed.

Re: [Qemu-devel] [Bug 322602] Re: Snapshot usage makes qcow2 image unusable due to large tables

[Kevin Wolf]

Am 11.06.2010 09:59, schrieb Jes Sorensen:
> Could you please let us know whether this is still a problem and if it
> isn't, lets close this bug.

This looks like a purely hypothetical thing - have you seen this happen
in reality, and if so, with how many snapshots?

This is reported against a very old version, so we have to assume 4k
clusters. This means that a refcount block holds the refcounts for 4k /
2 = 2k clusters. Let's assume a refcount table of only one cluster, so
we can describe (4k / 8) * 2k = 1M clusters with this, which makes up an
image size of 4G.

To hold a 20G virtual disk plus some metadata we'll therefore need
something like 6 clusters = 24k. To make the refcount table consume just
1 MB, you'll therefore need at least 42 snapshots, each fully allocated
on its own, consuming 1 TB for the image. I doubt that there are too
many machines which can handle a 1 TB image file on disk, but not a 1 MB
refcount table in RAM.

Nowadays, of course, we're using 64k clusters by default. With a
refcount table of 64k we describe 16 TB there, with a 1 MB refcount
table it's 256 TB.

Kevin

[Qemu-devel] [Bug 322602] Re: Snapshot usage makes qcow2 image unusable due to large tables

[Thomas Huth]

** Changed in: qemu
       Status: New => Incomplete

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/322602

Title:
  Snapshot usage makes qcow2 image unusable due to large tables

Status in QEMU:
  Incomplete

Bug description:
  To reproduce with 0.9.1 and svn:
  - Create a 20G (or some size much greater than system RAM) qcow2 image
  - Inside VM, install some OS, formatting whole drive
  - Create snapshot with savevm
  - Inside VM, reformat and reinstall OS
  - Create snapshot with savevm
  [...]

  Eventually, qemu crashes, then neither qemu-img nor qemu can open the
  image because memory is exhausted.  The reason is that the whole
  refcount_table is loaded into memory, and this refcount_table has now
  become much bigger than the size of memory due to each snapshot taken
  after significant changes to the disk image.

  The refcount_table really needs to be loaded and used in fixed size
  chunks to avoid this problem.  It will only get worse as typical
  storage set modifications during work sessions between snapshots
  outpace the size of system RAM.

  Alternatively, there needs to be a way to "rollback" a snapshot
  without loading the whole disk image normally, so that a snapshot
  which has made the image unusable in this way can be reversed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/322602/+subscriptions

[Qemu-devel] [Bug 322602] Re: Snapshot usage makes qcow2 image unusable due to large tables

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/322602

Title:
  Snapshot usage makes qcow2 image unusable due to large tables

Status in QEMU:
  Expired

Bug description:
  To reproduce with 0.9.1 and svn:
  - Create a 20G (or some size much greater than system RAM) qcow2 image
  - Inside VM, install some OS, formatting whole drive
  - Create snapshot with savevm
  - Inside VM, reformat and reinstall OS
  - Create snapshot with savevm
  [...]

  Eventually, qemu crashes, then neither qemu-img nor qemu can open the
  image because memory is exhausted.  The reason is that the whole
  refcount_table is loaded into memory, and this refcount_table has now
  become much bigger than the size of memory due to each snapshot taken
  after significant changes to the disk image.

  The refcount_table really needs to be loaded and used in fixed size
  chunks to avoid this problem.  It will only get worse as typical
  storage set modifications during work sessions between snapshots
  outpace the size of system RAM.

  Alternatively, there needs to be a way to "rollback" a snapshot
  without loading the whole disk image normally, so that a snapshot
  which has made the image unusable in this way can be reversed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/322602/+subscriptions