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
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
permissions: 0.987
peripherals: 0.986
user-level: 0.986
VMM: 0.986
device: 0.985
risc-v: 0.985
hypervisor: 0.985
architecture: 0.983
virtual: 0.982
vnc: 0.982
debug: 0.982
performance: 0.982
register: 0.981
assembly: 0.981
arm: 0.980
semantic: 0.979
graphic: 0.978
ppc: 0.977
i386: 0.977
x86: 0.977
socket: 0.975
PID: 0.975
kernel: 0.975
files: 0.975
TCG: 0.975
KVM: 0.974
network: 0.968
mistranslation: 0.962
boot: 0.959
"qemu-img convert -O qcow2 -o backing_file" makes huge images
$ dd if=/dev/urandom bs=1M of=1.img count=4
4+0 records in
4+0 records out
4194304 bytes (4,2 MB) copied, 1,0413 s, 4,0 MB/s
$ qemu-img create -f qcow2 -b 1.img 2.img
Formatting '2.img', fmt=qcow2 size=4194304 backing_file='1.img' encryption=off cluster_size=0
$ qemu-img convert -O qcow2 -o backing_file=1.img 2.img 3.img
$ du -h ?.img
4,1M 1.img
144K 2.img
4,3M 3.img
The conversion result is bigger then the source!
It appears that "-o backing_file" is not applied to data (as expected). I.e. all data is put into the resulting image: both from source image and "backing" image.
Expected behavior is to put only data that is not present in backing_file.
It is possible to chain backing files. As a workaround you could do the following:
$ qemu-img create -f qcow2 -b 2.img 4.img # from now on don't modify 2.img, instead use 4.img
$ qemu-img create -f qcow2 -b 2.img 3.img # here is the 3.img you tried to create with qemu-convert
Images 1.img and 2.img should never be modified, they are immutable snapshots.
Images 3.img and 4.img can be modified and will contain only changes against 2.img.
Perhaps qemu-img needs a command to drop data that is duplicated in the base image. This could be a new flag to commit: qemu-img commit --dedup 3.img.
Do you confirm this as a bug?
Sorry I'm not a frequent Launchpad user and will leave it up to someone more familiar to decide which status to place it in.
On Thu, Oct 14, 2010 at 1:26 PM, Anthony Liguori <email address hidden> wrote:
> ** Changed in: qemu
> Importance: Undecided => Wishlist
>
> ** Changed in: qemu
> Status: New => Confirmed
Thanks for doing this Anthony. Can I set the status myself next time
or do we have rules on who handles bugs?
Stefan
On 10/14/2010 07:51 AM, Stefan Hajnoczi wrote:
> On Thu, Oct 14, 2010 at 1:26 PM, Anthony Liguori<email address hidden> wrote:
>
>> ** Changed in: qemu
>> Importance: Undecided => Wishlist
>>
>> ** Changed in: qemu
>> Status: New => Confirmed
>>
> Thanks for doing this Anthony. Can I set the status myself next time
> or do we have rules on who handles bugs?
>
I'm pretty sure anyone can do it. If not, I'm certainly willing to give
people extra rights on the project if they want to help with bug triage.
Regards,
Anthony Liguori
> Stefan
>
I guess the problem is solved already.
qemu-img version 1.4.0
Is this reintroduced? I am on version 2.3.0
$ dd if=/dev/urandom of=disk bs=1M count=1024
$ qemu-img convert -f raw -O qcow2 disk disk.qcow
$ qemu-img convert -f raw -O qcow2 -o backing_file=disk.qcow disk disk1.qcow
$ ls -l
total 3146388
-rw-r--r-- 1 sakis sakis 1073741824 10 авг 15,29 disk
-rw-r--r-- 1 sakis sakis 1074135040 10 авг 15,30 disk.qcow
-rw-r--r-- 1 sakis sakis 1074135040 10 авг 15,31 disk1.qcow
All the data is copied again.
$ qemu-img info disk1.qcow
image: disk1.qcow
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 1.0G
cluster_size: 65536
*backing file: disk.qcow*
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false
Qemu-img works as expected though.
$ qemu-img create -f qcow2 -o backing_file=disk1.qcow disk2.qcow
$ ls -l
total 3146584
-rw-r--r-- 1 sakis sakis 1073741824 10 авг 15,29 disk
-rw-r--r-- 1 sakis sakis 1074135040 10 авг 15,30 disk.qcow
-rw-r--r-- 1 sakis sakis 1074135040 10 авг 15,31 disk1.qcow
-rw-r--r-- 1 sakis sakis 197120 10 авг 15,33 disk2.qcow
This is a different case. The original report used "qemu-img create" in step 2, which results in a sparse image that refers to the backing file for all data. Your sequence has "qemu-img convert" instead, which fully populates disk.qcow. Therefore, in step 3, "qemu-img convert" leaves the full allocation intact.
My mistake. It's different case than mine. Above sequence (original report) works fine.
But I do not really understand why the same is not achieved in my case. I use the convert instead of the create to get a full image in qcow format. From that point, the desired behaviour is to create a qcow that is based on the one created from the first convert and contain only the changes. Why would the second convert populate the whole image again?
Thanks in advance.
|