mirror of
https://github.com/xemu-project/xemu.git
synced 2024-12-27 14:35:11 +00:00
e11ce12f5e
Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
746 lines
30 KiB
Plaintext
746 lines
30 KiB
Plaintext
@example
|
|
@c man begin SYNOPSIS
|
|
@command{qemu-img} [@var{standard} @var{options}] @var{command} [@var{command} @var{options}]
|
|
@c man end
|
|
@end example
|
|
|
|
@c man begin DESCRIPTION
|
|
qemu-img allows you to create, convert and modify images offline. It can handle
|
|
all image formats supported by QEMU.
|
|
|
|
@b{Warning:} Never use qemu-img to modify images in use by a running virtual
|
|
machine or any other process; this may destroy the image. Also, be aware that
|
|
querying an image that is being modified by another process may encounter
|
|
inconsistent state.
|
|
@c man end
|
|
|
|
@c man begin OPTIONS
|
|
|
|
Standard options:
|
|
@table @option
|
|
@item -h, --help
|
|
Display this help and exit
|
|
@item -V, --version
|
|
Display version information and exit
|
|
@item -T, --trace [[enable=]@var{pattern}][,events=@var{file}][,file=@var{file}]
|
|
@findex --trace
|
|
@include qemu-option-trace.texi
|
|
@end table
|
|
|
|
The following commands are supported:
|
|
|
|
@include qemu-img-cmds.texi
|
|
|
|
Command parameters:
|
|
@table @var
|
|
|
|
@item filename
|
|
is a disk image filename
|
|
|
|
@item fmt
|
|
is the disk image format. It is guessed automatically in most cases. See below
|
|
for a description of the supported disk formats.
|
|
|
|
@item size
|
|
is the disk image size in bytes. Optional suffixes @code{k} or @code{K}
|
|
(kilobyte, 1024) @code{M} (megabyte, 1024k) and @code{G} (gigabyte, 1024M)
|
|
and T (terabyte, 1024G) are supported. @code{b} is ignored.
|
|
|
|
@item output_filename
|
|
is the destination disk image filename
|
|
|
|
@item output_fmt
|
|
is the destination format
|
|
|
|
@item options
|
|
is a comma separated list of format specific options in a
|
|
name=value format. Use @code{-o ?} for an overview of the options supported
|
|
by the used format or see the format descriptions below for details.
|
|
|
|
@item snapshot_param
|
|
is param used for internal snapshot, format is
|
|
'snapshot.id=[ID],snapshot.name=[NAME]' or '[ID_OR_NAME]'
|
|
|
|
@end table
|
|
|
|
@table @option
|
|
|
|
@item --object @var{objectdef}
|
|
is a QEMU user creatable object definition. See the @code{qemu(1)} manual
|
|
page for a description of the object properties. The most common object
|
|
type is a @code{secret}, which is used to supply passwords and/or encryption
|
|
keys.
|
|
|
|
@item --image-opts
|
|
Indicates that the source @var{filename} parameter is to be interpreted as a
|
|
full option string, not a plain filename. This parameter is mutually
|
|
exclusive with the @var{-f} parameter.
|
|
|
|
@item --target-image-opts
|
|
Indicates that the @var{output_filename} parameter(s) are to be interpreted as
|
|
a full option string, not a plain filename. This parameter is mutually
|
|
exclusive with the @var{-O} parameters. It is currently required to also use
|
|
the @var{-n} parameter to skip image creation. This restriction may be relaxed
|
|
in a future release.
|
|
|
|
@item --force-share (-U)
|
|
If specified, @code{qemu-img} will open the image in shared mode, allowing
|
|
other QEMU processes to open it in write mode. For example, this can be used to
|
|
get the image information (with 'info' subcommand) when the image is used by a
|
|
running guest. Note that this could produce inconsistent results because of
|
|
concurrent metadata changes, etc. This option is only allowed when opening
|
|
images in read-only mode.
|
|
|
|
@item --backing-chain
|
|
will enumerate information about backing files in a disk image chain. Refer
|
|
below for further description.
|
|
|
|
@item -c
|
|
indicates that target image must be compressed (qcow format only)
|
|
|
|
@item -h
|
|
with or without a command shows help and lists the supported formats
|
|
|
|
@item -p
|
|
display progress bar (compare, convert and rebase commands only).
|
|
If the @var{-p} option is not used for a command that supports it, the
|
|
progress is reported when the process receives a @code{SIGUSR1} or
|
|
@code{SIGINFO} signal.
|
|
|
|
@item -q
|
|
Quiet mode - do not print any output (except errors). There's no progress bar
|
|
in case both @var{-q} and @var{-p} options are used.
|
|
|
|
@item -S @var{size}
|
|
indicates the consecutive number of bytes that must contain only zeros
|
|
for qemu-img to create a sparse image during conversion. This value is rounded
|
|
down to the nearest 512 bytes. You may use the common size suffixes like
|
|
@code{k} for kilobytes.
|
|
|
|
@item -t @var{cache}
|
|
specifies the cache mode that should be used with the (destination) file. See
|
|
the documentation of the emulator's @code{-drive cache=...} option for allowed
|
|
values.
|
|
|
|
@item -T @var{src_cache}
|
|
specifies the cache mode that should be used with the source file(s). See
|
|
the documentation of the emulator's @code{-drive cache=...} option for allowed
|
|
values.
|
|
|
|
@end table
|
|
|
|
Parameters to snapshot subcommand:
|
|
|
|
@table @option
|
|
|
|
@item snapshot
|
|
is the name of the snapshot to create, apply or delete
|
|
@item -a
|
|
applies a snapshot (revert disk to saved state)
|
|
@item -c
|
|
creates a snapshot
|
|
@item -d
|
|
deletes a snapshot
|
|
@item -l
|
|
lists all snapshots in the given image
|
|
@end table
|
|
|
|
Parameters to compare subcommand:
|
|
|
|
@table @option
|
|
|
|
@item -f
|
|
First image format
|
|
@item -F
|
|
Second image format
|
|
@item -s
|
|
Strict mode - fail on different image size or sector allocation
|
|
@end table
|
|
|
|
Parameters to convert subcommand:
|
|
|
|
@table @option
|
|
|
|
@item -n
|
|
Skip the creation of the target volume
|
|
@item -m
|
|
Number of parallel coroutines for the convert process
|
|
@item -W
|
|
Allow out-of-order writes to the destination. This option improves performance,
|
|
but is only recommended for preallocated devices like host devices or other
|
|
raw block devices.
|
|
@item -C
|
|
Try to use copy offloading to move data from source image to target. This may
|
|
improve performance if the data is remote, such as with NFS or iSCSI backends,
|
|
but will not automatically sparsify zero sectors, and may result in a fully
|
|
allocated target image depending on the host support for getting allocation
|
|
information.
|
|
@end table
|
|
|
|
Parameters to dd subcommand:
|
|
|
|
@table @option
|
|
|
|
@item bs=@var{block_size}
|
|
defines the block size
|
|
@item count=@var{blocks}
|
|
sets the number of input blocks to copy
|
|
@item if=@var{input}
|
|
sets the input file
|
|
@item of=@var{output}
|
|
sets the output file
|
|
@item skip=@var{blocks}
|
|
sets the number of input blocks to skip
|
|
@end table
|
|
|
|
Command description:
|
|
|
|
@table @option
|
|
|
|
@item amend [--object @var{objectdef}] [--image-opts] [-p] [-p] [-f @var{fmt}] [-t @var{cache}] -o @var{options} @var{filename}
|
|
|
|
Amends the image format specific @var{options} for the image file
|
|
@var{filename}. Not all file formats support this operation.
|
|
|
|
@item bench [-c @var{count}] [-d @var{depth}] [-f @var{fmt}] [--flush-interval=@var{flush_interval}] [-n] [--no-drain] [-o @var{offset}] [--pattern=@var{pattern}] [-q] [-s @var{buffer_size}] [-S @var{step_size}] [-t @var{cache}] [-w] [-U] @var{filename}
|
|
|
|
Run a simple sequential I/O benchmark on the specified image. If @code{-w} is
|
|
specified, a write test is performed, otherwise a read test is performed.
|
|
|
|
A total number of @var{count} I/O requests is performed, each @var{buffer_size}
|
|
bytes in size, and with @var{depth} requests in parallel. The first request
|
|
starts at the position given by @var{offset}, each following request increases
|
|
the current position by @var{step_size}. If @var{step_size} is not given,
|
|
@var{buffer_size} is used for its value.
|
|
|
|
If @var{flush_interval} is specified for a write test, the request queue is
|
|
drained and a flush is issued before new writes are made whenever the number of
|
|
remaining requests is a multiple of @var{flush_interval}. If additionally
|
|
@code{--no-drain} is specified, a flush is issued without draining the request
|
|
queue first.
|
|
|
|
If @code{-n} is specified, the native AIO backend is used if possible. On
|
|
Linux, this option only works if @code{-t none} or @code{-t directsync} is
|
|
specified as well.
|
|
|
|
For write tests, by default a buffer filled with zeros is written. This can be
|
|
overridden with a pattern byte specified by @var{pattern}.
|
|
|
|
@item check [--object @var{objectdef}] [--image-opts] [-q] [-f @var{fmt}] [--output=@var{ofmt}] [-r [leaks | all]] [-T @var{src_cache}] [-U] @var{filename}
|
|
|
|
Perform a consistency check on the disk image @var{filename}. The command can
|
|
output in the format @var{ofmt} which is either @code{human} or @code{json}.
|
|
|
|
If @code{-r} is specified, qemu-img tries to repair any inconsistencies found
|
|
during the check. @code{-r leaks} repairs only cluster leaks, whereas
|
|
@code{-r all} fixes all kinds of errors, with a higher risk of choosing the
|
|
wrong fix or hiding corruption that has already occurred.
|
|
|
|
Only the formats @code{qcow2}, @code{qed} and @code{vdi} support
|
|
consistency checks.
|
|
|
|
In case the image does not have any inconsistencies, check exits with @code{0}.
|
|
Other exit codes indicate the kind of inconsistency found or if another error
|
|
occurred. The following table summarizes all exit codes of the check subcommand:
|
|
|
|
@table @option
|
|
|
|
@item 0
|
|
Check completed, the image is (now) consistent
|
|
@item 1
|
|
Check not completed because of internal errors
|
|
@item 2
|
|
Check completed, image is corrupted
|
|
@item 3
|
|
Check completed, image has leaked clusters, but is not corrupted
|
|
@item 63
|
|
Checks are not supported by the image format
|
|
|
|
@end table
|
|
|
|
If @code{-r} is specified, exit codes representing the image state refer to the
|
|
state after (the attempt at) repairing it. That is, a successful @code{-r all}
|
|
will yield the exit code 0, independently of the image state before.
|
|
|
|
@item commit [--object @var{objectdef}] [--image-opts] [-q] [-f @var{fmt}] [-t @var{cache}] [-b @var{base}] [-d] [-p] @var{filename}
|
|
|
|
Commit the changes recorded in @var{filename} in its base image or backing file.
|
|
If the backing file is smaller than the snapshot, then the backing file will be
|
|
resized to be the same size as the snapshot. If the snapshot is smaller than
|
|
the backing file, the backing file will not be truncated. If you want the
|
|
backing file to match the size of the smaller snapshot, you can safely truncate
|
|
it yourself once the commit operation successfully completes.
|
|
|
|
The image @var{filename} is emptied after the operation has succeeded. If you do
|
|
not need @var{filename} afterwards and intend to drop it, you may skip emptying
|
|
@var{filename} by specifying the @code{-d} flag.
|
|
|
|
If the backing chain of the given image file @var{filename} has more than one
|
|
layer, the backing file into which the changes will be committed may be
|
|
specified as @var{base} (which has to be part of @var{filename}'s backing
|
|
chain). If @var{base} is not specified, the immediate backing file of the top
|
|
image (which is @var{filename}) will be used. Note that after a commit operation
|
|
all images between @var{base} and the top image will be invalid and may return
|
|
garbage data when read. For this reason, @code{-b} implies @code{-d} (so that
|
|
the top image stays valid).
|
|
|
|
@item compare [--object @var{objectdef}] [--image-opts] [-f @var{fmt}] [-F @var{fmt}] [-T @var{src_cache}] [-p] [-q] [-s] [-U] @var{filename1} @var{filename2}
|
|
|
|
Check if two images have the same content. You can compare images with
|
|
different format or settings.
|
|
|
|
The format is probed unless you specify it by @var{-f} (used for
|
|
@var{filename1}) and/or @var{-F} (used for @var{filename2}) option.
|
|
|
|
By default, images with different size are considered identical if the larger
|
|
image contains only unallocated and/or zeroed sectors in the area after the end
|
|
of the other image. In addition, if any sector is not allocated in one image
|
|
and contains only zero bytes in the second one, it is evaluated as equal. You
|
|
can use Strict mode by specifying the @var{-s} option. When compare runs in
|
|
Strict mode, it fails in case image size differs or a sector is allocated in
|
|
one image and is not allocated in the second one.
|
|
|
|
By default, compare prints out a result message. This message displays
|
|
information that both images are same or the position of the first different
|
|
byte. In addition, result message can report different image size in case
|
|
Strict mode is used.
|
|
|
|
Compare exits with @code{0} in case the images are equal and with @code{1}
|
|
in case the images differ. Other exit codes mean an error occurred during
|
|
execution and standard error output should contain an error message.
|
|
The following table sumarizes all exit codes of the compare subcommand:
|
|
|
|
@table @option
|
|
|
|
@item 0
|
|
Images are identical
|
|
@item 1
|
|
Images differ
|
|
@item 2
|
|
Error on opening an image
|
|
@item 3
|
|
Error on checking a sector allocation
|
|
@item 4
|
|
Error on reading data
|
|
|
|
@end table
|
|
|
|
@item convert [--object @var{objectdef}] [--image-opts] [--target-image-opts] [-U] [-C] [-c] [-p] [-q] [-n] [-f @var{fmt}] [-t @var{cache}] [-T @var{src_cache}] [-O @var{output_fmt}] [-B @var{backing_file}] [-o @var{options}] [-l @var{snapshot_param}] [-S @var{sparse_size}] [-m @var{num_coroutines}] [-W] @var{filename} [@var{filename2} [...]] @var{output_filename}
|
|
|
|
Convert the disk image @var{filename} or a snapshot @var{snapshot_param}
|
|
to disk image @var{output_filename} using format @var{output_fmt}. It can be optionally compressed (@code{-c}
|
|
option) or use any format specific options like encryption (@code{-o} option).
|
|
|
|
Only the formats @code{qcow} and @code{qcow2} support compression. The
|
|
compression is read-only. It means that if a compressed sector is
|
|
rewritten, then it is rewritten as uncompressed data.
|
|
|
|
Image conversion is also useful to get smaller image when using a
|
|
growable format such as @code{qcow}: the empty sectors are detected and
|
|
suppressed from the destination image.
|
|
|
|
@var{sparse_size} indicates the consecutive number of bytes (defaults to 4k)
|
|
that must contain only zeros for qemu-img to create a sparse image during
|
|
conversion. If @var{sparse_size} is 0, the source will not be scanned for
|
|
unallocated or zero sectors, and the destination image will always be
|
|
fully allocated.
|
|
|
|
You can use the @var{backing_file} option to force the output image to be
|
|
created as a copy on write image of the specified base image; the
|
|
@var{backing_file} should have the same content as the input's base image,
|
|
however the path, image format, etc may differ.
|
|
|
|
If a relative path name is given, the backing file is looked up relative to
|
|
the directory containing @var{output_filename}.
|
|
|
|
If the @code{-n} option is specified, the target volume creation will be
|
|
skipped. This is useful for formats such as @code{rbd} if the target
|
|
volume has already been created with site specific options that cannot
|
|
be supplied through qemu-img.
|
|
|
|
Out of order writes can be enabled with @code{-W} to improve performance.
|
|
This is only recommended for preallocated devices like host devices or other
|
|
raw block devices. Out of order write does not work in combination with
|
|
creating compressed images.
|
|
|
|
@var{num_coroutines} specifies how many coroutines work in parallel during
|
|
the convert process (defaults to 8).
|
|
|
|
@item create [--object @var{objectdef}] [-q] [-f @var{fmt}] [-b @var{backing_file}] [-F @var{backing_fmt}] [-u] [-o @var{options}] @var{filename} [@var{size}]
|
|
|
|
Create the new disk image @var{filename} of size @var{size} and format
|
|
@var{fmt}. Depending on the file format, you can add one or more @var{options}
|
|
that enable additional features of this format.
|
|
|
|
If the option @var{backing_file} is specified, then the image will record
|
|
only the differences from @var{backing_file}. No size needs to be specified in
|
|
this case. @var{backing_file} will never be modified unless you use the
|
|
@code{commit} monitor command (or qemu-img commit).
|
|
|
|
If a relative path name is given, the backing file is looked up relative to
|
|
the directory containing @var{filename}.
|
|
|
|
Note that a given backing file will be opened to check that it is valid. Use
|
|
the @code{-u} option to enable unsafe backing file mode, which means that the
|
|
image will be created even if the associated backing file cannot be opened. A
|
|
matching backing file must be created or additional options be used to make the
|
|
backing file specification valid when you want to use an image created this
|
|
way.
|
|
|
|
The size can also be specified using the @var{size} option with @code{-o},
|
|
it doesn't need to be specified separately in this case.
|
|
|
|
@item dd [--image-opts] [-U] [-f @var{fmt}] [-O @var{output_fmt}] [bs=@var{block_size}] [count=@var{blocks}] [skip=@var{blocks}] if=@var{input} of=@var{output}
|
|
|
|
Dd copies from @var{input} file to @var{output} file converting it from
|
|
@var{fmt} format to @var{output_fmt} format.
|
|
|
|
The data is by default read and written using blocks of 512 bytes but can be
|
|
modified by specifying @var{block_size}. If count=@var{blocks} is specified
|
|
dd will stop reading input after reading @var{blocks} input blocks.
|
|
|
|
The size syntax is similar to dd(1)'s size syntax.
|
|
|
|
@item info [--object @var{objectdef}] [--image-opts] [-f @var{fmt}] [--output=@var{ofmt}] [--backing-chain] [-U] @var{filename}
|
|
|
|
Give information about the disk image @var{filename}. Use it in
|
|
particular to know the size reserved on disk which can be different
|
|
from the displayed size. If VM snapshots are stored in the disk image,
|
|
they are displayed too. The command can output in the format @var{ofmt}
|
|
which is either @code{human} or @code{json}.
|
|
|
|
If a disk image has a backing file chain, information about each disk image in
|
|
the chain can be recursively enumerated by using the option @code{--backing-chain}.
|
|
|
|
For instance, if you have an image chain like:
|
|
|
|
@example
|
|
base.qcow2 <- snap1.qcow2 <- snap2.qcow2
|
|
@end example
|
|
|
|
To enumerate information about each disk image in the above chain, starting from top to base, do:
|
|
|
|
@example
|
|
qemu-img info --backing-chain snap2.qcow2
|
|
@end example
|
|
|
|
@item map [-f @var{fmt}] [--output=@var{ofmt}] @var{filename}
|
|
|
|
Dump the metadata of image @var{filename} and its backing file chain.
|
|
In particular, this commands dumps the allocation state of every sector
|
|
of @var{filename}, together with the topmost file that allocates it in
|
|
the backing file chain.
|
|
|
|
Two option formats are possible. The default format (@code{human})
|
|
only dumps known-nonzero areas of the file. Known-zero parts of the
|
|
file are omitted altogether, and likewise for parts that are not allocated
|
|
throughout the chain. @command{qemu-img} output will identify a file
|
|
from where the data can be read, and the offset in the file. Each line
|
|
will include four fields, the first three of which are hexadecimal
|
|
numbers. For example the first line of:
|
|
@example
|
|
Offset Length Mapped to File
|
|
0 0x20000 0x50000 /tmp/overlay.qcow2
|
|
0x100000 0x10000 0x95380000 /tmp/backing.qcow2
|
|
@end example
|
|
@noindent
|
|
means that 0x20000 (131072) bytes starting at offset 0 in the image are
|
|
available in /tmp/overlay.qcow2 (opened in @code{raw} format) starting
|
|
at offset 0x50000 (327680). Data that is compressed, encrypted, or
|
|
otherwise not available in raw format will cause an error if @code{human}
|
|
format is in use. Note that file names can include newlines, thus it is
|
|
not safe to parse this output format in scripts.
|
|
|
|
The alternative format @code{json} will return an array of dictionaries
|
|
in JSON format. It will include similar information in
|
|
the @code{start}, @code{length}, @code{offset} fields;
|
|
it will also include other more specific information:
|
|
@itemize @minus
|
|
@item
|
|
whether the sectors contain actual data or not (boolean field @code{data};
|
|
if false, the sectors are either unallocated or stored as optimized
|
|
all-zero clusters);
|
|
|
|
@item
|
|
whether the data is known to read as zero (boolean field @code{zero});
|
|
|
|
@item
|
|
in order to make the output shorter, the target file is expressed as
|
|
a @code{depth}; for example, a depth of 2 refers to the backing file
|
|
of the backing file of @var{filename}.
|
|
@end itemize
|
|
|
|
In JSON format, the @code{offset} field is optional; it is absent in
|
|
cases where @code{human} format would omit the entry or exit with an error.
|
|
If @code{data} is false and the @code{offset} field is present, the
|
|
corresponding sectors in the file are not yet in use, but they are
|
|
preallocated.
|
|
|
|
For more information, consult @file{include/block/block.h} in QEMU's
|
|
source code.
|
|
|
|
@item measure [--output=@var{ofmt}] [-O @var{output_fmt}] [-o @var{options}] [--size @var{N} | [--object @var{objectdef}] [--image-opts] [-f @var{fmt}] [-l @var{snapshot_param}] @var{filename}]
|
|
|
|
Calculate the file size required for a new image. This information can be used
|
|
to size logical volumes or SAN LUNs appropriately for the image that will be
|
|
placed in them. The values reported are guaranteed to be large enough to fit
|
|
the image. The command can output in the format @var{ofmt} which is either
|
|
@code{human} or @code{json}.
|
|
|
|
If the size @var{N} is given then act as if creating a new empty image file
|
|
using @command{qemu-img create}. If @var{filename} is given then act as if
|
|
converting an existing image file using @command{qemu-img convert}. The format
|
|
of the new file is given by @var{output_fmt} while the format of an existing
|
|
file is given by @var{fmt}.
|
|
|
|
A snapshot in an existing image can be specified using @var{snapshot_param}.
|
|
|
|
The following fields are reported:
|
|
@example
|
|
required size: 524288
|
|
fully allocated size: 1074069504
|
|
@end example
|
|
|
|
The @code{required size} is the file size of the new image. It may be smaller
|
|
than the virtual disk size if the image format supports compact representation.
|
|
|
|
The @code{fully allocated size} is the file size of the new image once data has
|
|
been written to all sectors. This is the maximum size that the image file can
|
|
occupy with the exception of internal snapshots, dirty bitmaps, vmstate data,
|
|
and other advanced image format features.
|
|
|
|
@item snapshot [--object @var{objectdef}] [--image-opts] [-U] [-q] [-l | -a @var{snapshot} | -c @var{snapshot} | -d @var{snapshot}] @var{filename}
|
|
|
|
List, apply, create or delete snapshots in image @var{filename}.
|
|
|
|
@item rebase [--object @var{objectdef}] [--image-opts] [-U] [-q] [-f @var{fmt}] [-t @var{cache}] [-T @var{src_cache}] [-p] [-u] -b @var{backing_file} [-F @var{backing_fmt}] @var{filename}
|
|
|
|
Changes the backing file of an image. Only the formats @code{qcow2} and
|
|
@code{qed} support changing the backing file.
|
|
|
|
The backing file is changed to @var{backing_file} and (if the image format of
|
|
@var{filename} supports this) the backing file format is changed to
|
|
@var{backing_fmt}. If @var{backing_file} is specified as ``'' (the empty
|
|
string), then the image is rebased onto no backing file (i.e. it will exist
|
|
independently of any backing file).
|
|
|
|
If a relative path name is given, the backing file is looked up relative to
|
|
the directory containing @var{filename}.
|
|
|
|
@var{cache} specifies the cache mode to be used for @var{filename}, whereas
|
|
@var{src_cache} specifies the cache mode for reading backing files.
|
|
|
|
There are two different modes in which @code{rebase} can operate:
|
|
@table @option
|
|
@item Safe mode
|
|
This is the default mode and performs a real rebase operation. The new backing
|
|
file may differ from the old one and qemu-img rebase will take care of keeping
|
|
the guest-visible content of @var{filename} unchanged.
|
|
|
|
In order to achieve this, any clusters that differ between @var{backing_file}
|
|
and the old backing file of @var{filename} are merged into @var{filename}
|
|
before actually changing the backing file.
|
|
|
|
Note that the safe mode is an expensive operation, comparable to converting
|
|
an image. It only works if the old backing file still exists.
|
|
|
|
@item Unsafe mode
|
|
qemu-img uses the unsafe mode if @code{-u} is specified. In this mode, only the
|
|
backing file name and format of @var{filename} is changed without any checks
|
|
on the file contents. The user must take care of specifying the correct new
|
|
backing file, or the guest-visible content of the image will be corrupted.
|
|
|
|
This mode is useful for renaming or moving the backing file to somewhere else.
|
|
It can be used without an accessible old backing file, i.e. you can use it to
|
|
fix an image whose backing file has already been moved/renamed.
|
|
@end table
|
|
|
|
You can use @code{rebase} to perform a ``diff'' operation on two
|
|
disk images. This can be useful when you have copied or cloned
|
|
a guest, and you want to get back to a thin image on top of a
|
|
template or base image.
|
|
|
|
Say that @code{base.img} has been cloned as @code{modified.img} by
|
|
copying it, and that the @code{modified.img} guest has run so there
|
|
are now some changes compared to @code{base.img}. To construct a thin
|
|
image called @code{diff.qcow2} that contains just the differences, do:
|
|
|
|
@example
|
|
qemu-img create -f qcow2 -b modified.img diff.qcow2
|
|
qemu-img rebase -b base.img diff.qcow2
|
|
@end example
|
|
|
|
At this point, @code{modified.img} can be discarded, since
|
|
@code{base.img + diff.qcow2} contains the same information.
|
|
|
|
@item resize [--object @var{objectdef}] [--image-opts] [-f @var{fmt}] [--preallocation=@var{prealloc}] [-q] [--shrink] @var{filename} [+ | -]@var{size}
|
|
|
|
Change the disk image as if it had been created with @var{size}.
|
|
|
|
Before using this command to shrink a disk image, you MUST use file system and
|
|
partitioning tools inside the VM to reduce allocated file systems and partition
|
|
sizes accordingly. Failure to do so will result in data loss!
|
|
|
|
When shrinking images, the @code{--shrink} option must be given. This informs
|
|
qemu-img that the user acknowledges all loss of data beyond the truncated
|
|
image's end.
|
|
|
|
After using this command to grow a disk image, you must use file system and
|
|
partitioning tools inside the VM to actually begin using the new space on the
|
|
device.
|
|
|
|
When growing an image, the @code{--preallocation} option may be used to specify
|
|
how the additional image area should be allocated on the host. See the format
|
|
description in the @code{NOTES} section which values are allowed. Using this
|
|
option may result in slightly more data being allocated than necessary.
|
|
|
|
@end table
|
|
@c man end
|
|
|
|
@ignore
|
|
@c man begin NOTES
|
|
Supported image file formats:
|
|
|
|
@table @option
|
|
@item raw
|
|
|
|
Raw disk image format (default). This format has the advantage of
|
|
being simple and easily exportable to all other emulators. If your
|
|
file system supports @emph{holes} (for example in ext2 or ext3 on
|
|
Linux or NTFS on Windows), then only the written sectors will reserve
|
|
space. Use @code{qemu-img info} to know the real size used by the
|
|
image or @code{ls -ls} on Unix/Linux.
|
|
|
|
Supported options:
|
|
@table @code
|
|
@item preallocation
|
|
Preallocation mode (allowed values: @code{off}, @code{falloc}, @code{full}).
|
|
@code{falloc} mode preallocates space for image by calling posix_fallocate().
|
|
@code{full} mode preallocates space for image by writing zeros to underlying
|
|
storage.
|
|
@end table
|
|
|
|
@item qcow2
|
|
QEMU image format, the most versatile format. Use it to have smaller
|
|
images (useful if your filesystem does not supports holes, for example
|
|
on Windows), optional AES encryption, zlib based compression and
|
|
support of multiple VM snapshots.
|
|
|
|
Supported options:
|
|
@table @code
|
|
@item compat
|
|
Determines the qcow2 version to use. @code{compat=0.10} uses the
|
|
traditional image format that can be read by any QEMU since 0.10.
|
|
@code{compat=1.1} enables image format extensions that only QEMU 1.1 and
|
|
newer understand (this is the default). Amongst others, this includes zero
|
|
clusters, which allow efficient copy-on-read for sparse images.
|
|
|
|
@item backing_file
|
|
File name of a base image (see @option{create} subcommand)
|
|
@item backing_fmt
|
|
Image format of the base image
|
|
@item encryption
|
|
If this option is set to @code{on}, the image is encrypted with 128-bit AES-CBC.
|
|
|
|
The use of encryption in qcow and qcow2 images is considered to be flawed by
|
|
modern cryptography standards, suffering from a number of design problems:
|
|
|
|
@itemize @minus
|
|
@item
|
|
The AES-CBC cipher is used with predictable initialization vectors based
|
|
on the sector number. This makes it vulnerable to chosen plaintext attacks
|
|
which can reveal the existence of encrypted data.
|
|
@item
|
|
The user passphrase is directly used as the encryption key. A poorly
|
|
chosen or short passphrase will compromise the security of the encryption.
|
|
@item
|
|
In the event of the passphrase being compromised there is no way to
|
|
change the passphrase to protect data in any qcow images. The files must
|
|
be cloned, using a different encryption passphrase in the new file. The
|
|
original file must then be securely erased using a program like shred,
|
|
though even this is ineffective with many modern storage technologies.
|
|
@item
|
|
Initialization vectors used to encrypt sectors are based on the
|
|
guest virtual sector number, instead of the host physical sector. When
|
|
a disk image has multiple internal snapshots this means that data in
|
|
multiple physical sectors is encrypted with the same initialization
|
|
vector. With the CBC mode, this opens the possibility of watermarking
|
|
attacks if the attack can collect multiple sectors encrypted with the
|
|
same IV and some predictable data. Having multiple qcow2 images with
|
|
the same passphrase also exposes this weakness since the passphrase
|
|
is directly used as the key.
|
|
@end itemize
|
|
|
|
Use of qcow / qcow2 encryption is thus strongly discouraged. Users are
|
|
recommended to use an alternative encryption technology such as the
|
|
Linux dm-crypt / LUKS system.
|
|
|
|
@item cluster_size
|
|
Changes the qcow2 cluster size (must be between 512 and 2M). Smaller cluster
|
|
sizes can improve the image file size whereas larger cluster sizes generally
|
|
provide better performance.
|
|
|
|
@item preallocation
|
|
Preallocation mode (allowed values: @code{off}, @code{metadata}, @code{falloc},
|
|
@code{full}). An image with preallocated metadata is initially larger but can
|
|
improve performance when the image needs to grow. @code{falloc} and @code{full}
|
|
preallocations are like the same options of @code{raw} format, but sets up
|
|
metadata also.
|
|
|
|
@item lazy_refcounts
|
|
If this option is set to @code{on}, reference count updates are postponed with
|
|
the goal of avoiding metadata I/O and improving performance. This is
|
|
particularly interesting with @option{cache=writethrough} which doesn't batch
|
|
metadata updates. The tradeoff is that after a host crash, the reference count
|
|
tables must be rebuilt, i.e. on the next open an (automatic) @code{qemu-img
|
|
check -r all} is required, which may take some time.
|
|
|
|
This option can only be enabled if @code{compat=1.1} is specified.
|
|
|
|
@item nocow
|
|
If this option is set to @code{on}, it will turn off COW of the file. It's only
|
|
valid on btrfs, no effect on other file systems.
|
|
|
|
Btrfs has low performance when hosting a VM image file, even more when the guest
|
|
on the VM also using btrfs as file system. Turning off COW is a way to mitigate
|
|
this bad performance. Generally there are two ways to turn off COW on btrfs:
|
|
a) Disable it by mounting with nodatacow, then all newly created files will be
|
|
NOCOW. b) For an empty file, add the NOCOW file attribute. That's what this option
|
|
does.
|
|
|
|
Note: this option is only valid to new or empty files. If there is an existing
|
|
file which is COW and has data blocks already, it couldn't be changed to NOCOW
|
|
by setting @code{nocow=on}. One can issue @code{lsattr filename} to check if
|
|
the NOCOW flag is set or not (Capital 'C' is NOCOW flag).
|
|
|
|
@end table
|
|
|
|
@item Other
|
|
QEMU also supports various other image file formats for compatibility with
|
|
older QEMU versions or other hypervisors, including VMDK, VDI, VHD (vpc), VHDX,
|
|
qcow1 and QED. For a full list of supported formats see @code{qemu-img --help}.
|
|
For a more detailed description of these formats, see the QEMU Emulation User
|
|
Documentation.
|
|
|
|
The main purpose of the block drivers for these formats is image conversion.
|
|
For running VMs, it is recommended to convert the disk images to either raw or
|
|
qcow2 in order to achieve good performance.
|
|
@end table
|
|
|
|
|
|
@c man end
|
|
|
|
@setfilename qemu-img
|
|
@settitle QEMU disk image utility
|
|
|
|
@c man begin SEEALSO
|
|
The HTML documentation of QEMU for more precise information and Linux
|
|
user mode emulator invocation.
|
|
@c man end
|
|
|
|
@c man begin AUTHOR
|
|
Fabrice Bellard
|
|
@c man end
|
|
|
|
@end ignore
|