qemu picture

vm.settings(5) man page


vmtools.confvmtools configuration files


vmtools(7) commands obtain their configuration data from the following sources in the following order:
  1. Default settings (/usr/local/share/vmtools.conf).
  2. System-wide settings (/etc/vmtools/vmtools.conf).
  3. User settings (~/.config/vmtools/vmtools.conf, see FILES below for more information).
  4. Virtual machine settings, if applicable (including potential templates and parent files).
  5. Command-line options (in particular t the -o setting=value option).
For each parameter, the last obtained value will be used.
Currently the default, system, user settings and templates files are sourced as traditional shell script files but this behavior may change in a future version. Virtual machines settings files are more strongly checked:
  • Two classes of characters are distinguished:
    • Safe strings are composed of alphanumeric characters and the underscore character (_).
    • Extended strings do not need to be quoted (though it is allowed) when they only contain characters from the following classes:
      • Safe characters.
      • The dash (-), dot (.) and forward slash (/) characters.
      Strings containing any other character must be enclosed in single quotes (‘).
      Single quotes appearing as part of an extended string must be escaped using the following sequence: '\'' (single quote, backslash followed by two single quotes).
      Here is an example setting the virtual machine name to “John’s VM”:
      vm_name='John'\''s VM'
      The linefeed (\n) and null (\0) characters are forbidden in extended strings, even enclosed between single quotes.
  • Empty lines and lines starting with a ‘#’ are comments.
  • The general syntax for assigning a value to a setting is:
    setting is composed of safe characters and begins with one of these prefix:
    vmtools(7) general settings.
    They can only be set in the default, system and user configuration files and through command-line options. Virtual machine settings files and templates must not modify them.
    Virtual machine definition settings.
    They can be updated at any step.
    value is an extended string.
    No space is allowed around the = symbol.
  • In addition to settings assignment, templates and virtual machine settings files can also invoke templates using the following syntax:
    template template_name ...
    template_name is composed of safe characters.
  • Child virtual machines invoke their parent’s settings using the following syntax:
    parent parent_path
    parent_path is an extended string.
    The parent keyword can be invoked only once per virtual machine settings file, the parent virtual machine however can invoke its own parent to implement a virtual machines chain.


vmtools general settings describe vmtools behavior and are shared between all virtual machines. They are all using the prefix cfg_. They cannot be set in virtual machines and templates settings files.
vmtools general settings are as follows:
If yes, allow files in the user’s configuration directory to override default and system-wide settings and modules. Otherwise user’s configuration files are silently ignored.
See FILES below for more information on files location.
Some vmtools(7) commands allow to overwrite this setting on a per command-line basis using the -o flag:
-o cfg_include_userhome=yes
Default value: ‘no’.
Prefix to build the Qemu command-line.
The content of vm_qemu_arch is appended to this prefix in order to complete the name of the Qemu binary file to execute. This avoids to store path to binary executable files in virtual machines settings files.
Assigning an absolute path to cfg_include_userhome allows to use a non-default Qemu binary executable file (to test a locally compiled version of Qemu for instance). Otherwise, the Qemu binary executable will be searched in PATH.
The binary executable file name must begin with qemu-system-, otherwise the process will not be recognized by the vmps(1) utility.
Default value: ‘qemu-system-‘.


File storing the path to every child forked from the current virtual machine.
Default value: ‘childs.lst’.
File (acutally a symbolic link) used to lock access to a virtual machine, preventing concurrent access issues.
Default value: ‘.vm.settings.lock’.
File storig the PID of the Qemu hypervisor process running the current virtual machine.
Default value: ‘qemu.pid’.
Socket file providing access to the Qemu monitor shell.
This file is created only if vm_qemu_daemonize is set to yes.
Default value: ‘monitor.sock’.
Pattern for the name of the directory used to store temporary backup files.
Usually such directories are created below the system’s default temporary directory (see ENVIRONMENT below), but when they may be used to store large files (like disk image files) they will be created in other places (in the virtual machine home directory, its parent directory or the home diretory of the parent virtual machine depending on the context) to avoid moving such files between different partitions and filling up potentially small temporary directories.
This pattern contains trailing ‘X’ which are replaced by random characters (see mktemp(1)). For security purpose it is recommended to use at least around six trailing ‘X’. Some mktemp(1) implementation enforce a minimum of three trailing ‘X’.
Default value: ‘vmtools-backup.XXXXXXXXXX.
File storing the virtual machine settings.
Default value: ‘vm.settings’.


