root / qemu-img.texi @ 360a6f2d
History | View | Annotate | Download (17.9 kB)
1 |
@example |
---|---|
2 |
@c man begin SYNOPSIS |
3 |
usage: qemu-img command [command options] |
4 |
@c man end |
5 |
@end example |
6 |
|
7 |
@c man begin DESCRIPTION |
8 |
qemu-img allows you to create, convert and modify images offline. It can handle |
9 |
all image formats supported by QEMU. |
10 |
|
11 |
@b{Warning:} Never use qemu-img to modify images in use by a running virtual |
12 |
machine or any other process; this may destroy the image. Also, be aware that |
13 |
querying an image that is being modified by another process may encounter |
14 |
inconsistent state. |
15 |
@c man end |
16 |
|
17 |
@c man begin OPTIONS |
18 |
|
19 |
The following commands are supported: |
20 |
|
21 |
@include qemu-img-cmds.texi |
22 |
|
23 |
Command parameters: |
24 |
@table @var |
25 |
@item filename |
26 |
is a disk image filename |
27 |
@item fmt |
28 |
is the disk image format. It is guessed automatically in most cases. See below |
29 |
for a description of the supported disk formats. |
30 |
|
31 |
@item --backing-chain |
32 |
will enumerate information about backing files in a disk image chain. Refer |
33 |
below for further description. |
34 |
|
35 |
@item size |
36 |
is the disk image size in bytes. Optional suffixes @code{k} or @code{K} |
37 |
(kilobyte, 1024) @code{M} (megabyte, 1024k) and @code{G} (gigabyte, 1024M) |
38 |
and T (terabyte, 1024G) are supported. @code{b} is ignored. |
39 |
|
40 |
@item output_filename |
41 |
is the destination disk image filename |
42 |
|
43 |
@item output_fmt |
44 |
is the destination format |
45 |
@item options |
46 |
is a comma separated list of format specific options in a |
47 |
name=value format. Use @code{-o ?} for an overview of the options supported |
48 |
by the used format or see the format descriptions below for details. |
49 |
@item snapshot_param |
50 |
is param used for internal snapshot, format is |
51 |
'snapshot.id=[ID],snapshot.name=[NAME]' or '[ID_OR_NAME]' |
52 |
@item snapshot_id_or_name |
53 |
is deprecated, use snapshot_param instead |
54 |
|
55 |
@item -c |
56 |
indicates that target image must be compressed (qcow format only) |
57 |
@item -h |
58 |
with or without a command shows help and lists the supported formats |
59 |
@item -p |
60 |
display progress bar (compare, convert and rebase commands only). |
61 |
If the @var{-p} option is not used for a command that supports it, the |
62 |
progress is reported when the process receives a @code{SIGUSR1} signal. |
63 |
@item -q |
64 |
Quiet mode - do not print any output (except errors). There's no progress bar |
65 |
in case both @var{-q} and @var{-p} options are used. |
66 |
@item -S @var{size} |
67 |
indicates the consecutive number of bytes that must contain only zeros |
68 |
for qemu-img to create a sparse image during conversion. This value is rounded |
69 |
down to the nearest 512 bytes. You may use the common size suffixes like |
70 |
@code{k} for kilobytes. |
71 |
@item -t @var{cache} |
72 |
specifies the cache mode that should be used with the (destination) file. See |
73 |
the documentation of the emulator's @code{-drive cache=...} option for allowed |
74 |
values. |
75 |
@end table |
76 |
|
77 |
Parameters to snapshot subcommand: |
78 |
|
79 |
@table @option |
80 |
|
81 |
@item snapshot |
82 |
is the name of the snapshot to create, apply or delete |
83 |
@item -a |
84 |
applies a snapshot (revert disk to saved state) |
85 |
@item -c |
86 |
creates a snapshot |
87 |
@item -d |
88 |
deletes a snapshot |
89 |
@item -l |
90 |
lists all snapshots in the given image |
91 |
@end table |
92 |
|
93 |
Parameters to compare subcommand: |
94 |
|
95 |
@table @option |
96 |
|
97 |
@item -f |
98 |
First image format |
99 |
@item -F |
100 |
Second image format |
101 |
@item -s |
102 |
Strict mode - fail on on different image size or sector allocation |
103 |
@end table |
104 |
|
105 |
Parameters to convert subcommand: |
106 |
|
107 |
@table @option |
108 |
|
109 |
@item -n |
110 |
Skip the creation of the target volume |
111 |
@end table |
112 |
|
113 |
Command description: |
114 |
|
115 |
@table @option |
116 |
@item check [-f @var{fmt}] [--output=@var{ofmt}] [-r [leaks | all]] @var{filename} |
117 |
|
118 |
Perform a consistency check on the disk image @var{filename}. The command can |
119 |
output in the format @var{ofmt} which is either @code{human} or @code{json}. |
120 |
|
121 |
If @code{-r} is specified, qemu-img tries to repair any inconsistencies found |
122 |
during the check. @code{-r leaks} repairs only cluster leaks, whereas |
123 |
@code{-r all} fixes all kinds of errors, with a higher risk of choosing the |
124 |
wrong fix or hiding corruption that has already occurred. |
125 |
|
126 |
Only the formats @code{qcow2}, @code{qed} and @code{vdi} support |
127 |
consistency checks. |
128 |
|
129 |
@item create [-f @var{fmt}] [-o @var{options}] @var{filename} [@var{size}] |
130 |
|
131 |
Create the new disk image @var{filename} of size @var{size} and format |
132 |
@var{fmt}. Depending on the file format, you can add one or more @var{options} |
133 |
that enable additional features of this format. |
134 |
|
135 |
If the option @var{backing_file} is specified, then the image will record |
136 |
only the differences from @var{backing_file}. No size needs to be specified in |
137 |
this case. @var{backing_file} will never be modified unless you use the |
138 |
@code{commit} monitor command (or qemu-img commit). |
139 |
|
140 |
The size can also be specified using the @var{size} option with @code{-o}, |
141 |
it doesn't need to be specified separately in this case. |
142 |
|
143 |
@item commit [-f @var{fmt}] [-t @var{cache}] @var{filename} |
144 |
|
145 |
Commit the changes recorded in @var{filename} in its base image or backing file. |
146 |
If the backing file is smaller than the snapshot, then the backing file will be |
147 |
resized to be the same size as the snapshot. If the snapshot is smaller than |
148 |
the backing file, the backing file will not be truncated. If you want the |
149 |
backing file to match the size of the smaller snapshot, you can safely truncate |
150 |
it yourself once the commit operation successfully completes. |
151 |
|
152 |
@item compare [-f @var{fmt}] [-F @var{fmt}] [-p] [-s] [-q] @var{filename1} @var{filename2} |
153 |
|
154 |
Check if two images have the same content. You can compare images with |
155 |
different format or settings. |
156 |
|
157 |
The format is probed unless you specify it by @var{-f} (used for |
158 |
@var{filename1}) and/or @var{-F} (used for @var{filename2}) option. |
159 |
|
160 |
By default, images with different size are considered identical if the larger |
161 |
image contains only unallocated and/or zeroed sectors in the area after the end |
162 |
of the other image. In addition, if any sector is not allocated in one image |
163 |
and contains only zero bytes in the second one, it is evaluated as equal. You |
164 |
can use Strict mode by specifying the @var{-s} option. When compare runs in |
165 |
Strict mode, it fails in case image size differs or a sector is allocated in |
166 |
one image and is not allocated in the second one. |
167 |
|
168 |
By default, compare prints out a result message. This message displays |
169 |
information that both images are same or the position of the first different |
170 |
byte. In addition, result message can report different image size in case |
171 |
Strict mode is used. |
172 |
|
173 |
Compare exits with @code{0} in case the images are equal and with @code{1} |
174 |
in case the images differ. Other exit codes mean an error occurred during |
175 |
execution and standard error output should contain an error message. |
176 |
The following table sumarizes all exit codes of the compare subcommand: |
177 |
|
178 |
@table @option |
179 |
|
180 |
@item 0 |
181 |
Images are identical |
182 |
@item 1 |
183 |
Images differ |
184 |
@item 2 |
185 |
Error on opening an image |
186 |
@item 3 |
187 |
Error on checking a sector allocation |
188 |
@item 4 |
189 |
Error on reading data |
190 |
|
191 |
@end table |
192 |
|
193 |
@item convert [-c] [-p] [-n] [-f @var{fmt}] [-t @var{cache}] [-O @var{output_fmt}] [-o @var{options}] [-s @var{snapshot_id_or_name}] [-l @var{snapshot_param}] [-S @var{sparse_size}] @var{filename} [@var{filename2} [...]] @var{output_filename} |
194 |
|
195 |
Convert the disk image @var{filename} or a snapshot @var{snapshot_param}(@var{snapshot_id_or_name} is deprecated) |
196 |
to disk image @var{output_filename} using format @var{output_fmt}. It can be optionally compressed (@code{-c} |
197 |
option) or use any format specific options like encryption (@code{-o} option). |
198 |
|
199 |
Only the formats @code{qcow} and @code{qcow2} support compression. The |
200 |
compression is read-only. It means that if a compressed sector is |
201 |
rewritten, then it is rewritten as uncompressed data. |
202 |
|
203 |
Image conversion is also useful to get smaller image when using a |
204 |
growable format such as @code{qcow} or @code{cow}: the empty sectors |
205 |
are detected and suppressed from the destination image. |
206 |
|
207 |
@var{sparse_size} indicates the consecutive number of bytes (defaults to 4k) |
208 |
that must contain only zeros for qemu-img to create a sparse image during |
209 |
conversion. If @var{sparse_size} is 0, the source will not be scanned for |
210 |
unallocated or zero sectors, and the destination image will always be |
211 |
fully allocated. |
212 |
|
213 |
You can use the @var{backing_file} option to force the output image to be |
214 |
created as a copy on write image of the specified base image; the |
215 |
@var{backing_file} should have the same content as the input's base image, |
216 |
however the path, image format, etc may differ. |
217 |
|
218 |
If the @code{-n} option is specified, the target volume creation will be |
219 |
skipped. This is useful for formats such as @code{rbd} if the target |
220 |
volume has already been created with site specific options that cannot |
221 |
be supplied through qemu-img. |
222 |
|
223 |
@item info [-f @var{fmt}] [--output=@var{ofmt}] [--backing-chain] @var{filename} |
224 |
|
225 |
Give information about the disk image @var{filename}. Use it in |
226 |
particular to know the size reserved on disk which can be different |
227 |
from the displayed size. If VM snapshots are stored in the disk image, |
228 |
they are displayed too. The command can output in the format @var{ofmt} |
229 |
which is either @code{human} or @code{json}. |
230 |
|
231 |
If a disk image has a backing file chain, information about each disk image in |
232 |
the chain can be recursively enumerated by using the option @code{--backing-chain}. |
233 |
|
234 |
For instance, if you have an image chain like: |
235 |
|
236 |
@example |
237 |
base.qcow2 <- snap1.qcow2 <- snap2.qcow2 |
238 |
@end example |
239 |
|
240 |
To enumerate information about each disk image in the above chain, starting from top to base, do: |
241 |
|
242 |
@example |
243 |
qemu-img info --backing-chain snap2.qcow2 |
244 |
@end example |
245 |
|
246 |
@item map [-f @var{fmt}] [--output=@var{ofmt}] @var{filename} |
247 |
|
248 |
Dump the metadata of image @var{filename} and its backing file chain. |
249 |
In particular, this commands dumps the allocation state of every sector |
250 |
of @var{filename}, together with the topmost file that allocates it in |
251 |
the backing file chain. |
252 |
|
253 |
Two option formats are possible. The default format (@code{human}) |
254 |
only dumps known-nonzero areas of the file. Known-zero parts of the |
255 |
file are omitted altogether, and likewise for parts that are not allocated |
256 |
throughout the chain. @command{qemu-img} output will identify a file |
257 |
from where the data can be read, and the offset in the file. Each line |
258 |
will include four fields, the first three of which are hexadecimal |
259 |
numbers. For example the first line of: |
260 |
@example |
261 |
Offset Length Mapped to File |
262 |
0 0x20000 0x50000 /tmp/overlay.qcow2 |
263 |
0x100000 0x10000 0x95380000 /tmp/backing.qcow2 |
264 |
@end example |
265 |
@noindent |
266 |
means that 0x20000 (131072) bytes starting at offset 0 in the image are |
267 |
available in /tmp/overlay.qcow2 (opened in @code{raw} format) starting |
268 |
at offset 0x50000 (327680). Data that is compressed, encrypted, or |
269 |
otherwise not available in raw format will cause an error if @code{human} |
270 |
format is in use. Note that file names can include newlines, thus it is |
271 |
not safe to parse this output format in scripts. |
272 |
|
273 |
The alternative format @code{json} will return an array of dictionaries |
274 |
in JSON format. It will include similar information in |
275 |
the @code{start}, @code{length}, @code{offset} fields; |
276 |
it will also include other more specific information: |
277 |
@itemize @minus |
278 |
@item |
279 |
whether the sectors contain actual data or not (boolean field @code{data}; |
280 |
if false, the sectors are either unallocated or stored as optimized |
281 |
all-zero clusters); |
282 |
|
283 |
@item |
284 |
whether the data is known to read as zero (boolean field @code{zero}); |
285 |
|
286 |
@item |
287 |
in order to make the output shorter, the target file is expressed as |
288 |
a @code{depth}; for example, a depth of 2 refers to the backing file |
289 |
of the backing file of @var{filename}. |
290 |
@end itemize |
291 |
|
292 |
In JSON format, the @code{offset} field is optional; it is absent in |
293 |
cases where @code{human} format would omit the entry or exit with an error. |
294 |
If @code{data} is false and the @code{offset} field is present, the |
295 |
corresponding sectors in the file are not yet in use, but they are |
296 |
preallocated. |
297 |
|
298 |
For more information, consult @file{include/block/block.h} in QEMU's |
299 |
source code. |
300 |
|
301 |
@item snapshot [-l | -a @var{snapshot} | -c @var{snapshot} | -d @var{snapshot} ] @var{filename} |
302 |
|
303 |
List, apply, create or delete snapshots in image @var{filename}. |
304 |
|
305 |
@item rebase [-f @var{fmt}] [-t @var{cache}] [-p] [-u] -b @var{backing_file} [-F @var{backing_fmt}] @var{filename} |
306 |
|
307 |
Changes the backing file of an image. Only the formats @code{qcow2} and |
308 |
@code{qed} support changing the backing file. |
309 |
|
310 |
The backing file is changed to @var{backing_file} and (if the image format of |
311 |
@var{filename} supports this) the backing file format is changed to |
312 |
@var{backing_fmt}. If @var{backing_file} is specified as ``'' (the empty |
313 |
string), then the image is rebased onto no backing file (i.e. it will exist |
314 |
independently of any backing file). |
315 |
|
316 |
There are two different modes in which @code{rebase} can operate: |
317 |
@table @option |
318 |
@item Safe mode |
319 |
This is the default mode and performs a real rebase operation. The new backing |
320 |
file may differ from the old one and qemu-img rebase will take care of keeping |
321 |
the guest-visible content of @var{filename} unchanged. |
322 |
|
323 |
In order to achieve this, any clusters that differ between @var{backing_file} |
324 |
and the old backing file of @var{filename} are merged into @var{filename} |
325 |
before actually changing the backing file. |
326 |
|
327 |
Note that the safe mode is an expensive operation, comparable to converting |
328 |
an image. It only works if the old backing file still exists. |
329 |
|
330 |
@item Unsafe mode |
331 |
qemu-img uses the unsafe mode if @code{-u} is specified. In this mode, only the |
332 |
backing file name and format of @var{filename} is changed without any checks |
333 |
on the file contents. The user must take care of specifying the correct new |
334 |
backing file, or the guest-visible content of the image will be corrupted. |
335 |
|
336 |
This mode is useful for renaming or moving the backing file to somewhere else. |
337 |
It can be used without an accessible old backing file, i.e. you can use it to |
338 |
fix an image whose backing file has already been moved/renamed. |
339 |
@end table |
340 |
|
341 |
You can use @code{rebase} to perform a ``diff'' operation on two |
342 |
disk images. This can be useful when you have copied or cloned |
343 |
a guest, and you want to get back to a thin image on top of a |
344 |
template or base image. |
345 |
|
346 |
Say that @code{base.img} has been cloned as @code{modified.img} by |
347 |
copying it, and that the @code{modified.img} guest has run so there |
348 |
are now some changes compared to @code{base.img}. To construct a thin |
349 |
image called @code{diff.qcow2} that contains just the differences, do: |
350 |
|
351 |
@example |
352 |
qemu-img create -f qcow2 -b modified.img diff.qcow2 |
353 |
qemu-img rebase -b base.img diff.qcow2 |
354 |
@end example |
355 |
|
356 |
At this point, @code{modified.img} can be discarded, since |
357 |
@code{base.img + diff.qcow2} contains the same information. |
358 |
|
359 |
@item resize @var{filename} [+ | -]@var{size} |
360 |
|
361 |
Change the disk image as if it had been created with @var{size}. |
362 |
|
363 |
Before using this command to shrink a disk image, you MUST use file system and |
364 |
partitioning tools inside the VM to reduce allocated file systems and partition |
365 |
sizes accordingly. Failure to do so will result in data loss! |
366 |
|
367 |
After using this command to grow a disk image, you must use file system and |
368 |
partitioning tools inside the VM to actually begin using the new space on the |
369 |
device. |
370 |
|
371 |
@item amend [-f @var{fmt}] -o @var{options} @var{filename} |
372 |
|
373 |
Amends the image format specific @var{options} for the image file |
374 |
@var{filename}. Not all file formats support this operation. |
375 |
@end table |
376 |
@c man end |
377 |
|
378 |
@ignore |
379 |
@c man begin NOTES |
380 |
Supported image file formats: |
381 |
|
382 |
@table @option |
383 |
@item raw |
384 |
|
385 |
Raw disk image format (default). This format has the advantage of |
386 |
being simple and easily exportable to all other emulators. If your |
387 |
file system supports @emph{holes} (for example in ext2 or ext3 on |
388 |
Linux or NTFS on Windows), then only the written sectors will reserve |
389 |
space. Use @code{qemu-img info} to know the real size used by the |
390 |
image or @code{ls -ls} on Unix/Linux. |
391 |
|
392 |
@item qcow2 |
393 |
QEMU image format, the most versatile format. Use it to have smaller |
394 |
images (useful if your filesystem does not supports holes, for example |
395 |
on Windows), optional AES encryption, zlib based compression and |
396 |
support of multiple VM snapshots. |
397 |
|
398 |
Supported options: |
399 |
@table @code |
400 |
@item compat |
401 |
Determines the qcow2 version to use. @code{compat=0.10} uses the |
402 |
traditional image format that can be read by any QEMU since 0.10. |
403 |
@code{compat=1.1} enables image format extensions that only QEMU 1.1 and |
404 |
newer understand (this is the default). Amongst others, this includes zero |
405 |
clusters, which allow efficient copy-on-read for sparse images. |
406 |
|
407 |
@item backing_file |
408 |
File name of a base image (see @option{create} subcommand) |
409 |
@item backing_fmt |
410 |
Image format of the base image |
411 |
@item encryption |
412 |
If this option is set to @code{on}, the image is encrypted. |
413 |
|
414 |
Encryption uses the AES format which is very secure (128 bit keys). Use |
415 |
a long password (16 characters) to get maximum protection. |
416 |
|
417 |
@item cluster_size |
418 |
Changes the qcow2 cluster size (must be between 512 and 2M). Smaller cluster |
419 |
sizes can improve the image file size whereas larger cluster sizes generally |
420 |
provide better performance. |
421 |
|
422 |
@item preallocation |
423 |
Preallocation mode (allowed values: off, metadata). An image with preallocated |
424 |
metadata is initially larger but can improve performance when the image needs |
425 |
to grow. |
426 |
|
427 |
@item lazy_refcounts |
428 |
If this option is set to @code{on}, reference count updates are postponed with |
429 |
the goal of avoiding metadata I/O and improving performance. This is |
430 |
particularly interesting with @option{cache=writethrough} which doesn't batch |
431 |
metadata updates. The tradeoff is that after a host crash, the reference count |
432 |
tables must be rebuilt, i.e. on the next open an (automatic) @code{qemu-img |
433 |
check -r all} is required, which may take some time. |
434 |
|
435 |
This option can only be enabled if @code{compat=1.1} is specified. |
436 |
|
437 |
@end table |
438 |
|
439 |
@item Other |
440 |
QEMU also supports various other image file formats for compatibility with |
441 |
older QEMU versions or other hypervisors, including VMDK, VDI, VHD (vpc), VHDX, |
442 |
qcow1 and QED. For a full list of supported formats see @code{qemu-img --help}. |
443 |
For a more detailed description of these formats, see the QEMU Emulation User |
444 |
Documentation. |
445 |
|
446 |
The main purpose of the block drivers for these formats is image conversion. |
447 |
For running VMs, it is recommended to convert the disk images to either raw or |
448 |
qcow2 in order to achieve good performance. |
449 |
@end table |
450 |
|
451 |
|
452 |
@c man end |
453 |
|
454 |
@setfilename qemu-img |
455 |
@settitle QEMU disk image utility |
456 |
|
457 |
@c man begin SEEALSO |
458 |
The HTML documentation of QEMU for more precise information and Linux |
459 |
user mode emulator invocation. |
460 |
@c man end |
461 |
|
462 |
@c man begin AUTHOR |
463 |
Fabrice Bellard |
464 |
@c man end |
465 |
|
466 |
@end ignore |