933 lines
32 KiB
PHP
933 lines
32 KiB
PHP
Disk image file formats
|
||
~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
QEMU 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.
|
||
|
||
.. program:: image-formats
|
||
.. option:: raw
|
||
|
||
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:
|
||
|
||
.. program:: raw
|
||
.. option:: preallocation
|
||
|
||
Preallocation mode (allowed values: ``off``, ``falloc``,
|
||
``full``). ``falloc`` mode preallocates space for image by
|
||
calling ``posix_fallocate()``. ``full`` mode preallocates space
|
||
for image by writing data to underlying storage. This data may or
|
||
may not be zero, depending on the storage location.
|
||
|
||
.. program:: image-formats
|
||
.. option:: 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), zlib based compression and support of multiple VM
|
||
snapshots.
|
||
|
||
Supported options:
|
||
|
||
.. program:: qcow2
|
||
.. option:: compat
|
||
|
||
Determines 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.
|
||
|
||
.. option:: backing_file
|
||
|
||
File name of a base image (see ``create`` subcommand)
|
||
|
||
.. option:: backing_fmt
|
||
|
||
Image format of the base image
|
||
|
||
.. option:: encryption
|
||
|
||
This option is deprecated and equivalent to ``encrypt.format=aes``
|
||
|
||
.. option:: encrypt.format
|
||
|
||
If this is set to ``luks``, it requests that the qcow2 payload (not
|
||
qcow2 header) be encrypted using the LUKS format. The passphrase to
|
||
use to unlock the LUKS key slot is given by the ``encrypt.key-secret``
|
||
parameter. LUKS encryption parameters can be tuned with the other
|
||
``encrypt.*`` parameters.
|
||
|
||
If this is set to ``aes``, the image is encrypted with 128-bit AES-CBC.
|
||
The encryption key is given by the ``encrypt.key-secret`` parameter.
|
||
This encryption format 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.
|
||
|
||
The use of this is no longer supported in system emulators. Support only
|
||
remains in the command line utilities, for the purposes of data liberation
|
||
and interoperability with old versions of QEMU. The ``luks`` format
|
||
should be used instead.
|
||
|
||
.. option:: encrypt.key-secret
|
||
|
||
Provides the ID of a ``secret`` object that contains the passphrase
|
||
(``encrypt.format=luks``) or encryption key (``encrypt.format=aes``).
|
||
|
||
.. option:: encrypt.cipher-alg
|
||
|
||
Name of the cipher algorithm and key length. Currently defaults
|
||
to ``aes-256``. Only used when ``encrypt.format=luks``.
|
||
|
||
.. option:: encrypt.cipher-mode
|
||
|
||
Name of the encryption mode to use. Currently defaults to ``xts``.
|
||
Only used when ``encrypt.format=luks``.
|
||
|
||
.. option:: encrypt.ivgen-alg
|
||
|
||
Name of the initialization vector generator algorithm. Currently defaults
|
||
to ``plain64``. Only used when ``encrypt.format=luks``.
|
||
|
||
.. option:: encrypt.ivgen-hash-alg
|
||
|
||
Name of the hash algorithm to use with the initialization vector generator
|
||
(if required). Defaults to ``sha256``. Only used when ``encrypt.format=luks``.
|
||
|
||
.. option:: encrypt.hash-alg
|
||
|
||
Name of the hash algorithm to use for PBKDF algorithm
|
||
Defaults to ``sha256``. Only used when ``encrypt.format=luks``.
|
||
|
||
.. option:: encrypt.iter-time
|
||
|
||
Amount of time, in milliseconds, to use for PBKDF algorithm per key slot.
|
||
Defaults to ``2000``. Only used when ``encrypt.format=luks``.
|
||
|
||
.. option:: 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.
|
||
|
||
.. option:: preallocation
|
||
|
||
Preallocation 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.
|
||
|
||
.. option:: lazy_refcounts
|
||
|
||
If 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 :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) ``qemu-img
|
||
check -r all`` is required, which may take some time.
|
||
|
||
This option can only be enabled if ``compat=1.1`` is specified.
|
||
|
||
.. option:: nocow
|
||
|
||
If 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:
|
||
|
||
- Disable it by mounting with nodatacow, then all newly created files
|
||
will be NOCOW.
|
||
- 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).
|
||
|
||
.. program:: image-formats
|
||
.. option:: qed
|
||
|
||
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:
|
||
|
||
.. program:: qed
|
||
.. option:: backing_file
|
||
|
||
File name of a base image (see ``create`` subcommand).
|
||
|
||
.. option:: backing_fmt
|
||
|
||
Image file format of backing file (optional). Useful if the format cannot be
|
||
autodetected because it has no header, like some vhd/vpc files.
|
||
|
||
.. option:: cluster_size
|
||
|
||
Changes 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.
|
||
|
||
.. option:: table_size
|
||
|
||
Changes 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 between used for
|
||
performance benchmarking.
|
||
|
||
.. program:: image-formats
|
||
.. option:: qcow
|
||
|
||
Old QEMU image format with support for backing files, compact image files,
|
||
encryption and compression.
|
||
|
||
Supported options:
|
||
|
||
.. program:: qcow
|
||
.. option:: backing_file
|
||
|
||
File name of a base image (see ``create`` subcommand)
|
||
|
||
.. option:: encryption
|
||
|
||
This option is deprecated and equivalent to ``encrypt.format=aes``
|
||
|
||
.. option:: encrypt.format
|
||
|
||
If this is set to ``aes``, the image is encrypted with 128-bit AES-CBC.
|
||
The encryption key is given by the ``encrypt.key-secret`` parameter.
|
||
This encryption format is considered to be flawed by modern cryptography
|
||
standards, suffering from a number of design problems enumerated previously
|
||
against the ``qcow2`` image format.
|
||
|
||
The use of this is no longer supported in system emulators. Support only
|
||
remains in the command line utilities, for the purposes of data liberation
|
||
and interoperability with old versions of QEMU.
|
||
|
||
Users requiring native encryption should use the ``qcow2`` format
|
||
instead with ``encrypt.format=luks``.
|
||
|
||
.. option:: encrypt.key-secret
|
||
|
||
Provides the ID of a ``secret`` object that contains the encryption
|
||
key (``encrypt.format=aes``).
|
||
|
||
.. program:: image-formats
|
||
.. option:: luks
|
||
|
||
LUKS v1 encryption format, compatible with Linux dm-crypt/cryptsetup
|
||
|
||
Supported options:
|
||
|
||
.. program:: luks
|
||
.. option:: key-secret
|
||
|
||
Provides the ID of a ``secret`` object that contains the passphrase.
|
||
|
||
.. option:: cipher-alg
|
||
|
||
Name of the cipher algorithm and key length. Currently defaults
|
||
to ``aes-256``.
|
||
|
||
.. option:: cipher-mode
|
||
|
||
Name of the encryption mode to use. Currently defaults to ``xts``.
|
||
|
||
.. option:: ivgen-alg
|
||
|
||
Name of the initialization vector generator algorithm. Currently defaults
|
||
to ``plain64``.
|
||
|
||
.. option:: ivgen-hash-alg
|
||
|
||
Name of the hash algorithm to use with the initialization vector generator
|
||
(if required). Defaults to ``sha256``.
|
||
|
||
.. option:: hash-alg
|
||
|
||
Name of the hash algorithm to use for PBKDF algorithm
|
||
Defaults to ``sha256``.
|
||
|
||
.. option:: iter-time
|
||
|
||
Amount of time, in milliseconds, to use for PBKDF algorithm per key slot.
|
||
Defaults to ``2000``.
|
||
|
||
.. program:: image-formats
|
||
.. option:: vdi
|
||
|
||
VirtualBox 1.1 compatible image format.
|
||
|
||
Supported options:
|
||
|
||
.. program:: vdi
|
||
.. option:: static
|
||
|
||
If this option is set to ``on``, the image is created with metadata
|
||
preallocation.
|
||
|
||
.. program:: image-formats
|
||
.. option:: vmdk
|
||
|
||
VMware 3 and 4 compatible image format.
|
||
|
||
Supported options:
|
||
|
||
.. program: vmdk
|
||
.. option:: backing_file
|
||
|
||
File name of a base image (see ``create`` subcommand).
|
||
|
||
.. option:: compat6
|
||
|
||
Create a VMDK version 6 image (instead of version 4)
|
||
|
||
.. option:: hwversion
|
||
|
||
Specify vmdk virtual hardware version. Compat6 flag cannot be enabled
|
||
if hwversion is specified.
|
||
|
||
.. option:: subformat
|
||
|
||
Specifies which VMDK subformat to use. Valid options are
|
||
``monolithicSparse`` (default),
|
||
``monolithicFlat``,
|
||
``twoGbMaxExtentSparse``,
|
||
``twoGbMaxExtentFlat`` and
|
||
``streamOptimized``.
|
||
|
||
.. program:: image-formats
|
||
.. option:: vpc
|
||
|
||
VirtualPC compatible image format (VHD).
|
||
|
||
Supported options:
|
||
|
||
.. program:: vpc
|
||
.. option:: subformat
|
||
|
||
Specifies which VHD subformat to use. Valid options are
|
||
``dynamic`` (default) and ``fixed``.
|
||
|
||
.. program:: image-formats
|
||
.. option:: VHDX
|
||
|
||
Hyper-V compatible image format (VHDX).
|
||
|
||
Supported options:
|
||
|
||
.. program:: VHDX
|
||
.. option:: subformat
|
||
|
||
Specifies which VHDX subformat to use. Valid options are
|
||
``dynamic`` (default) and ``fixed``.
|
||
|
||
.. option:: block_state_zero
|
||
|
||
Force 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``.
|
||
|
||
.. option:: block_size
|
||
|
||
Block size; min 1 MB, max 256 MB. 0 means auto-calculate based on
|
||
image size.
|
||
|
||
.. option:: log_size
|
||
|
||
Log size; min 1 MB.
|
||
|
||
Read-only formats
|
||
~~~~~~~~~~~~~~~~~
|
||
|
||
More disk image file formats are supported in a read-only mode.
|
||
|
||
.. program:: image-formats
|
||
.. option:: bochs
|
||
|
||
Bochs images of ``growing`` type.
|
||
|
||
.. program:: image-formats
|
||
.. option:: cloop
|
||
|
||
Linux Compressed Loop image, useful only to reuse directly compressed
|
||
CD-ROM images present for example in the Knoppix CD-ROMs.
|
||
|
||
.. program:: image-formats
|
||
.. option:: dmg
|
||
|
||
Apple disk image.
|
||
|
||
.. program:: image-formats
|
||
.. option:: parallels
|
||
|
||
Parallels disk image format.
|
||
|
||
Using host drives
|
||
~~~~~~~~~~~~~~~~~
|
||
|
||
In addition to disk image files, QEMU can directly access host
|
||
devices. We describe here the usage for QEMU version >= 0.8.3.
|
||
|
||
Linux
|
||
^^^^^
|
||
|
||
On 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.
|
||
|
||
CD
|
||
You 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.
|
||
|
||
Floppy
|
||
You 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 disks
|
||
Hard 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 ``-snapshot`` command
|
||
line option or modify the device permissions accordingly).
|
||
|
||
Windows
|
||
^^^^^^^
|
||
|
||
CD
|
||
The 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 disks
|
||
Hard 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 ``-snapshot`` 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 images
|
||
~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
QEMU can automatically create a virtual FAT disk image from a
|
||
directory tree. In order to use it, just type:
|
||
|
||
.. parsed-literal::
|
||
|
||
|qemu_system| 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:
|
||
|
||
.. parsed-literal::
|
||
|
||
|qemu_system| linux.img -fda fat:floppy:/my_directory
|
||
|
||
A read/write support is available for testing (beta stage) with the
|
||
``:rw:`` option:
|
||
|
||
.. parsed-literal::
|
||
|
||
|qemu_system| 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 access
|
||
~~~~~~~~~~
|
||
|
||
QEMU can access directly to block device exported using the Network Block Device
|
||
protocol.
|
||
|
||
.. parsed-literal::
|
||
|
||
|qemu_system| 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:
|
||
|
||
.. parsed-literal::
|
||
|
||
|qemu_system| linux.img -hdb nbd+unix://?socket=/tmp/my_socket
|
||
|
||
In this case, the block device must be exported using ``qemu-nbd``:
|
||
|
||
.. parsed-literal::
|
||
|
||
qemu-nbd --socket=/tmp/my_socket my_disk.qcow2
|
||
|
||
The use of ``qemu-nbd`` allows sharing of a disk between several guests:
|
||
|
||
.. parsed-literal::
|
||
|
||
qemu-nbd --socket=/tmp/my_socket --share=2 my_disk.qcow2
|
||
|
||
and then you can use it with two guests:
|
||
|
||
.. parsed-literal::
|
||
|
||
|qemu_system| linux1.img -hdb nbd+unix://?socket=/tmp/my_socket
|
||
|qemu_system| 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:
|
||
|
||
.. parsed-literal::
|
||
|
||
|qemu_system| -cdrom nbd://localhost/debian-500-ppc-netinst
|
||
|qemu_system| -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:
|
||
|
||
.. parsed-literal::
|
||
|
||
|qemu_system| linux.img -hdb nbd:my_nbd_server.mydomain.org:1024
|
||
|qemu_system| linux2.img -hdb nbd:unix:/tmp/my_socket
|
||
|qemu_system| -cdrom nbd:localhost:10809:exportname=debian-500-ppc-netinst
|
||
|
||
iSCSI LUNs
|
||
~~~~~~~~~~
|
||
|
||
iSCSI 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[:<uuid>'] where <uuid> is the UUID of the
|
||
virtual machine. If the UUID is not specified qemu will use
|
||
'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"
|
||
|
||
How to use a configuration file to set iSCSI configuration options:
|
||
|
||
.. parsed-literal::
|
||
|
||
cat >iscsi.conf <<EOF
|
||
[iscsi]
|
||
user = "me"
|
||
password = "my password"
|
||
initiator-name = "iqn.qemu.test:my-initiator"
|
||
header-digest = "CRC32C"
|
||
EOF
|
||
|
||
|qemu_system| -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \\
|
||
-readconfig iscsi.conf
|
||
|
||
How to set up a simple iSCSI target on loopback and access 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'.
|
||
|
||
.. parsed-literal::
|
||
|
||
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| -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 images
|
||
~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
GlusterFS is a user space distributed file system.
|
||
|
||
You can boot from the GlusterFS disk image with the command:
|
||
|
||
URI:
|
||
|
||
.. parsed-literal::
|
||
|
||
|qemu_system| -drive file=gluster[+TYPE]://[HOST}[:PORT]]/VOLUME/PATH
|
||
[?socket=...][,file.debug=9][,file.logfile=...]
|
||
|
||
JSON:
|
||
|
||
.. parsed-literal::
|
||
|
||
|qemu_system| 'json:{"driver":"qcow2",
|
||
"file":{"driver":"gluster",
|
||
"volume":"testvol","path":"a.img","debug":9,"logfile":"...",
|
||
"server":[{"type":"tcp","host":"...","port":"..."},
|
||
{"type":"unix","socket":"..."}]}}'
|
||
|
||
*gluster* is the protocol.
|
||
|
||
*TYPE* specifies the transport type used to connect to gluster
|
||
management daemon (glusterd). Valid transport types are
|
||
tcp and unix. In the URI form, if a transport type isn't specified,
|
||
then tcp type is assumed.
|
||
|
||
*HOST* specifies the server where the volume file specification for
|
||
the given volume resides. This can be either a hostname or an ipv4 address.
|
||
If transport type is unix, then *HOST* 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, it defaults to port 24007. If the transport type is unix,
|
||
then *PORT* should not be specified.
|
||
|
||
*VOLUME* is the name of the gluster volume which contains the disk image.
|
||
|
||
*PATH* is the path to the actual disk image that resides on gluster volume.
|
||
|
||
*debug* is the logging level of the gluster protocol driver. Debug levels
|
||
are 0-9, with 9 being the most verbose, and 0 representing no debugging output.
|
||
The default level is 4. The current logging levels defined in the gluster source
|
||
are 0 - None, 1 - Emergency, 2 - Alert, 3 - Critical, 4 - Error, 5 - Warning,
|
||
6 - Notice, 7 - Info, 8 - Debug, 9 - Trace
|
||
|
||
*logfile* is a commandline option to mention log file path which helps in
|
||
logging to the specified file and also help in persisting the gfapi logs. The
|
||
default is stderr.
|
||
|
||
You can create a GlusterFS disk image with the command:
|
||
|
||
.. parsed-literal::
|
||
|
||
qemu-img create gluster://HOST/VOLUME/PATH SIZE
|
||
|
||
Examples
|
||
|
||
.. parsed-literal::
|
||
|
||
|qemu_system| -drive file=gluster://1.2.3.4/testvol/a.img
|
||
|qemu_system| -drive file=gluster+tcp://1.2.3.4/testvol/a.img
|
||
|qemu_system| -drive file=gluster+tcp://1.2.3.4:24007/testvol/dir/a.img
|
||
|qemu_system| -drive file=gluster+tcp://[1:2:3:4:5:6:7:8]/testvol/dir/a.img
|
||
|qemu_system| -drive file=gluster+tcp://[1:2:3:4:5:6:7:8]:24007/testvol/dir/a.img
|
||
|qemu_system| -drive file=gluster+tcp://server.domain.com:24007/testvol/dir/a.img
|
||
|qemu_system| -drive file=gluster+unix:///testvol/dir/a.img?socket=/tmp/glusterd.socket
|
||
|qemu_system| -drive file=gluster+rdma://1.2.3.4:24007/testvol/a.img
|
||
|qemu_system| -drive file=gluster://1.2.3.4/testvol/a.img,file.debug=9,file.logfile=/var/log/qemu-gluster.log
|
||
|qemu_system| 'json:{"driver":"qcow2",
|
||
"file":{"driver":"gluster",
|
||
"volume":"testvol","path":"a.img",
|
||
"debug":9,"logfile":"/var/log/qemu-gluster.log",
|
||
"server":[{"type":"tcp","host":"1.2.3.4","port":24007},
|
||
{"type":"unix","socket":"/var/run/glusterd.socket"}]}}'
|
||
|qemu_system| -drive driver=qcow2,file.driver=gluster,file.volume=testvol,file.path=/path/a.img,
|
||
file.debug=9,file.logfile=/var/log/qemu-gluster.log,
|
||
file.server.0.type=tcp,file.server.0.host=1.2.3.4,file.server.0.port=24007,
|
||
file.server.1.type=unix,file.server.1.socket=/var/run/glusterd.socket
|
||
|
||
Secure Shell (ssh) disk images
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
You can access disk images located on a remote ssh server
|
||
by using the ssh protocol:
|
||
|
||
.. parsed-literal::
|
||
|
||
|qemu_system| -drive file=ssh://[USER@]SERVER[:PORT]/PATH[?host_key_check=HOST_KEY_CHECK]
|
||
|
||
Alternative syntax using properties:
|
||
|
||
.. parsed-literal::
|
||
|
||
|qemu_system| -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. The fingerprint can be provided in
|
||
``md5``, ``sha1``, or ``sha256`` format, however, it is strongly
|
||
recommended to only use ``sha256``, since the other options are
|
||
considered insecure by modern standards. The fingerprint value
|
||
must be given as a hex encoded string::
|
||
|
||
host_key_check=sha256:04ce2ae89ff4295a6b9c4111640bdcb3297858ee55cb434d9dd88796e93aa795
|
||
|
||
The key string may optionally contain ":" separators between
|
||
each pair of hex digits.
|
||
|
||
The ``$HOME/.ssh/known_hosts`` file contains the base64 encoded
|
||
host keys. These can be converted into the format needed for
|
||
QEMU using a command such as::
|
||
|
||
$ for key in `grep 10.33.8.112 known_hosts | awk '{print $3}'`
|
||
do
|
||
echo $key | base64 -d | sha256sum
|
||
done
|
||
6c3aa525beda9dc83eadfbd7e5ba7d976ecb59575d1633c87cd06ed2ed6e366f -
|
||
12214fd9ea5b408086f98ecccd9958609bd9ac7c0ea316734006bc7818b45dc8 -
|
||
d36420137bcbd101209ef70c3b15dc07362fbe0fa53c5b135eba6e6afa82f0ce -
|
||
|
||
Note that there can be multiple keys present per host, each with
|
||
different key ciphers. Care is needed to pick the key fingerprint
|
||
that matches the cipher QEMU will negotiate with the remote server.
|
||
|
||
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 libssh and OpenSSH, ``fsync`` is
|
||
supported.
|
||
|
||
NVMe disk images
|
||
~~~~~~~~~~~~~~~~
|
||
|
||
NVM Express (NVMe) storage controllers can be accessed directly by a userspace
|
||
driver in QEMU. This bypasses the host kernel file system and block layers
|
||
while retaining QEMU block layer functionalities, such as block jobs, I/O
|
||
throttling, image formats, etc. Disk I/O performance is typically higher than
|
||
with ``-drive file=/dev/sda`` using either thread pool or linux-aio.
|
||
|
||
The controller will be exclusively used by the QEMU process once started. To be
|
||
able to share storage between multiple VMs and other applications on the host,
|
||
please use the file based protocols.
|
||
|
||
Before starting QEMU, bind the host NVMe controller to the host vfio-pci
|
||
driver. For example:
|
||
|
||
.. parsed-literal::
|
||
|
||
# modprobe vfio-pci
|
||
# lspci -n -s 0000:06:0d.0
|
||
06:0d.0 0401: 1102:0002 (rev 08)
|
||
# echo 0000:06:0d.0 > /sys/bus/pci/devices/0000:06:0d.0/driver/unbind
|
||
# echo 1102 0002 > /sys/bus/pci/drivers/vfio-pci/new_id
|
||
|
||
# |qemu_system| -drive file=nvme://HOST:BUS:SLOT.FUNC/NAMESPACE
|
||
|
||
Alternative syntax using properties:
|
||
|
||
.. parsed-literal::
|
||
|
||
|qemu_system| -drive file.driver=nvme,file.device=HOST:BUS:SLOT.FUNC,file.namespace=NAMESPACE
|
||
|
||
*HOST*:*BUS*:*SLOT*.\ *FUNC* is the NVMe controller's PCI device
|
||
address on the host.
|
||
|
||
*NAMESPACE* is the NVMe namespace number, starting from 1.
|
||
|
||
Disk image file locking
|
||
~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
By default, QEMU tries to protect image files from unexpected concurrent
|
||
access, as long as it's supported by the block protocol driver and host
|
||
operating system. If multiple QEMU processes (including QEMU emulators and
|
||
utilities) try to open the same image with conflicting accessing modes, all but
|
||
the first one will get an error.
|
||
|
||
This feature is currently supported by the file protocol on Linux with the Open
|
||
File Descriptor (OFD) locking API, and can be configured to fall back to POSIX
|
||
locking if the POSIX host doesn't support Linux OFD locking.
|
||
|
||
To explicitly enable image locking, specify "locking=on" in the file protocol
|
||
driver options. If OFD locking is not possible, a warning will be printed and
|
||
the POSIX locking API will be used. In this case there is a risk that the lock
|
||
will get silently lost when doing hot plugging and block jobs, due to the
|
||
shortcomings of the POSIX locking API.
|
||
|
||
QEMU transparently handles lock handover during shared storage migration. For
|
||
shared virtual disk images between multiple VMs, the "share-rw" device option
|
||
should be used.
|
||
|
||
By default, the guest has exclusive write access to its disk image. If the
|
||
guest can safely share the disk image with other writers the
|
||
``-device ...,share-rw=on`` parameter can be used. This is only safe if
|
||
the guest is running software, such as a cluster file system, that
|
||
coordinates disk accesses to avoid corruption.
|
||
|
||
Note that share-rw=on only declares the guest's ability to share the disk.
|
||
Some QEMU features, such as image file formats, require exclusive write access
|
||
to the disk image and this is unaffected by the share-rw=on option.
|
||
|
||
Alternatively, locking can be fully disabled by "locking=off" block device
|
||
option. In the command line, the option is usually in the form of
|
||
"file.locking=off" as the protocol driver is normally placed as a "file" child
|
||
under a format driver. For example:
|
||
|
||
::
|
||
|
||
-blockdev driver=qcow2,file.filename=/path/to/image,file.locking=off,file.driver=file
|
||
|
||
To check if image locking is active, check the output of the "lslocks" command
|
||
on host and see if there are locks held by the QEMU process on the image file.
|
||
More than one byte could be locked by the QEMU instance, each byte of which
|
||
reflects a particular permission that is acquired or protected by the running
|
||
block driver.
|
||
|
||
Filter drivers
|
||
~~~~~~~~~~~~~~
|
||
|
||
QEMU supports several filter drivers, which don't store any data, but perform
|
||
some additional tasks, hooking io requests.
|
||
|
||
.. program:: filter-drivers
|
||
.. option:: preallocate
|
||
|
||
The preallocate filter driver is intended to be inserted between format
|
||
and protocol nodes and preallocates some additional space
|
||
(expanding the protocol file) when writing past the file’s end. This can be
|
||
useful for file-systems with slow allocation.
|
||
|
||
Supported options:
|
||
|
||
.. program:: preallocate
|
||
.. option:: prealloc-align
|
||
|
||
On preallocation, align the file length to this value (in bytes), default 1M.
|
||
|
||
.. program:: preallocate
|
||
.. option:: prealloc-size
|
||
|
||
How much to preallocate (in bytes), default 128M.
|