Maximum nesting level for templates and child virtual machines nesting. This value is used to detect infinite loops.
Default value: 100.
Time (in seconds) after which vmtools(7) commands will give up after unsuccessful attempts to acquire a lock.
It is possible that unused lock files may remain after a crash. See vmfix(1) to delete such files.
See also the cfg_file_lock setting to set the lock file name. Default value: 10.


These settings are space-separated lists of names of vmtools modules to be called in certain circumstances. The modules are invoked in their order of appearance in these lists.
Modules handling the copy and fork of virtual machines.
Default value: ‘networking_iface_mac storage_backend’.
Modules building the Qemu command-line to execute to boot the guest.
Don’t assume that removing a module from this list will automatically disable the associated feature, this will make Qemu to use its default behavior which may be different (for instance, if no networking parameter is specified Qemu enables networking by default, disabling it must be done explicitely, see the corresponding settings in vm_networking).
Unless you want to prefix the Qemu command with something or replace this command altogether, qemu will most likely be the first module to be invoked.
Default value: ‘qemu boot cpu display keyboard monitor name networking ram storage_cdrom storage_hdd’
Configuration modules used to select a template.
Configuration modules are invoked to start a virtual machine when no setting file is available.
The template system allows to alter the virtual machine default settings in various ways and may have different functional use, from adapting the settings to comply with operating system prerequisites to grouping the virtual machines into technical or logical entities
Default value: ‘autodetect’
Configuration modules used to define the various vitual machine settings.
Configuration modules are invoked to start a virtual machine when no setting file is available.
Most of these modules ask the user to enter the associated setting value or accept the proposed default value.
Default value: ‘cpu_count ram_size networking_auto storage_hdd_import storage_hdd1_createsize’

User interface

If yes, do not ask any question to the user, assume a positive answer (y) for user confirmation requests and automatically accept the default value for multiple choices questions.
Most vmtools(7) commands allow to temporarily set this setting to yes using the -y flag.
Default value: ‘no’.
Makes vmtools(7) commands to produce more or less output on stderr.
Most commands allow to set temporarily modify this setting using the -q (quiet) and -v (verbose) flags to respectively decrease and increase the verbosity.
The verbosity levels are as follows:
Minimal output (error messages, listening port, etc.).
Output informational messages like the name of a correctly started or created virtual machines.
Adds progress information on slow tasks (image file creation, lock, etc.), progress information may include control character not suitable for log files.
Provide feedback on each main intermediary step (modules loaded, modified virtual machine, etc.).
Provide deeper information (locks and file management, settings dump, etc.).
Print each executed shell command.
Default value: 2.


These settings describe the devices and environment available to the virtual machine guest system.
These settings are designed to be overridden in virtual machines settings files.
Path to the virtual machine home directory.
This value is automatically set by the vmtools(7) commands, there should be no need to set it manually.
Default value:  (empty).
The virtual machine name appears in various locations, like the title bar of some display interface and as output of some commands to help the user to identify a virtual machine.
This setting has no direct impact on the guest system environment.
While there is no global default value, a command such as vmcreate(1) usually initialize this setting to the name of the current virtual machine home directory, or to the name of booted file if the virtual machine has no home directory. The user however is free to set this setting to any other value.
Default setting:  (empty).


A combination of letters defining Qemu devices boot order.
The devices identifiers are as follows:
a, b
The first and second floppy disk device.
The first hard disk device.
The first CD-ROM device.
Etherboot from the network adapters 1-3.
Default value: ‘cd’.
If yes, enable the boot media selection menu.
This menu is handled by the BIOS, and therefore its support and behavior directly depends on the selected BIOS image.
Default value: ‘no’.


Number of virtual CPUs available for the guest.
Default value: 2.
Type of virtual CPUs available for the guest.
The list of available CPU models is obtained by passing:
-cpu help
to the Qemu command.
Default value: host.


