1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
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.]
|
