Windows img for qemu

A collection of disk images and virtual machines that can be used by the QEMU emulator. If you are installing an OS in QEMU but don’t want to go through the whole process of downloading an ISO, preparing a disk image, waiting for the install to complete, etc, you can use one of my prepared images that I have created. In most cases, the images are vanilla installations, meaning they are un-modified from the original installation. If you want to just experiment with QEMU and see what it can do, check out the test-images folder!

Some of these disk images can even be ran in VirtualBox and other emulators, such as the Limbo PC Emulator App for Android (which is actually a derivation of the original QEMU emulator). Yes, you can run other operating systems on Android with this! Known images to work in Limbo PC Emulator are: FreeDOS, DSL, and other small linux distros.

QEMU (short for Quick Emulator) is an processor emulator. By using QEMU, you can run operating systems for different CPU architectures regardless of your host CPU’s architecture. You can run IA-32 (x86), x86-64, ARM, PowerPC, and lots more! QEMU can be installed on the host computer or can be ran from a USB flash drive. QEMU makes for a great alternative to VirtualBox and VMware, especially since these two programs are restricted to running guest operating systems for the x86 architecture.

How do I obtain QEMU?

If you use Linux:
- apt-get install qemu
If you use Windows:
- Go to: https://qemu.weilnetz.de/ and go to either the w32 or w64 directory and download one of the .exe files. In general, it’s OK to download the most recent installer
- If you installed it on your PC (not a USB) and you want to access it anywhere from the terminal, add it to your PATH environement variable. This does not happen by default.
- If you feel really unconfortable with the command line on Windows, then you can run the setupqemuk70.exe installer. It can be downloaded here. Note that this holds a very old version of QEMU that may not work with all the examples in this repository, so you might as well install a newer version and get used to the command line
If you use Mac OS X:
- QEMU can be installed from Homebrew brew install qemu

How do I run the examples in this repository?

In each directory exists instructions to run their respective disk images.

I went to a directory but there was no disk image!

There is a link in the directory’s README to download the file(s) seperately.

Why are all of the disk images in .7z format?

In general, disk images can be fairly large in size. In most cases, .7z format has better compression than .zip and other compression formats. You will need to use a tool such as 7-zip to extract the disk image.

How can I make my own disk image? Can I create one from scratch?

Yes, here is a brief tutorial:

First, you need some sort of ISO. We will use FreeDOS as an example

Download the FreeDOS ISO file at: http://www.freedos.org/download/download/FD12CD.iso
Move it to a directory other than your «Downloads» folder if you’d like

Create a hard disk image with qemu-img create

For a raw image format: qemu-img create myImage.img 1G or with qcow2 image format: qemu-img create -f qcow2 myImage.qcow2 1G where myImage is the name for your disk image file and 1G is the size of the file. Note that by using the qcow2 image format, you might be able to save some space on your hard drive or USB stick

Boot QEMU with the ISO mounted and disk image attached

qemu-system-i386 -hda myImage.img -cdrom FD12CD.iso -boot d -m 256
- -boot d — Boot the first virtual CD-ROM drive
- -m 256 — Give the machine 256 MB of RAM

From here just follow the install instructions for the OS

After the installation is done, the system can be booted with:

Can I run these images in VirtualBox instead?

Yes, but there are a couple things you need to do first:
1. You need to make sure the original image is x86 or x64 compadable, i.e. the image is for the i386 or amd64 architecture, and that the image can originally be ran with the qemu-system-i386 or qemu-system-x86_64 command(s)
2. You need to convert the .img or .qcow2 into a .vdi
  - From raw to vdi: qemu-img convert myImage.img -O vdi vdisk.vdi
  - From QCOW2 to vdi: qemu-img convert -f qcow2 myImage.qcow2 -O vdi vdisk.vdi

How can I get disk information (i.e. Type of disk image, virtual size, etc)?

About

A collection of disk images and virtual machines that can be used by the QEMU emulator

Источник

Образы виртуальных машин QEMU-KVM — создание и конвертация