Select the display device to emulate to the guest.
Available display devices are as follows:
For legacy systems.
For 2000-era systems (Windows XP and higher).
Unix: natively supported by any modern XFree86/Xorg, Windows: requires appropriate drivers to be installed in the guest.
Automativally selected when vm_display_type is set to spice.
For Sun machines.
For legacy Sun machines.
No display device is available for the guest. vm_display_type is ignored.
See the description of the -vga flag in qemu-system(1) for more details.
Default value: ‘std’.
Listening interface when a remote display type is used.
This setting has an effect only when vm_display_type is set to either spice or vnc.
The special value allows to listen on all interface, but it is generally a bad idea security-wise to listen on external interfaces. For better security, it is recommended to listen only on local loopback interface and tunnel the remote desktop application through a SSH tunnel to access it.
Default value: ‘’.
Listening TCP port when a remote display type is used. If the port is not free, the virtual machine will fail to start.
This setting has an effect only when vm_display_type is set to either spice or vnc.
Leaving this setting empty enables automatic port selection (see the vm_display_portmin setting).
Default value:  (empty).
First port to try when vm_display_port is empty. If the port is not free, the next port will be tried until a free port is found.
This setting is ignored if vm_display_port is not empty.
Qemu hardcodes a minimum value of 5900 for the VNC protocol, so you should not set a lower value unless you intend to never use the VNC protocol. See https://bugs.launchpad.net/qemu/+bug/1089496
You are free however to set a higher value in a virtual machine settings file or in a template for instance to allocate different port ranges to different virtual machines groups.
Default value: 5900.
Select display output to use.
This setting is ignored if vm_display_device is set to none.
When using a headless display mode, the Qemu hypervisor process acts as a server and unless specified otherwise opens a TCP port in listen mode (see vm_display_iface, vm_display_port and vm_display_portmin settings to define the listening interface and port).
The available headless display output are as follow:
The Qemu hypervisor acts as a VNC server. This is the historical and most widely supported headless output mode as it has no requirement guest-side.
Automatically sets vm_display_device to qxl. More efficient than VNC, this requires the guest to have a driver for the QXL paravirtualized graphic card device. This is natively supported with any recent X.org, on Windows a freely available driver needs to be installed.
The Qemu hypervisor will not produce any display output (and will, therefore, not open any TCP port). The guest however will see have the display device selected using the vm_display_device setting enabled.
When using a windowed display mode, the Qemu hypervisor software acts as a client of the host’s window manager to open a graphical window. Depending on the window server settings, the display may be redirected to a remote host, but when using a standard X server this is less effcient than using VNC or SPICE.
The available windowed display output are as follow:
This is the most basic windowed display mode. Some Linux distributions which enable only headless modes (like Alpine Linux) do not support this mode, appart than that it is quite widely supported.
This windowed display mode has more features. Due to the amount of library dependencies, some Linux distributions (like Debian) choose not to enable it.
More information can be found in the description of the -display and -spice flag in the qemu-system(1) man page. More information on distribution-specific limitations are available online:
https://bugs.alpinelinux.org/issues/6609 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839695
Default value: ‘sdl’.


Select a keyboard mapping.
Leave this setting empty to let Qemu detect it, but this may be unreliable specially when using remote displays.
Available keymaps should be located in /usr/share/qemu/keymaps.
This setting is a good candidate to be overridden in system-wide or user settings.
Default value:  (empty).


Specific settings for running Apple MacOS guests.
This key stored in Apple’s hardware SMC (System Management Center) chip is used to decrypt some MacOS system files, ensuring the system can be run only on genuine Apple hardware. Qemu does not implement (yet) any passthrough so you must fetch the key from your own hardware before trying to start an OSX guest in Qemu.
More information is available online:
This setting can be set system-wide so it will be automatically shared between all virtual machines running on the same host.
Default value:  (empty).


