Block devices are vital for virtual machines. In general, these are fixed or removable storage media usually referred to as 'drives'. One of the connected hard drives typically holds the guest operating system to be virtualized.

Virtual Machine drives are defined with -drive. This option uses many suboptions, some of which are described in this section. For their complete list, see the manual page (man 1 qemu).

Tip

To simplify defining of block devices, QEMU understands several shortcuts which you may find handy when entering the qemu-system-ARCH command line.

You can use

qemu-system-ARCH -cdrom /images/cdrom.iso

instead of

qemu-system-ARCH -drive file=/images/cdrom.iso,index=2,media=cdrom

and

qemu-system-ARCH -hda /images/imagei1.raw -hdb /images/image2.raw -hdc \
/images/image3.raw -hdd /images/image4.raw

instead of

qemu-system-ARCH -drive file=/images/image1.raw,index=0,media=disk \
-drive file=/images/image2.raw,index=1,media=disk \
-drive file=/images/image3.raw,index=2,media=disk \
-drive file=/images/image4.raw,index=3,media=disk

Tip: Using Host Drives Instead of Images

As an alternative to using disk images (see Section 27.2, “Managing Disk Images with qemu-img”) you can also use existing VM Host Server disks, connect them as drives, and access them from VM Guest. Use the host disk device directly instead of disk image file names.

To access the host CD-ROM drive, use

qemu-system-ARCH [...] -drive file=/dev/cdrom,media=cdrom

To access the host hard disk, use

qemu-system-ARCH [...] -drive file=/dev/hdb,media=disk

A host drive used by a VM Guest must not be accessed concurrently by the VM Host Server or another VM Guest.

28.3.1.1 Freeing Unused Guest Disk Space #

A Sparse image file is a type of disk image file that grows in size as the user adds data to it, taking up only as much disk space as is stored in it. For example, if you copy 1 GB of data inside the sparse disk image, its size grows by 1 GB. If you then delete for example 500 MB of the data, the image size does not by default decrease as expected.

That is why the discard=on option is introduced on the KVM command line. It tells the hypervisor to automatically free the 'holes' after deleting data from the sparse guest image. Note that this option is valid only for the if=scsi drive interface:

qemu-system-ARCH [...] -drive file=/path/to/file.img,if=scsi,discard=on

Warning

if=scsi is not supported. This interface doesn't map to virtio-scsi, but rather to the lsi scsi adapter.

28.3.1.2 virtio-blk-data-plane #

The virtio-blk-data-plane is a new performance feature for KVM. It enables a high-performance code path for I/O requests coming from VM Guests. More specifically, this feature introduces dedicated threads (one per virtual block device) to process I/O requests going through the virtio-blk driver. It makes use of Linux AIO (asynchronous I/O interface) support in the VM Host Server Kernel directly—without the need to go through the QEMU block layer. Therefore it can sustain very high I/O rates on storage setups.

The virtio-blk-data-plane feature can be enabled or disabled by the x-data-plane=on|off option on the qemu command line when starting the VM Guest:

qemu [...] -drive if=none,id=drive0,cache=none,aio=native,\
format=raw,file=filename -device virtio-blk-pci,drive=drive0,scsi=off,\
config-wce=off,x-data-plane=on [...]

As of now, the virtio-blk-data-plane has the following limitations:

• Only raw image format is supported.

• No support for live migration.

• Block jobs and hot unplug operations fail with -EBUSY.

• I/O throttling limits are ignored.

• Only Linux VM Host Servers are supported because of the Linux AIO usage, but non-Linux VM Guests are supported.

Important

The virtio-blk-data-plane feature is not yet supported in SUSE Linux Enterprise Server. It is released as a technical preview only.

28.3.1.3 Bio-Based I/O Path for virtio-blk #

For better performance of I/O-intensive applications, a new I/O path was introduced for the virtio-blk interface in kernel version 3.7. This bio-based block device driver skips the I/O scheduler, and thus shortens the I/O path in guest and has lower latency. It is especially useful for high-speed storage devices, such as SSD disks.

The driver is disabled by default. To use it, do the following:

1. Append virtio_blk.use_bio=1 to the kernel command line on the guest. You can do so via YaST › System › Boot Loader.

   You can do it also by editing /etc/default/grub, searching for the line that contains GRUB_CMDLINE_LINUX_DEFAULT=, and adding the kernel parameter at the end. Then run grub2-mkconfig >/boot/grub2/grub.cfg to update the grub2 boot menu.

