1 files changed, 58 insertions, 0 deletions
diff --git a/results/classifier/118/graphic/322602 b/results/classifier/118/graphic/322602
new file mode 100644
index 000000000..8bf546e34
--- /dev/null
+++ b/results/classifier/118/graphic/322602
@@ -0,0 +1,58 @@
+graphic: 0.899
+device: 0.726
+performance: 0.715
+virtual: 0.613
+semantic: 0.526
+user-level: 0.511
+architecture: 0.504
+socket: 0.444
+kernel: 0.421
+PID: 0.412
+mistranslation: 0.396
+permissions: 0.378
+assembly: 0.373
+vnc: 0.366
+boot: 0.360
+register: 0.349
+debug: 0.344
+network: 0.341
+ppc: 0.296
+i386: 0.275
+x86: 0.262
+hypervisor: 0.244
+files: 0.196
+VMM: 0.178
+risc-v: 0.177
+arm: 0.164
+TCG: 0.148
+peripherals: 0.128
+KVM: 0.126
+
+Snapshot usage makes qcow2 image unusable due to large tables
+
+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.
+
+The refcount_table really needs to be loaded and used in fixed size chunks to avoid this problem.
+
+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.
+
+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
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+