Networking setting are divided in two groups:
  • The default settings whose values are used to override unset interface settings.
  • The interface settings, their name contain the ifacen string where n is a counter (the first interface will have its settings variable labelled iface1, the second one iface 2, etc.).
    n does not need to be incremental: the interface 4 may be enabled while the interface 3 remains undefined. Two different interfaces cannot share an indentical value for n. This label has only a meaning from the hypervisor perspective, its exact value has no impact on the guest.
Default network virtual device type. This setting replaces empty vm_networking_ifacen_device settings.
The list of available devices is obtained by passing:
-device help
to the Qemu command, section Network devices.
This setting accepts supplementary, comma-separated options to pass to the virtual device. The list of available options for a particular device is obtained by passing:
-device device_name,help
to the Qemu command.
Default value: ‘e1000-82545em’.
Default MAC address. If empty, a random MAC address will be used. A partial address is taken as a MAC prefix, and dynamically completed using a random value.
This setting replaces empty vm_networking_ifacen_mac settings.
This setting may contain up to six groups of two hexadecimal digits separated by colons. A final colon may be present or omitted. It is not possible to break a group of two hexadecimal digits. The remaining digits are completed using random digits.
It is recommended to use valid Organizationally Unique Identifier (OUI), at the very least the multicast bit must be set to zero (multicast MAC addresses are not authorized in Ethernet frames’ sender field).
If this setting is empty, a MAC address is generated with the multicast bit set to zero, the locally administered bit set to one, and all other bits set to random values.
See also vmrndmac(1).
Default value: ‘52:54:00’.
Default operating mode. This setting replaces empty vm_networking_ifacen_mode settings.
This setting accepts supplementary, comma-separated options to apply to the selected mode. Available options vary greatly depending on the mode used.
Here are a few examples:
Use the default user mode network stack which requires no administrator privilege to run.
The user mode network stack simulates a network where by default the host system acts as the default gateway. External hosts will see the connection attempts made by the guests as coming from the host system, and external hosts will be unable to directly contact the guest systems.
Qemu provides several services available for this virtual network, including a DHCP server enabled by default which assigns local addresses to the guests connected to this network (the address range used in this internal network is independant from the range used on the host’s physical network). Other notable services are VLAN-based network segmentation, TFTP and BOOTP servers to store boot images and a SMB server allowing to share files between the guest and host system. None of these additional services is enabled by default.
This example extends from the previous case by changing a few defaults:
The host system will not forward by default anymore packets coming fom the guests to the external network. This has the consequence of isolating the guest from any external network.
The guest will be connected to the virtual network VLAN 2 instead of the default VLAN 0. It will be able to communicate only with guests also connected to VLAN 2, and will be unable to communicate with hosts connected to other VLAN.
It is possible for a guest to have several interfaces connected to different VLANs, thus allowing to build a complex network architecture.
The Qemu hypervisor process will listen on port 12345 on the host interface, and forward all incoming connections to the guest on port 22. This particular settings allows to connect to the guest from the host using SSH.
Removing the host interface (hostfwd=tcp::12345-:22) allows the Qemu hypervisor to listen on all interfaces, effectively allowing external hosts to connect to the guest’s port 22 while still preventing them from reaching any other guest’s port (note that the host firewall must be configured to allow incoming connections).
These options, given here for the sake of the example, can be also used independently.
Use the default network helper (usually /usr/lib/qemu/qemu-bridge-helper) to automatically create and delete a TAP network interface when the virtual machine starts and stop, providing a direct access to the external network to the guest.
External hosts will see the guest as a standalone system, unrelated to the host system. The guest will have its own IP on the external network, outgoing connections will have the guest IP as source and external hosts will be able to directly reach the guest system, without involving any routing the Qemu hypervisor (for this reason this mode offers better performances than the user mode network stack).
This method has three main prerequisites:
  • A bridge interface must be created on the system.
    Qemu attempts by default to use a bridge interface named br0, the br=bridge_name option allows to specify another name if needed. The exact procedure to define a bridge interface depends on the system used and your current network settings, refer to your system documentation.
  • The helper is not executable by default, must be explicitely enabled and be able gain sufficient privileges to create the TAP network interface.
    The safest way to do so is to make it executable only to the members of the kvm or libvirtd group (or any equivalent group, the exact name depends on your system) and use Linux capabilities to grant it network administration privileges:
    chown root:kvm \ 
    chgrp 750 /usr/lib/qemu/qemu-bridge-helper 
    setcap cap_net_admin=ep \ 
    Note that those changes may be reverted by any system update updating the Qemu binaries.
  • The helper must be explicitely authorized to use the bridge interface created earlier.
    This is usually defined in the file /etc/qemu/bridge.conf (replace br0 with your own bridge interface name):
    echo "allow br0" >/etc/qemu/bridge.conf