2. Reboot the guest with the new kernel command line active.

Tip: Bio-Based Driver on Slow Devices

The bio-based virtio-blk driver does not help on slow devices such as spin hard disks. The reason is that the benefit of scheduling is larger than what the shortened bio path offers. Do not use the bio-based driver on slow devices.

This section describes QEMU options affecting the type of the emulated video card and the way VM Guest graphical output is displayed.

There are two ways to create USB devices usable by the VM Guest in KVM: you can either emulate new USB devices inside a VM Guest, or assign an existing host USB device to a VM Guest. To use USB devices in QEMU you first need to enable the generic USB driver with the -usb option. Then you can specify individual devices with the -usbdevice option.

28.3.3.2 USB Pass-Through #

To assign an existing host USB device to a VM Guest, you need to find out its host bus and device ID.

tux@vmhost:~> lsusb
[...]
Bus 002 Device 005: ID 12d1:1406 Huawei Technologies Co., Ltd. E1750
[...]

In the above example, we want to assign a USB stick connected to the host's USB bus number 2 with device number 5. Now run the VM Guest with the following additional options:

qemu-system-ARCH [...] -usb -device usb-host,hostbus=2,hostaddr=5

After the guest is booted, check that the assigned USB device is present on it.

tux@vmguest:~> lsusb
[...]
Bus 001 Device 002: ID 12d1:1406 Huawei Technologies Co., Ltd. E1750
[...]

Note

The guest operating system must take care of mounting the assigned USB device so that it is accessible for the user.

PCI Pass-Through is a technique to give your VM Guest exclusive access to a PCI device.

Note: Prereqisites

To make use of PCI Pass-Through, your motherboard chipset, BIOS, and CPU must have support for IOMMU (AMD) or VT-d (Intel) virtualization technology. To make sure that your computer supports this feature, ask your supplier specifically to deliver a system that supports PCI Pass-Through.

Assigning graphics cards is not supported by SUSE.

Note: Consider Using libvirt for Setting Up PCI Pass-Through

There are some factors affecting successful PCI Pass-Through that are best handled programmatically. If you encounter problems, consider instead relying on libvirt to manage guests that use PCI Pass-Through devices. Refer to Section 13.7, “Adding a PCI Device with virsh” or Section 13.6, “Adding a PCI Device with Virtual Machine Manager” for details.

Note

If the PCI device shares IRQ with other devices, it cannot be assigned to a VM Guest.

KVM also supports PCI device hotplugging to a VM Guest. To achieve this, you need to switch to a QEMU monitor (see Chapter 30, Administrating Virtual Machines with QEMU Monitor for more information) and issue the following commands:

VFIO stands for Virtual Function I/O and is a new user-level driver framework for Linux. It is meant to replace the traditional PCI device assignment. The VFIO driver exposes direct device access to userspace in a secure memory (IOMMU) protected environment.

Compared to KVM PCI device assignment, VFIO interface has the following advantages:

01:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)

# readlink /sys/bus/pci/devices/0000:01:10.0/iommu_group
../../../../kernel/iommu_groups/15

ls -l /sys/bus/pci/devices/0000:01:10.0/iommu_group/devices/0000:01:10.0
[...] 0000:00:1e.0 -> ../../../../devices/pci0000:00/0000:00:1e.0
[...] 0000:01:10.0 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:01:10.0
[...] 0000:01:10.1 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:01:10.1

# sudo qemu-system-ARCH [...] -device vfio-pci,host=01:10.0,id=net0

Use -chardev to create a new character device. The option uses the following general syntax:

qemu-system-ARCH [...] -chardev backend_type,id=id_string

where backend_type can be one of null, socket, udp, msmouse, vc, file, pipe, console, serial, pty, stdio, braille, tty, or parport. All character devices must have a unique identification string up to 127 characters long. It is used to identify the device in other related directives. For the complete description of all back-end's suboptions, see the manual page (man 1 qemu). A brief description of the available back-ends follows:

By default QEMU creates a set of character devices for serial and parallel ports, and a special console for QEMU monitor. You can, however, create your own character devices and use them for the just mentioned purposes. The following options will help you:

For a complete list of available character devices back-ends, see the man page (man 1 qemu).

Use -net nic to add a new emulated network card:

qemu-system-ARCH [...] -net nic,vlan=11,macaddr=00:16:35:AF:94:4B2,\
model=virtio3,name=ncard14 -net user

The -net user option instructs QEMU to use user-mode networking. This is the default if no networking mode is selected. Therefore, these command lines are equivalent:

qemu-system-ARCH -hda /images/sles_base.raw

qemu-system-ARCH -hda /images/sles_base.raw -net nic -net user

This mode is useful if you want to allow the VM Guest to access the external network resources, such as the Internet. By default, no incoming traffic is permitted and therefore, the VM Guest is not visible to other machines on the network. No administrator privileges are required in this networking mode. The user-mode is also useful for doing a 'network-booting' on your VM Guest from a local directory on VM Host Server.

The VM Guest allocates an IP address from a virtual DHCP server. VM Host Server (the DHCP server) is reachable at 10.0.2.2, while the IP address range for allocation starts from 10.0.2.15. You can use ssh to connect to VM Host Server at 10.0.2.2, and scp to copy files back and forth.

qemu-system-ARCH [...] -net user1,vlan=12,name=user_net13,restrict=yes4

qemu-system-ARCH [...] -net user,net=10.2.0.0/81,host=10.2.0.62,dhcpstart=10.2.0.203,\
hostname=tux_kvm_guest4

qemu-system-ARCH [...] -net user,tftp=/images/tftp_dir1,bootfile=/images/boot/pxelinux.02

qemu-system-ARCH [...] -net user,hostfwd=tcp::2222-:22

ssh qemu_host -p 2222

With the -net tap option, QEMU creates a network bridge by connecting the host TAP network device to a specified VLAN of VM Guest. Its network interface is then visible to the rest of the network. This method does not work by default and has to be explicitly specified.

First, create a network bridge and add a VM Host Server physical network interface (usually eth0) to it:

28.4.3.1 Connecting to a Bridge Manually #

Use the following example script to connect VM Guest to the newly created bridge interface br0. Several commands in the script are run via the sudo mechanism because they require root privileges.

Note

Make sure the tunctl and bridge-utils packages are installed on the VM Host Server. If not, install them with zypper in tunctl bridge-utils.

#!/bin/bash
bridge=br01
tap=$(sudo tunctl -u $(whoami) -b)2
sudo ip link set $tap up3
sleep 1s4
sudo brctl addif $bridge $tap5
qemu-system-ARCH -machine accel=kvm -m 512 -hda /images/sles_base.raw \
-net nic,vlan=0,model=virtio,macaddr=00:16:35:AF:94:4B \
-net tap,vlan=0,ifname=$tap6,script=no7,downscript=no
sudo brctl delif $bridge $tap8
sudo ip link set $tap down9
sudo tunctl -d $tap10

1	Name of the bridge device.
2	Prepare a new TAP device and assign it to the user who runs the script. TAP devices are virtual network devices often used for virtualization and emulation setups.
3	Bring up the newly created TAP network interface.
4	Make a 1-second pause to make sure the new TAP network interface is really up.
5	Add the new TAP device to the network bridge br0.
6	The ifname= suboption specifies the name of the TAP network interface used for bridging.
7	Before qemu-system-ARCH connects to a network bridge, it checks the script and downscript values. If it finds the specified scripts on the VM Host Server file system, it runs the script before it connects to the network bridge and downscript after it exits the network environment. You can use these scripts to first set up and bring up the bridged network devices, and then to deconfigure them. By default, /etc/qemu-ifup and /etc/qemu-ifdown are examined. If script=no and downscript=no are specified, the script execution is disabled and you have to take care of it manually.
8	Deletes the TAP interface from a network bridge br0.
9	Sets the state of the TAP device to 'down'.
10	Deconfigures the TAP device.

28.4.3.2 Connecting to a Bridge with qemu-bridge-helper #

Another way to connect VM Guest to a network through a network bridge is by means of the qemu-bridge-helper helper program. It configures the TAP interface for you, and attaches it to the specified bridge. The default helper executable is /usr/lib/qemu-bridge-helper. The helper executable is setuid root, which is only executable by the members of the virtualization group (kvm). Therefore the qemu-system-ARCH command itself does not have to be run under root privileges.

You can call the helper the following way:

qemu-system-ARCH [...] -net nic,vlan=0,model=virtio -net bridge,vlan=0,br=br0