Для манипуляции с образами дисков виртуальных машин в QEMU-KVM используется команда qemu-img, которая использует подкомманды для осуществления определенных действий. В общем случае формат команды qemu-img:

где в качестве «subcommand» могут быть:

check Проверка существующего образа диска на ошибки.

convert Конвертация существующего образа диска в другой формат.

info Выводит информацию о существующем образе диска.

snapshot Управляет снимками состояний (snapshots) существующих образов дисков.

commit Записывает произведенные изменения на существующий образ диска.

rebase Создает новый базовый образ на основании существующего.

Создание нового образа диска — qemu-img create

qemu-img create создает новый образ диска в базовой операционной системе для гостевой виртуальной машины. Формат команды:

fmt — формат образа диска. В kvm в Ubuntu можно создать образы дисков следующих форматов: vvfat vpc vmdk vhdx vdi sheepdog sheepdog sheepdog rbd raw host_cdrom host_floppy host_device file qed qcow2 qcow parallels nbd nbd nbd dmg tftp ftps ftp https http cow cloop bochs blkverify blkdebug.
Из всего этого разнообразия реально используется только 4 формата:

raw Файл содержащий как бы точную копию физического диска. Переводится как «сырой». Данные пишутся как есть без всякой обработки и без дополнительной служебной информации. Основным преимуществом данного формата являются максимальная производительность дисковой подсистемы среди других образов за счет отсутствия служебной информации и дополнительных действий в моменты чтения/записи. Универсальность формата позволяет использовать RAW-диски под управлением других гипервизоров(Xen, VMware).
К минусам можно отнести невозможность создавать снапшоты а так же необходимость выделения для файла-образа всего объема дискового пространства указанного в параметре size, что в прочем в некоторых случаях избавляет от фрагментации файла-образа за счет единовременного выделения всего объема.
qcow2 «Родной» формат эмулятора QEMU с поддержкой сжатия, снапшотов и шифрования. Кроме того qcow2 образ занимает столько места, сколько реально занимают данные, вне зависимости от размера создаваемого при соз8589934592дании. Наиболее часто используемый и рекомендуемый формат.
Производительность дисков в формате QCOW2 несколько уступает дискам в формате RAW . Диски в формате QCOW2 в большей степени подвержены фрагментации за счет постепенного а не едино разового выделения всего объема на физическом диске.
vdi Образ виртуальных машин, поддерживаемый VirtualBox.
vmdk Образ виртульных машин VMware.

size — размер создаваемого диска. Число и единица измерения — K (kilobyte), M (megabyte), G (gigabyte), или T (terabyte).

fname — имя файла образа диска.

Конвертация образа диска qemu-img convert

Для конвертации одного формата образа в другой используется опция convert:

-c — компрессия (сжатие) целевого диска. Компрессию поддерживают только qcow и qcow2 форматы.

-f fmt — формат исходного диска, в большинстве случаев хорошо определяется автоматически.

-O out_fmt — формат целевого диска

-o options — куча опций. Чтобы узнать, какие опции допустимы для данной конвертации можно ввести:

Источник

Disk Images¶

QEMU supports many disk image formats, including growable disk images (their size increase as non empty sectors are written), compressed and encrypted disk images.

Quick start for disk image creation¶

You can create a disk image with the command:

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 the qemu-img invocation documentation for more information.

Snapshot mode¶

If you use the option -snapshot , 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 snapshots¶

VM 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:

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 ( 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).

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.

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.

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.

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.

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.

File name of a base image (see create subcommand)

Image format of the base image

This option is deprecated and equivalent to encrypt.format=aes

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.

Provides the ID of a secret object that contains the passphrase ( encrypt.format=luks ) or encryption key ( encrypt.format=aes ).

Name of the cipher algorithm and key length. Currently defaults to aes-256 . Only used when encrypt.format=luks .

Name of the encryption mode to use. Currently defaults to xts . Only used when encrypt.format=luks .

Name of the initialization vector generator algorithm. Currently defaults to plain64 . Only used when encrypt.format=luks .

Name of the hash algorithm to use with the initialization vector generator (if required). Defaults to sha256 . Only used when encrypt.format=luks .