For more information on available modes and options, see the description of the -netdev flag in qemu-system(1).
Default value: ‘user’.
Device type of the virtual network interface n.
If vm_networking_ifacen_enable is not set to yes, this setting is ignored. If no value is provided, vm_networking_default_device is used instead.
See the description of vm_networking_default_device for more information.
Default value:  (empty).
If set to yes, enable the virtual network interface n. Otherwise, all other settings related to this interface are ignored.
Note that the settings configuration module networking_auto automatically enables the first network interface on new virtual machines using the default settings. See the enabled modules in cfg_modules_configure_settings.
Default value:  (empty).
MAC address of the virtual network interface n.
If vm_networking_ifacen_enable is not set to yes, this setting is ignored. If no value is provided, vm_networking_default_mac is used instead.
See the description of vm_networking_default_mac for more information.
Default value:  (empty).
Operating mode for the virtual network interface n.
If vm_networking_ifacen_enable is not set to yes, this setting is ignored. If no value is provided, vm_networking_default_mode is used instead.
See the description of vm_networking_default_mode for more information.
Default value:  (empty).


Name of the architecture emulated by Qemu.
Qemu supports various architectures, the list of available ones depends on your compilation options and installed packages. Common architectures are x86_64 and i386.
When using KVM (kernel-based virtualization), no difference is made between x86_64 and i386 modes. When using TCG (user-mode virtualization), 32-bits applications will execute faster if the architecture is explicitely set to i386.
Default value: ‘x86_64’.
If yes, compress copied and converted images.
The compression occurs only during the copy and conversion process, newly created empty images and data written by a running guest is not compressed to limit the impact on performance.
Default value: ‘no’.
Let the Qemu hypervisor process run in the background.
If yes and if the virtual machine has a home directory, a socket file will be created (see cfg_file_monitor setting) providing access to the Qemu monitor shell allowing to interactively control the Qemu hypervisor. See vmmon(1) to access this shell.
If no, the virtual machine will be started in interactive mode: Qemu will not go to the background but will instead directly provide the Qemu monitor shell.
Default value: ‘yes’.
Space-separated list of supplementary parameters to pass to the Qemu command-line.
The parameters containing spaces or special characters must be properly escaped, as indicated in the extended list description in the beginning of this man page.
Note that KVM is enabled by default. This provides near native performance for he guest system, but on some system this requires the user to belong to a certain group (like “kvm”).
Default value: ‘-enable-kvm -usbdevice tablet’.
The maximum amount of time (in seconds) to wait when shutting down a virtual machine.
See vmdown(1) for more information on the virtual machine shutdown process and options.
Default value: 20


Amount of RAM allocated to the guest.
This setting must be a number expressed either in Megabytes (it must be followed by a M) or in Gigabytes (it must be followed by a G).
The RAM amount is probably one of the most vital settings to allow a proper behavior of the guest system.
  • A value too low for the guest may turn an healthy guest into a senile slug, making the guest slow, irresponsive and affected by a wide range of issues indirectly caused by the lack of usable RAM, including but not limited to guest boot failures.
  • A value to high for the host will basically have the same consequences, this time not because of the lack of usable RAM for the guest but because of the inability for the host to properly execute the Qemu hypervisor process.
A good rule of thumb is that, under a normal load, a system should have at least 20% of its RAM free.
“Free” means doesn’t mean memory used by the system cache, “free” means that the memory is currently not used at all so it is immediately available upon request and the system has enough spare space to do all its management duties. Don’t expect the swap to compensate a lack of memory: the role of the swap is to act as an emergency solution, an alternative to not let the kernel kill random processes as a desperate attempt to keep the system up.
There is usually no side-effect in changing the amount of RAM of a stopped virtual machine.
Default value: ‘2G’.


