Disk ImagesSince version 0.6.1, QEMU supports many disk image formats, including
growable disk images (their size increase as non empty sectors are
written), compressed and encrypted disk images. Version 0.8.3 added
the new qcow2 disk image format which is essential to support VM
snapshots.
Quick start for disk image creationYou can create a disk image with the command:
qemu-img create myimage.img mysize
where myimage.img is the disk image filename and mysize is its
size in kilobytes. You can add an M suffix to give the size in
megabytes and a G suffix for gigabytes.
See qemu_img_invocation for more information.
Snapshot modeIf you use the option , all disk images are
considered as read only. When sectors in written, they are written in
a temporary file created in /tmp. You can however force the
write back to the raw disk images by using the commit monitor
command (or C-a s in the serial console).
VM snapshotsVM snapshots are snapshots of the complete virtual machine including
CPU state, RAM, device state and the content of all the writable
disks. In order to use VM snapshots, you must have at least one non
removable and writable block device using the qcow2 disk image
format. Normally this device is the first virtual hard drive.
Use the monitor command savevm to create a new VM snapshot or
replace an existing one. A human readable name can be assigned to each
snapshot in addition to its numerical ID.
Use loadvm to restore a VM snapshot and delvm to remove
a VM snapshot. info snapshots lists the available snapshots
with their associated information:
(qemu) info snapshots
Snapshot devices: hda
Snapshot list (from hda):
ID TAG VM SIZE DATE VM CLOCK
1 start 41M 2006-08-06 12:38:02 00:00:14.954
2 40M 2006-08-06 12:43:29 00:00:18.633
3 msys 40M 2006-08-06 12:44:04 00:00:23.514
A VM snapshot is made of a VM state info (its size is shown in
info snapshots) and a snapshot of every writable disk image.
The VM state info is stored in the first qcow2 non removable
and writable block device. The disk image snapshots are stored in
every disk image. The size of a snapshot in a disk image is difficult
to evaluate and is not shown by info snapshots because the
associated disk sectors are shared among all the snapshots to save
disk space (otherwise each snapshot would need a full copy of all the
disk images).
When using the (unrelated) -snapshot option
(disk_images_snapshot_mode), you can always make VM snapshots,
but they are deleted as soon as you exit QEMU.
VM snapshots currently have the following known limitations:
They cannot cope with removable devices if they are removed or
inserted after a snapshot is done.
A few device drivers still have incomplete snapshot support so their
state is not saved or restored properly (in particular USB).
qemu-img Invocationqemu-img [standardoptions] command [commandoptions]
qemu-img allows you to create, convert and modify images offline. It can handle
all image formats supported by QEMU.
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.
Standard options:
Display this help and exit
Display version information and exit
–traceSpecify tracing options.
Immediately enable events matching pattern.
The file must contain one event name (as listed in the trace-events-all
file) per line; globbing patterns are accepted too. This option is only
available if QEMU has been compiled with the simple, stderr
or ftrace tracing backend. To specify multiple events or patterns,
specify the option multiple times.
Use -trace help to print a list of names of trace points.
Immediately enable events listed in file.
The file must contain one event name (as listed in the trace-events-all
file) per line; globbing patterns are accepted too. This option is only
available if QEMU has been compiled with the simple, stderr or
ftrace tracing backend.
Log output traces to file.
This option is only available if QEMU has been compiled with
the simple tracing backend.
The following commands are supported:
Command parameters:
filenameis a disk image filename
–object objectdefis a QEMU user creatable object definition. See the qemu(1) manual
page for a description of the object properties. The most common object
type is a secret, which is used to supply passwords and/or encryption
keys.
–image-optsIndicates that the filename parameter is to be interpreted as a
full option string, not a plain filename. This parameter is mutually
exclusive with the -f and -F parameters.
fmtis the disk image format. It is guessed automatically in most cases. See below
for a description of the supported disk formats.
–backing-chainwill enumerate information about backing files in a disk image chain. Refer
below for further description.
sizeis the disk image size in bytes. Optional suffixes k or K
(kilobyte, 1024) M (megabyte, 1024k) and G (gigabyte, 1024M)
and T (terabyte, 1024G) are supported. b is ignored.
output_filenameis the destination disk image filename
output_fmtis the destination format
optionsis a comma separated list of format specific options in a
name=value format. Use -o ? for an overview of the options supported
by the used format or see the format descriptions below for details.
snapshot_paramis param used for internal snapshot, format is
’snapshot.id=[ID],snapshot.name=[NAME]’ or ’[ID_OR_NAME]’
snapshot_id_or_nameis deprecated, use snapshot_param instead
-cindicates that target image must be compressed (qcow format only)
-hwith or without a command shows help and lists the supported formats
-pdisplay progress bar (compare, convert and rebase commands only).
If the -p option is not used for a command that supports it, the
progress is reported when the process receives a SIGUSR1 signal.
-qQuiet mode - do not print any output (except errors). There’s no progress bar
in case both -q and -p options are used.
-S sizeindicates 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
k for kilobytes.
-t cachespecifies the cache mode that should be used with the (destination) file. See
the documentation of the emulator’s -drive cache=... option for allowed
values.
-T src_cachespecifies the cache mode that should be used with the source file(s). See
the documentation of the emulator’s -drive cache=... option for allowed
values.
Parameters to snapshot subcommand:
is the name of the snapshot to create, apply or delete
applies a snapshot (revert disk to saved state)
creates a snapshot
deletes a snapshot
lists all snapshots in the given image
Parameters to compare subcommand:
First image format
Second image format
Strict mode - fail on different image size or sector allocation
Parameters to convert subcommand:
Skip the creation of the target volume
Parameters to dd subcommand:
defines the block size
sets the number of input blocks to copy
sets the input file
sets the output file
sets the number of input blocks to skip
Command description:
Run a simple sequential I/O benchmark on the specified image. If -w is
specified, a write test is performed, otherwise a read test is performed.
A total number of count I/O requests is performed, each buffer_size
bytes in size, and with depth requests in parallel. The first request
starts at the position given by offset, each following request increases
the current position by step_size. If step_size is not given,
buffer_size is used for its value.
If 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 flush_interval. If additionally
--no-drain is specified, a flush is issued without draining the request
queue first.
If -n is specified, the native AIO backend is used if possible. On
Linux, this option only works if -t none or -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 pattern.
Perform a consistency check on the disk image filename. The command can
output in the format ofmt which is either human or json.
If -r is specified, qemu-img tries to repair any inconsistencies found
during the check. -r leaks repairs only cluster leaks, whereas
-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 qcow2, qed and vdi support
consistency checks.
In case the image does not have any inconsistencies, check exits with 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:
Check completed, the image is (now) consistent
Check not completed because of internal errors
Check completed, image is corrupted
Check completed, image has leaked clusters, but is not corrupted
Checks are not supported by the image format
If -r is specified, exit codes representing the image state refer to the
state after (the attempt at) repairing it. That is, a successful -r all
will yield the exit code 0, independently of the image state before.
Create the new disk image filename of size size and format
fmt. Depending on the file format, you can add one or more options
that enable additional features of this format.
If the option backing_file is specified, then the image will record
only the differences from backing_file. No size needs to be specified in
this case. backing_file will never be modified unless you use the
commit monitor command (or qemu-img commit).
The size can also be specified using the size option with -o,
it doesn’t need to be specified separately in this case.
Commit the changes recorded in 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 filename is emptied after the operation has succeeded. If you do
not need filename afterwards and intend to drop it, you may skip emptying
filename by specifying the -d flag.
If the backing chain of the given image file filename has more than one
layer, the backing file into which the changes will be committed may be
specified as base (which has to be part of filename’s backing
chain). If base is not specified, the immediate backing file of the top
image (which is filename) will be used. For reasons of consistency,
explicitly specifying base will always imply -d (since emptying an
image after committing to an indirect backing file would lead to different data
being read from the image due to content in the intermediate backing chain
overruling the commit target).
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 -f (used for
filename1) and/or -F (used for 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 -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 0 in case the images are equal and with 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:
Images are identical
Images differ
Error on opening an image
Error on checking a sector allocation
Error on reading data
Convert the disk image filename or a snapshot snapshot_param(snapshot_id_or_name is deprecated)
to disk image output_filename using format output_fmt. It can be optionally compressed (-c
option) or use any format specific options like encryption (-o option).
Only the formats qcow and 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 qcow: the empty sectors are detected and
suppressed from the destination image.
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 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 backing_file option to force the output image to be
created as a copy on write image of the specified base image; the
backing_file should have the same content as the input’s base image,
however the path, image format, etc may differ.
If the -n option is specified, the target volume creation will be
skipped. This is useful for formats such as rbd if the target
volume has already been created with site specific options that cannot
be supplied through qemu-img.
Dd copies from input file to output file converting it from
fmt format to output_fmt format.
The data is by default read and written using blocks of 512 bytes but can be
modified by specifying block_size. If count=blocks is specified
dd will stop reading input after reading blocks input blocks.
The size syntax is similar to dd(1)’s size syntax.
Give information about the disk image 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 ofmt
which is either human or 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 --backing-chain.
For instance, if you have an image chain like:
base.qcow2 <- snap1.qcow2 <- snap2.qcow2
To enumerate information about each disk image in the above chain, starting from top to base, do:
qemu-img info --backing-chain snap2.qcow2
Dump the metadata of image filename and its backing file chain.
In particular, this commands dumps the allocation state of every sector
of filename, together with the topmost file that allocates it in
the backing file chain.
Two option formats are possible. The default format (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. 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:
Offset Length Mapped to File
0 0x20000 0x50000 /tmp/overlay.qcow2
0x100000 0x10000 0x95380000 /tmp/backing.qcow2
means that 0x20000 (131072) bytes starting at offset 0 in the image are
available in /tmp/overlay.qcow2 (opened in raw format) starting
at offset 0x50000 (327680). Data that is compressed, encrypted, or
otherwise not available in raw format will cause an error if 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 json will return an array of dictionaries
in JSON format. It will include similar information in
the start, length, offset fields;
it will also include other more specific information:
− whether the sectors contain actual data or not (boolean field data;
if false, the sectors are either unallocated or stored as optimized
all-zero clusters);
− whether the data is known to read as zero (boolean field zero);
− in order to make the output shorter, the target file is expressed as
a depth; for example, a depth of 2 refers to the backing file
of the backing file of filename.
In JSON format, the offset field is optional; it is absent in
cases where human format would omit the entry or exit with an error.
If data is false and the offset field is present, the
corresponding sectors in the file are not yet in use, but they are
preallocated.
For more information, consult include/block/block.h in QEMU’s
source code.
List, apply, create or delete snapshots in image filename.
Changes the backing file of an image. Only the formats qcow2 and
qed support changing the backing file.
The backing file is changed to backing_file and (if the image format of
filename supports this) the backing file format is changed to
backing_fmt. If 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).
cache specifies the cache mode to be used for filename, whereas
src_cache specifies the cache mode for reading backing files.
There are two different modes in which rebase can operate:
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 filename unchanged.
In order to achieve this, any clusters that differ between backing_file
and the old backing file of filename are merged into 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.
qemu-img uses the unsafe mode if -u is specified. In this mode, only the
backing file name and format of 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.
You can use 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 base.img has been cloned as modified.img by
copying it, and that the modified.img guest has run so there
are now some changes compared to base.img. To construct a thin
image called diff.qcow2 that contains just the differences, do:
qemu-img create -f qcow2 -b modified.img diff.qcow2
qemu-img rebase -b base.img diff.qcow2
At this point, modified.img can be discarded, since
base.img + diff.qcow2 contains the same information.
Change the disk image as if it had been created with 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!
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.
Amends the image format specific options for the image file
filename. Not all file formats support this operation.
qemu-nbd Invocationqemu-nbd [OPTION]... filenameqemu-nbddevExport a QEMU disk image using the NBD protocol.
filename is a disk image filename, or a set of block
driver options if –image-opts is specified.
dev is an NBD device.
Define a new instance of the type object class identified by id.
See the qemu(1) manual page for full details of the properties
supported. The common object types that it makes sense to define are the
secret object, which is used to supply passwords and/or encryption
keys, and the tls-creds object, which is used to supply TLS
credentials for the qemu-nbd server.
The TCP port to listen on (default ‘10809’)
The offset into the image
The interface to bind to (default ‘0.0.0.0’)
Use a unix socket with path pathTreat filename as a set of image options, instead of a plain
filename. If this flag is specified, the -f flag should
not be used, instead the ’format=’ option should be set.
Force the use of the block driver for format fmt instead of
auto-detecting
Export the disk as read-only
Only expose partition numUse filename as an external snapshot, create a temporary
file with backing_file=filename, redirect the write to
the temporary one
Load an internal snapshot inside filename and export it
as an read-only device, snapshot_param format is
’snapshot.id=[ID],snapshot.name=[NAME]’ or ’[ID_OR_NAME]’
The cache mode to be used with the file. See the documentation of
the emulator’s -drive cache=... option for allowed values.
Set the asynchronous I/O mode between ‘threads’ (the default)
and ‘native’ (Linux only).
Control whether discard (also known as trim or unmap)
requests are ignored or passed to the filesystem. discard is one of
‘ignore’ (or ‘off’), ‘unmap’ (or ‘on’). The default is
‘ignore’.
Control the automatic conversion of plain zero writes by the OS to
driver-specific optimized zero write commands. detect-zeroes is one of
‘off’, ‘on’ or ‘unmap’. ‘unmap’
converts a zero write to an unmap operation and can only be used if
discard is set to ‘unmap’. The default is ‘off’.
Connect filename to NBD device devDisconnect the device devAllow up to num clients to share the device (default ‘1’)
Don’t exit on the last connection
Set the NBD volume export name. This switches the server to use
the new style NBD protocol negotiation
Set the NBD volume export description, as a human-readable
string. Requires the use of
Enable mandatory TLS encryption for the server by setting the ID
of the TLS credentials object previously created with the –object
option.
Fork off the server process and exit the parent once the server is running.
Display extra debugging information
Display this help and exit
Display version information and exit
–traceSpecify tracing options.
Immediately enable events matching pattern.
The file must contain one event name (as listed in the trace-events-all
file) per line; globbing patterns are accepted too. This option is only
available if QEMU has been compiled with the simple, stderr
or ftrace tracing backend. To specify multiple events or patterns,
specify the option multiple times.
Use -trace help to print a list of names of trace points.
Immediately enable events listed in file.
The file must contain one event name (as listed in the trace-events-all
file) per line; globbing patterns are accepted too. This option is only
available if QEMU has been compiled with the simple, stderr or
ftrace tracing backend.
Log output traces to file.
This option is only available if QEMU has been compiled with
the simple tracing backend.
qemu-ga Invocationqemu-ga [OPTIONS]
The QEMU Guest Agent is a daemon intended to be run within virtual
machines. It allows the hypervisor host to perform various operations
in the guest, such as:
get information from the guest
set the guest’s system time
read/write a file
sync and freeze the filesystems
suspend the guest
reconfigure guest local processors
set user’s password
...
qemu-ga will read a system configuration file on startup (located at
/etc/qemu/qemu-ga.conf by default), then parse remaining
configuration options on the command line. For the same key, the last
option wins, but the lists accumulate (see below for configuration
file format).
Transport method: one of ‘unix-listen’, ‘virtio-serial’, or
‘isa-serial’ (‘virtio-serial’ is the default).
Device/socket path (the default for virtio-serial is
‘/dev/virtio-ports/org.qemu.guest_agent.0’,
the default for isa-serial is ‘/dev/ttyS0’)
Set log file path (default is stderr).
Specify pid file (default is ‘/var/run/qemu-ga.pid’).
Enable fsfreeze hook. Accepts an optional argument that specifies
script to run on freeze/thaw. Script will be called with
’freeze’/’thaw’ arguments accordingly (default is
‘/etc/qemu/fsfreeze-hook’). If using -F with an argument, do
not follow -F with a space (for example:
‘-F/var/run/fsfreezehook.sh’).
Specify the directory to store state information (absolute paths only,
default is ‘/var/run’).
Log extra debugging information.
Print version information and exit.
Daemonize after startup (detach from terminal).
Comma-separated list of RPCs to disable (no spaces, ‘?’ to list
available RPCs).
Dump the configuration in a format compatible with qemu-ga.conf
and exit.
Display this help and exit.
The syntax of the qemu-ga.conf configuration file follows the
Desktop Entry Specification, here is a quick summary: it consists of
groups of key-value pairs, interspersed with comments.
# qemu-ga configuration sample
[general]
daemonize = 0
pidfile = /var/run/qemu-ga.pid
verbose = 0
method = virtio-serial
path = /dev/virtio-ports/org.qemu.guest_agent.0
statedir = /var/run
The list of keys follows the command line options:
Disk image file formatsQEMU supports many image file formats that can be used with VMs as well as with
any of the tools (like qemu-img). This includes the preferred formats
raw and qcow2 as well as formats that are supported for compatibility with
older QEMU versions or other hypervisors.
Depending on the image format, different options can be passed to
qemu-img create and qemu-img convert using the -o option.
This section describes each format and the options that are supported for it.
Raw disk image format. This format has the advantage of
being simple and easily exportable to all other emulators. If your
file system supports holes (for example in ext2 or ext3 on
Linux or NTFS on Windows), then only the written sectors will reserve
space. Use qemu-img info to know the real size used by the
image or ls -ls on Unix/Linux.
Supported options:
preallocationPreallocation mode (allowed values: off, falloc, full).
falloc mode preallocates space for image by calling posix_fallocate().
full mode preallocates space for image by writing zeros to underlying
storage.
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), zlib based compression and support of multiple VM
snapshots.
Supported options:
compatDetermines the qcow2 version to use. compat=0.10 uses the
traditional image format that can be read by any QEMU since 0.10.
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.
backing_fileFile name of a base image (see subcommand)
backing_fmtImage format of the base image
encryptionIf this option is set to 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:
− 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.
− The user passphrase is directly used as the encryption key. A poorly
chosen or short passphrase will compromise the security of the encryption.
− 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.
Use of qcow / qcow2 encryption with QEMU is deprecated, and support for
it will go away in a future release. Users are recommended to use an
alternative encryption technology such as the Linux dm-crypt / LUKS
system.
cluster_sizeChanges 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.
preallocationPreallocation mode (allowed values: off, metadata, falloc,
full). An image with preallocated metadata is initially larger but can
improve performance when the image needs to grow. falloc and full
preallocations are like the same options of raw format, but sets up
metadata also.
lazy_refcountsIf this option is set to on, reference count updates are postponed with
the goal of avoiding metadata I/O and improving performance. This is
particularly interesting with 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) qemu-img
check -r all is required, which may take some time.
This option can only be enabled if compat=1.1 is specified.
nocowIf this option is set to 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 nocow=on. One can issue lsattr filename to check if
the NOCOW flag is set or not (Capital ’C’ is NOCOW flag).
Old QEMU image format with support for backing files and compact image files
(when your filesystem or transport medium does not support holes).
When converting QED images to qcow2, you might want to consider using the
lazy_refcounts=on option to get a more QED-like behaviour.
Supported options:
backing_fileFile name of a base image (see subcommand).
backing_fmtImage file format of backing file (optional). Useful if the format cannot be
autodetected because it has no header, like some vhd/vpc files.
cluster_sizeChanges the cluster size (must be power-of-2 between 4K and 64K). Smaller
cluster sizes can improve the image file size whereas larger cluster sizes
generally provide better performance.
table_sizeChanges the number of clusters per L1/L2 table (must be power-of-2 between 1
and 16). There is normally no need to change this value but this option can be
used for performance benchmarking.
Old QEMU image format with support for backing files, compact image files,
encryption and compression.
Supported options:
backing_fileFile name of a base image (see subcommand)
encryptionIf this option is set to on, the image is encrypted.
VirtualBox 1.1 compatible image format.
Supported options:
staticIf this option is set to on, the image is created with metadata
preallocation.
VMware 3 and 4 compatible image format.
Supported options:
backing_fileFile name of a base image (see subcommand).
compat6Create a VMDK version 6 image (instead of version 4)
hwversionSpecify vmdk virtual hardware version. Compat6 flag cannot be enabled
if hwversion is specified.
subformatSpecifies which VMDK subformat to use. Valid options are
monolithicSparse (default),
monolithicFlat,
twoGbMaxExtentSparse,
twoGbMaxExtentFlat and
streamOptimized.
VirtualPC compatible image format (VHD).
Supported options:
subformatSpecifies which VHD subformat to use. Valid options are
dynamic (default) and fixed.
Hyper-V compatible image format (VHDX).
Supported options:
subformatSpecifies which VHDX subformat to use. Valid options are
dynamic (default) and fixed.
block_state_zeroForce use of payload blocks of type ’ZERO’. Can be set to on (default)
or off. When set to off, new blocks will be created as
PAYLOAD_BLOCK_NOT_PRESENT, which means parsers are free to return
arbitrary data for those blocks. Do not set to off when using
qemu-img convert with subformat=dynamic.
block_sizeBlock size; min 1 MB, max 256 MB. 0 means auto-calculate based on image size.
log_sizeLog size; min 1 MB.
Read-only formatsMore disk image file formats are supported in a read-only mode.
Bochs images of growing type.
Linux Compressed Loop image, useful only to reuse directly compressed
CD-ROM images present for example in the Knoppix CD-ROMs.
Apple disk image.
Parallels disk image format.
Using host drivesIn addition to disk image files, QEMU can directly access host
devices. We describe here the usage for QEMU version >= 0.8.3.
LinuxOn Linux, you can directly use the host device filename instead of a
disk image filename provided you have enough privileges to access
it. For example, use /dev/cdrom to access to the CDROM.
CDYou can specify a CDROM device even if no CDROM is loaded. QEMU has
specific code to detect CDROM insertion or removal. CDROM ejection by
the guest OS is supported. Currently only data CDs are supported.
FloppyYou can specify a floppy device even if no floppy is loaded. Floppy
removal is currently not detected accurately (if you change floppy
without doing floppy access while the floppy is not loaded, the guest
OS will think that the same floppy is loaded).
Use of the host’s floppy device is deprecated, and support for it will
be removed in a future release.
Hard disksHard disks can be used. Normally you must specify the whole disk
(/dev/hdb instead of /dev/hdb1) so that the guest OS can
see it as a partitioned disk. WARNING: unless you know what you do, it
is better to only make READ-ONLY accesses to the hard disk otherwise
you may corrupt your host data (use the command
line option or modify the device permissions accordingly).
WindowsCDThe preferred syntax is the drive letter (e.g. d:). The
alternate syntax \\.\d: is supported. /dev/cdrom is
supported as an alias to the first CDROM drive.
Currently there is no specific code to handle removable media, so it
is better to use the change or eject monitor commands to
change or eject media.
Hard disksHard disks can be used with the syntax: \\.\PhysicalDriveN
where N is the drive number (0 is the first hard disk).
WARNING: unless you know what you do, it is better to only make
READ-ONLY accesses to the hard disk otherwise you may corrupt your
host data (use the command line so that the
modifications are written in a temporary file).
Mac OS X/dev/cdrom is an alias to the first CDROM.
Currently there is no specific code to handle removable media, so it
is better to use the change or eject monitor commands to
change or eject media.
Virtual FAT disk imagesQEMU can automatically create a virtual FAT disk image from a
directory tree. In order to use it, just type:
qemu-system-i386 linux.img -hdb fat:/my_directory
Then you access access to all the files in the /my_directory
directory without having to copy them in a disk image or to export
them via SAMBA or NFS. The default access is read-only.
Floppies can be emulated with the :floppy: option:
qemu-system-i386 linux.img -fda fat:floppy:/my_directory
A read/write support is available for testing (beta stage) with the
:rw: option:
qemu-system-i386 linux.img -fda fat:floppy:rw:/my_directory
What you should never do:
use non-ASCII filenames ;
use "-snapshot" together with ":rw:" ;
expect it to work when loadvm’ing ;
write to the FAT directory on the host system while accessing it with the guest system.
NBD accessQEMU can access directly to block device exported using the Network Block Device
protocol.
qemu-system-i386 linux.img -hdb nbd://my_nbd_server.mydomain.org:1024/
If the NBD server is located on the same host, you can use an unix socket instead
of an inet socket:
qemu-system-i386 linux.img -hdb nbd+unix://?socket=/tmp/my_socket
In this case, the block device must be exported using qemu-nbd:
qemu-nbd --socket=/tmp/my_socket my_disk.qcow2
The use of qemu-nbd allows sharing of a disk between several guests:
qemu-nbd --socket=/tmp/my_socket --share=2 my_disk.qcow2
and then you can use it with two guests:
qemu-system-i386 linux1.img -hdb nbd+unix://?socket=/tmp/my_socket
qemu-system-i386 linux2.img -hdb nbd+unix://?socket=/tmp/my_socket
If the nbd-server uses named exports (supported since NBD 2.9.18, or with QEMU’s
own embedded NBD server), you must specify an export name in the URI:
qemu-system-i386 -cdrom nbd://localhost/debian-500-ppc-netinst
qemu-system-i386 -cdrom nbd://localhost/openSUSE-11.1-ppc-netinst
The URI syntax for NBD is supported since QEMU 1.3. An alternative syntax is
also available. Here are some example of the older syntax:
qemu-system-i386 linux.img -hdb nbd:my_nbd_server.mydomain.org:1024
qemu-system-i386 linux2.img -hdb nbd:unix:/tmp/my_socket
qemu-system-i386 -cdrom nbd:localhost:10809:exportname=debian-500-ppc-netinst
Sheepdog disk imagesSheepdog is a distributed storage system for QEMU. It provides highly
available block level storage volumes that can be attached to
QEMU-based virtual machines.
You can create a Sheepdog disk image with the command:
qemu-img create sheepdog:///imagesizewhere image is the Sheepdog image name and size is its
size.
To import the existing filename to Sheepdog, you can use a
convert command.
qemu-img convert filename sheepdog:///imageYou can boot from the Sheepdog disk image with the command:
qemu-system-i386 sheepdog:///imageYou can also create a snapshot of the Sheepdog image like qcow2.
qemu-img snapshot -c tag sheepdog:///imagewhere tag is a tag name of the newly created snapshot.
To boot from the Sheepdog snapshot, specify the tag name of the
snapshot.
qemu-system-i386 sheepdog:///image#tagYou can create a cloned image from the existing snapshot.
qemu-img create -b sheepdog:///base#tag sheepdog:///imagewhere base is a image name of the source snapshot and tag
is its tag name.
You can use an unix socket instead of an inet socket:
qemu-system-i386 sheepdog+unix:///image?socket=pathIf the Sheepdog daemon doesn’t run on the local host, you need to
specify one of the Sheepdog servers to connect to.
qemu-img create sheepdog://hostname:port/imagesize
qemu-system-i386 sheepdog://hostname:port/imageiSCSI LUNsiSCSI is a popular protocol used to access SCSI devices across a computer
network.
There are two different ways iSCSI devices can be used by QEMU.
The first method is to mount the iSCSI LUN on the host, and make it appear as
any other ordinary SCSI device on the host and then to access this device as a
/dev/sd device from QEMU. How to do this differs between host OSes.
The second method involves using the iSCSI initiator that is built into
QEMU. This provides a mechanism that works the same way regardless of which
host OS you are running QEMU on. This section will describe this second method
of using iSCSI together with QEMU.
In QEMU, iSCSI devices are described using special iSCSI URLs
URL syntax:
iscsi://[<username>[%<password>]@]<host>[:<port>]/<target-iqn-name>/<lun>
Username and password are optional and only used if your target is set up
using CHAP authentication for access control.
Alternatively the username and password can also be set via environment
variables to have these not show up in the process list
export LIBISCSI_CHAP_USERNAME=<username>
export LIBISCSI_CHAP_PASSWORD=<password>
iscsi://<host>/<target-iqn-name>/<lun>
Various session related parameters can be set via special options, either
in a configuration file provided via ’-readconfig’ or directly on the
command line.
If the initiator-name is not specified qemu will use a default name
of ’iqn.2008-11.org.linux-kvm[:<name>’] where <name> is the name of the
virtual machine.
Setting a specific initiator name to use when logging in to the target
-iscsi initiator-name=iqn.qemu.test:my-initiator
Controlling which type of header digest to negotiate with the target
-iscsi header-digest=CRC32C|CRC32C-NONE|NONE-CRC32C|NONE
These can also be set via a configuration file
[iscsi]
user = "CHAP username"
password = "CHAP password"
initiator-name = "iqn.qemu.test:my-initiator"
# header digest is one of CRC32C|CRC32C-NONE|NONE-CRC32C|NONE
header-digest = "CRC32C"
Setting the target name allows different options for different targets
[iscsi "iqn.target.name"]
user = "CHAP username"
password = "CHAP password"
initiator-name = "iqn.qemu.test:my-initiator"
# header digest is one of CRC32C|CRC32C-NONE|NONE-CRC32C|NONE
header-digest = "CRC32C"
Howto use a configuration file to set iSCSI configuration options:
cat >iscsi.conf <<EOF
[iscsi]
user = "me"
password = "my password"
initiator-name = "iqn.qemu.test:my-initiator"
header-digest = "CRC32C"
EOF
qemu-system-i386 -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \
-readconfig iscsi.conf
Howto set up a simple iSCSI target on loopback and accessing it via QEMU:
This example shows how to set up an iSCSI target with one CDROM and one DISK
using the Linux STGT software target. This target is available on Red Hat based
systems as the package 'scsi-target-utils'.
tgtd --iscsi portal=127.0.0.1:3260
tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.qemu.test
tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 1 \
-b /IMAGES/disk.img --device-type=disk
tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 2 \
-b /IMAGES/cd.iso --device-type=cd
tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL
qemu-system-i386 -iscsi initiator-name=iqn.qemu.test:my-initiator \
-boot d -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \
-cdrom iscsi://127.0.0.1/iqn.qemu.test/2
GlusterFS disk imagesGlusterFS is an user space distributed file system.
You can boot from the GlusterFS disk image with the command:
qemu-system-x86_64 -drive file=gluster[+transport]://[server[:port]]/volname/image[?socket=...]
gluster is the protocol.
transport specifies the transport type used to connect to gluster
management daemon (glusterd). Valid transport types are
tcp, unix and rdma. If a transport type isn’t specified, then tcp
type is assumed.
server specifies the server where the volume file specification for
the given volume resides. This can be either hostname, ipv4 address
or ipv6 address. ipv6 address needs to be within square brackets [ ].
If transport type is unix, then server field should not be specified.
Instead socket field needs to be populated with the path to unix domain
socket.
port is the port number on which glusterd is listening. This is optional
and if not specified, QEMU will send 0 which will make gluster to use the
default port. If the transport type is unix, then port should not be
specified.
volname is the name of the gluster volume which contains the disk image.
image is the path to the actual disk image that resides on gluster volume.
You can create a GlusterFS disk image with the command:
qemu-img create gluster://server/volname/imagesizeExamples
qemu-system-x86_64 -drive file=gluster://1.2.3.4/testvol/a.img
qemu-system-x86_64 -drive file=gluster+tcp://1.2.3.4/testvol/a.img
qemu-system-x86_64 -drive file=gluster+tcp://1.2.3.4:24007/testvol/dir/a.img
qemu-system-x86_64 -drive file=gluster+tcp://[1:2:3:4:5:6:7:8]/testvol/dir/a.img
qemu-system-x86_64 -drive file=gluster+tcp://[1:2:3:4:5:6:7:8]:24007/testvol/dir/a.img
qemu-system-x86_64 -drive file=gluster+tcp://server.domain.com:24007/testvol/dir/a.img
qemu-system-x86_64 -drive file=gluster+unix:///testvol/dir/a.img?socket=/tmp/glusterd.socket
qemu-system-x86_64 -drive file=gluster+rdma://1.2.3.4:24007/testvol/a.img
Secure Shell (ssh) disk imagesYou can access disk images located on a remote ssh server
by using the ssh protocol:
qemu-system-x86_64 -drive file=ssh://[user@]server[:port]/path[?host_key_check=host_key_check]
Alternative syntax using properties:
qemu-system-x86_64 -drive file.driver=ssh[,file.user=user],file.host=server[,file.port=port],file.path=path[,file.host_key_check=host_key_check]
ssh is the protocol.
user is the remote user. If not specified, then the local
username is tried.
server specifies the remote ssh server. Any ssh server can be
used, but it must implement the sftp-server protocol. Most Unix/Linux
systems should work without requiring any extra configuration.
port is the port number on which sshd is listening. By default
the standard ssh port (22) is used.
path is the path to the disk image.
The optional host_key_check parameter controls how the remote
host’s key is checked. The default is yes which means to use
the local .ssh/known_hosts file. Setting this to no
turns off known-hosts checking. Or you can check that the host key
matches a specific fingerprint:
host_key_check=md5:78:45:8e:14:57:4f:d5:45:83:0a:0e:f3:49:82:c9:c8
(sha1: can also be used as a prefix, but note that OpenSSH
tools only use MD5 to print fingerprints).
Currently authentication must be done using ssh-agent. Other
authentication methods may be supported in future.
Note: Many ssh servers do not support an fsync-style operation.
The ssh driver cannot guarantee that disk flush requests are
obeyed, and this causes a risk of disk corruption if the remote
server or network goes down during writes. The driver will
print a warning when fsync is not supported:
warning: ssh server ssh.example.com:22 does not support fsync
With sufficiently new versions of libssh2 and OpenSSH, fsync is
supported.