blob: 52a661c693052c0d58725e82852dbc571797d654 (
plain) (
blame)
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
|
device: 0.830
graphic: 0.756
user-level: 0.699
architecture: 0.698
PID: 0.666
socket: 0.647
performance: 0.640
ppc: 0.632
semantic: 0.626
register: 0.619
permissions: 0.590
files: 0.561
kernel: 0.540
network: 0.519
vnc: 0.504
VMM: 0.504
boot: 0.501
risc-v: 0.485
hypervisor: 0.476
mistranslation: 0.436
KVM: 0.427
x86: 0.404
arm: 0.389
TCG: 0.384
i386: 0.376
virtual: 0.352
peripherals: 0.343
debug: 0.336
assembly: 0.184
Prevent qemu-img resize from causing "Active L1 table too large"
This commit prevents qemu from overallocating if qcow2 image is too big (whatever that means): https://lists.gnu.org/archive/html/qemu-devel/2014-07/msg01481.html
However, `qemu-img resize` isn't protected by the same code and allows to go beyond that.
root@nwkr-laptop ~virtkick/hdd # qemu-img resize 33_test_609dffde-eb51-4b75-918d-b814f1bcb526.qcow2 +100000T
Image resized.
Which then causes "Active L1 table too large" error that cannot be reversed.
root@nwkr-laptop ~virtkick/hdd # qemu-img info 33_test_609dffde-eb51-4b75-918d-b814f1bcb526.qcow2
qemu-img: Could not open '33_test_609dffde-eb51-4b75-918d-b814f1bcb526.qcow2': Active L1 table too large
root@nwkr-laptop ~virtkick/hdd # qemu-img resize 33_test_609dffde-eb51-4b75-918d-b814f1bcb526.qcow2 -100000T
qemu-img: Could not open '33_test_609dffde-eb51-4b75-918d-b814f1bcb526.qcow2': Active L1 table too large
I originally faces this bug when I passed wrong parameters to qemu-img in a programatic way which caused an image to go corrupt. It's good to protect user's images from being resized too much.
Thanks for the report, sorry for the late reply: This has been fixed in commit 84c26520d3c1c9ff4a10455748139463278816d5 (included in the 2.7.0 release).
|