Name of the hash algorithm to use for PBKDF algorithm Defaults to sha256 . Only used when encrypt.format=luks .

Amount of time, in milliseconds, to use for PBKDF algorithm per key slot. Defaults to 2000 . Only used when encrypt.format=luks .

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.

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.

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 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.

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).

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.

File name of a base image (see create subcommand).

Image file format of backing file (optional). Useful if the format cannot be autodetected because it has no header, like some vhd/vpc files.

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.

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.

Old QEMU image format with support for backing files, compact image files, encryption and compression.

File name of a base image (see create subcommand)

This option is deprecated and equivalent to encrypt.format=aes

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 .

Provides the ID of a secret object that contains the encryption key ( encrypt.format=aes ).

LUKS v1 encryption format, compatible with Linux dm-crypt/cryptsetup

Provides the ID of a secret object that contains the passphrase.

Name of the cipher algorithm and key length. Currently defaults to aes-256 .

Name of the encryption mode to use. Currently defaults to xts .

Name of the initialization vector generator algorithm. Currently defaults to plain64 .

Name of the hash algorithm to use with the initialization vector generator (if required). Defaults to sha256 .

Name of the hash algorithm to use for PBKDF algorithm Defaults to sha256 .

Amount of time, in milliseconds, to use for PBKDF algorithm per key slot. Defaults to 2000 .

VirtualBox 1.1 compatible image format.

If this option is set to on , the image is created with metadata preallocation.

VMware 3 and 4 compatible image format.

File name of a base image (see create subcommand).

Create a VMDK version 6 image (instead of version 4)

Specify vmdk virtual hardware version. Compat6 flag cannot be enabled if hwversion is specified.

Specifies which VMDK subformat to use. Valid options are monolithicSparse (default), monolithicFlat , twoGbMaxExtentSparse , twoGbMaxExtentFlat and streamOptimized .

VirtualPC compatible image format (VHD).

Specifies which VHD subformat to use. Valid options are dynamic (default) and fixed .

Hyper-V compatible image format (VHDX).

Specifies which VHDX subformat to use. Valid options are dynamic (default) and fixed .

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 .

Block size; min 1 MB, max 256 MB. 0 means auto-calculate based on image size.

Read-only formats¶

More 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.

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.

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.

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 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¶

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 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:

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:

A read/write support is available for testing (beta stage) with the :rw: option:

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.

If the NBD server is located on the same host, you can use an unix socket instead of an inet socket:

In this case, the block device must be exported using qemu-nbd:

The use of qemu-nbd allows sharing of a disk between several guests:

and then you can use it with two guests:

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:

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:

Sheepdog disk images¶

Sheepdog 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:

where IMAGE is the Sheepdog image name and SIZE is its size.

To import the existing FILENAME to Sheepdog, you can use a convert command.

You can boot from the Sheepdog disk image with the command:

You can also create a snapshot of the Sheepdog image like qcow2.

where TAG is a tag name of the newly created snapshot.

To boot from the Sheepdog snapshot, specify the tag name of the snapshot.

You can create a cloned image from the existing snapshot.

where BASE is an image name of the source snapshot and TAG is its tag name.

You can use an unix socket instead of an inet socket:

If the Sheepdog daemon doesn’t run on the local host, you need to specify one of the Sheepdog servers to connect to.

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:

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:

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[: ’] where is the UUID of the virtual machine. If the UUID is not specified qemu will use ‘iqn.2008-11.org.linux-kvm[: ’] where is the name of the virtual machine.

Setting a specific initiator name to use when logging in to the target:

Controlling which type of header digest to negotiate with the target:

These can also be set via a configuration file:

Setting the target name allows different options for different targets:

How to use a configuration file to set iSCSI configuration options:

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’.

GlusterFS disk images¶

GlusterFS is a user space distributed file system.

You can boot from the GlusterFS disk image with the command:

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:

Secure Shell (ssh) disk images¶

You can access disk images located on a remote ssh server by using the ssh protocol:

Alternative syntax using properties:

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:

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:

Alternative syntax using properties:

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:

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.

Источник

Windows img for qemu