There are three access modes to a storage backend:
The storage is seen as writable by the guest, and guest’s write operations are applied to the storage backend.
This is the most common mode for hard disk images.
Also known as non-persistant mode, the storage is seen as writable by the guest but guest’s write operations are not applied to the storage backend. Instead, they are stored in a temporary area and are deleted when the virtual machine exits. This allows to rollback to the same initial state upon each start of the virtual machine.
Note that the rollback is done upon a restart of the virtual machine itself. All modifications are kept upon guest operating system restarts.
Also note that Qemu still provides a way (the Qemu monitor commit command) to apply all temporarily stored write operations to the backend resource accessed in snapshot mode. This may or may not be a wanted feature. In case there is a strong requirement for the backend resource to remain unmodified, it is advised to work using a copy instead of the original file and/or protect the file by unsetting its write bit:
chmod a-w image_file
When accessing a file with the write bit unset, Qemu seem to transparently switch into snapshot mode even if the file access mode was explicitely set to read-write.
The storage is seen as read-only by the guest, all write attempt result in a failure.
This mode is commonly used for CD and DVD reader virtual devices. IDE hard disks cannot be read-only.
The effective access mode is the result of three criterion:
  1. The storage backend default mode.
    The default mode depends on the device type and path, see vm_storage_cdrom1_backend and vm_storage_hdd1_backend settings description for more information.
  2. The access mode provided as prefix in the storage path.
    See below for more information on storage path prefixes.
  3. The highest access mode allowed by the vm_storage_rwmode setting.
    See the setting’s decription for more information.
The latest of these criterion wins.
The storage backend path itself is composed of two main parts:
  • An optional prefix explicitely stating the access mode to use:
    Read-write mode.
    Snapshot mode.
    Read-only mode.
    The colon is part of the prefix and acts as a separator between the prefix and the storage backend location.
  • A storage backend location:
    The storage backend location may be of several types: a local file path, a local directory path, a local device path or a remote URL. The features, limitations and default behavior vary, see the description of the vm_storage_cdrom1_backend and vm_storage_hdd1_backend settings for more information.
See vmup(1) for several examples of backend paths, both with and without a prefix.
First virtual CD-ROM reader device backend.
This is usually one of the following:
  • A path to an ISO file.
  • A path to a local directory.
    An ISO image storing the content of the directory will be generated on the fly, attached to the guest system, and deleted when the virtual machine exits or otherwise close it. genisoimage(1) must be available on the host system for this feature to be available.
  • A path to one of host’s physical CD/DVD reader device file (like /dev/cdrom).
  • A URL to a remotely hosted ISO file.
    Qemu natively support FTP(S), HTTP(S), SSH and TFTP protocols.
Read-only is the only supported mode with virtual CD-ROM reader devices, read-write and snapshot modes are not supported. A CD-ROM device may be enabled (see vm_storage_cdrom1_enable setting) with no backend associated with it: the guest will see as a CD-ROM reader with no disk inserted.
Currently it is necessary to manually access the Qemu monitor shell to manipulate the CD-ROM reader device (this will change in a future version of vmtools(7)).
To manage the guest’s virtual CD-ROM device:
  1. Open it Qemu monitor shell using the vmmon(1) command.
  2. Type the following command to list available virtual block devices:
    (qemu) info block
    The virtual CD-ROM device should have an identifier along the lines of ide1-cd0.
  3. If there is already a disk present in the CD-ROM reader device, eject it using the following command:
    (qemu) eject device_identifier
  4. Now mount the new disk backend:
    (qemu) change device_identifier file_path