You can specify your own custom helper script that will take care of the TAP device (de)configuration, with the helper=/path/to/your/helper option:

qemu-system-ARCH [...] -net bridge,vlan=0,br=br1,helper=/path/to/bridge-helper

Tip

To define access privileges to qemu-bridge-helper, inspect the /etc/qemu/bridge.conf file. For example the following directive

allow br0

allows the qemu-system-ARCH command to connect its VM Guest to the network bridge br0.

The vhost-net module is used to accelerate KVM's paravirtualized network drivers. It provides better latency and greater throughput for network.

To make use of the module, verify that the host's running Kernel has CONFIG_VHOST_NET turned on or enabled as a module:

grep CONFIG_VHOST_NET /boot/config-`uname -r`

Also verify that the guest's running Kernel has CONFIG_PCI_MSI enabled:

grep CONFIG_PCI_MSI /boot/config-`uname -r`

If both conditions are met, use the vhost-net driver by starting the guest with the following example command line:

qemu-system-ARCH [...] -netdev tap,id=guest0,vhost=on,script=no
-net nic,model=virtio,netdev=guest0,macaddr=00:16:35:AF:94:4B

Note that guest0 is an identification string of the vhost-driven device.

As the number of virtual CPUs increases in VM Guests, QEMU offers a way of improving the network performance using multiqueue. Multiqueue virtio-net scales the network performance by allowing VM Guest virtual CPUs to transfer packets in parallel. Multiqueue support is required on both VM Host Server and VM Guest side.

Tip: Performance Benefit

The Multiqueue virtio-net solution is most beneficial in the following cases:

• Network traffic packets are large.

• VM Guest has more connections active at the same time, mainly between the guest systems, or between the guest and the host, or between the guest and an external system.

• The number of active queues is equal to the number of virtual CPUs in the VM Guest.

Note

While multiqueue virtio-net increases the total network throughput, it increases CPU consumption as it makes use of the virtual CPU's power.

The resulting qemu-system-ARCH command line will look similar to the following example:

qemu-system-ARCH [...] -netdev tap,id=guest0,queues=4,vhost=on \
-device virtio-net-pci,netdev=guest0,mq=on,vectors=10

Note that the id of the network device (guest0 ) needs to be identical for both options.

Inside the running VM Guest, specify the following command as root:

ethtool -L eth0 combined 8

Now the guest system networking makes use of the multiqueue support from the qemu-system-ARCH hypervisor.

The default VNC server setup does not use any form of authentication. In the previous example, any user can connect and view the QEMU VNC session from any host on the network.

There are several levels of security that you can apply to your VNC client/server connection. You can either protect your connection with a password, use x509 certificates, use SASL authentication, or even combine some of these authentication methods in one QEMU command.

See Section B.2, “Generating x509 Client/Server Certificates” for more information about the x509 certificates generation. For more information about configuring x509 certificates on a VM Host Server and the client, see Section 11.3.2, “Remote TLS/SSL Connection with x509 Certificate (qemu+tls or xen+tls)” and Section 11.3.2.3, “Configuring the Client and Testing the Setup”.

The Vinagre VNC viewer supports advanced authentication mechanisms. Therefore, it will be used to view the graphical output of VM Guest in the following examples. For this example, let us assume that the server x509 certificates ca-cert.pem, server-cert.pem, and server-key.pem are located in the /etc/pki/qemu directory on the host, while the client's certificates are distributed in the following locations on the client:

qemu-system-ARCH [...] -vnc :5,password -monitor stdio

QEMU 2.0.0 monitor - type 'help' for more information
(qemu) change vnc password
Password: ****

Figure 28.4: Authentication Dialog in Vinagre #

qemu-system-ARCH [...] -vnc :5,tls,x509verify=/etc/pki/qemu

qemu-system-ARCH [...] -vnc :5,password,tls,x509verify=/etc/pki/qemu -monitor stdio

qemu-system-ARCH [...] -vnc :5,tls,x509,sasl -monitor stdio

In QEMU, the implementation of VirtFS is facilitated by defining two types of devices:

qemu-system-ARCH [...] -fsdev local,id=exp11,path=/tmp/2,security_model=mapped3
-device virtio-9p-pci,fsdev=exp14,mount_tag=v_tmp5

sudo mount -t 9p -o trans=virtio v_tmp /mnt