Default value:  (empty).
If set to yes, the first virtual CD-ROM device is enabled.
See vm_storage_cdrom1_backend setting for more information.
Default value: ‘no’.
Second CD-ROM device backend.
See vm_storage_cdrom1_backend setting for more information.
Default value:  (empty).
If set to yes, the second virtual CD-ROM device is enabled.
See vm_storage_cdrom1_backend setting for more information.
Default value: ‘no’.
First hard disk device backend.
This is usually one of the following:
  • A path to a hard disk image file.
    The preferred formats are QCow2 and RAW. Third-party and legacy image format are supported, but will usually be accessible only in snapshot mode. The vmcreate(1) and vmup(1) commands also propose to automatically convert such images to the QCow2 format. Images in .ova format must be converted as Qemu cannot handle them natively.
  • A path to a directory.
    This directory content will be presented to the guest as a virtual VFAT (Qemu VVFAT) hard disk. This feature has a few limitations:
    • The content of a directory shared this way must not be changed by the host while the guest is running.
    • The total size of this directory is limited to 504MB.
    • While natively supported by Qemu, this is not a widely used feature which is not even mentionned in the qemu-system(1) man page, so you may want to avoid it for sensitive tasks (you may either mount the directory as a CD-ROM reader, use SMB sharing or, for Unix and Unix-like guest use the VirtFS paravirtualized filesystem).
    By default the directory is mounted in read-only (actually snapshot) mode. It is possible to mount it in read-write mode by using an explicit rw: prefix, however this should be done cautiously (see the last bullet).
  • A path to a local device file (like /dev/sda). Qemu handles it like a RAW storage file.
  • A URL to a remotely hosted image file or a network storage. Qemu natively supports FTP(S), HTTP(S), iSCSI, NBD, SSH and TFTP. Such files are loaded in snapshot mode by default, except iSCSI and NBD URLs which are accessed in read-write mode by default. See qemu-system(1) to get more information regarding the URL syntax.
Unless stated otherwise, hard disk images are access in read-write mode by default. Qemu only supports the snapshot and read-write mode for hard disk devices, read-only mode is not supported. When a hard disk is enabled (see vm_storage_hdd1_enable setting) it is mandatory to provide a backend image. Default value:  (empty).
Size of a new empty image to create for the first virtual hard disk.
This setting must be expressed either in Megabytes, Gigabytes or Terabytes and must be followed by the appropriate unit (respectively M, G or T).
When this setting is set, vm_storage_hdd1_backend must be a local file path. The file designated by this setting will be created, if it already exists it will be overwriten.
This setting is mainly used during the creation of a new virtual machine and is not stored in the virtual machine settings (otherwise the image woud be oerwriten at each start of the virtual machine).
It may also be used to reset the storage of a virtual machine by passing an option such as -o vm_storage_hhd1_createsize=20G to vmup(1).
If you just want your virtual machine data to be non-persistent, consider using snapshot mode.
Default value:  (empty).
If set to yes, the first virtual hard disk device is enabled.
See vm_storage_hdd1_backend setting for more information.
Default value: ‘no’.
Second hard disk device backend.
See vm_storage_hdd1_backend setting for more information.
Default value:  (empty).
Size of a new empty image to create for the second virtual hard disk.
See vm_storage_hhd1_createsize setting for more information.
Default value:  (empty).
If set to yes, the second virtual hard disk device is enabled.
See vm_storage_hdd1_backend setting for more information.
Default value: ‘no’.
Maximum access mode allowed for storage backends:
There is no restriction: backends supporting it are accessed in read-write mode.
Note that this setting does not enforce read-write mode, it only allows it. To enforce the read-write mode to be used on a certain device it still needs to be explicitely enabled using the rw: storage path prefix.
Storage backend which would otherwise be accessed in read-write are accessed in snapshot mode instead. Storage accessed in snapshot mode or in read-write mode are not affected.
Read-only access is enforced to all storage backends.
The vmcreate(1) and vmup(1) commands allow to set this setting on a command-line basis, using the -s (snapshot mode) and -r (read-only mode) flags.
Default value: ‘rw’.


Default location to store temporary files, by default /tmp.
Location of user’s configuration files, by default ~/.config.


Libraries shared by the vmtools project utilities.
Modules handling the virtual machine copying process.
Virtual machine default settings, see vmtools.conf(5).
Moreover, the content of /usr/local/share/vmtools can be overridden in the following locations (in the order of precedence):
User overrides (if cfg_include_userhome is set to “yes”).
System-wide overrides.


Please send bug reports to the vmtools issues page.

Popular tags see all