To improve the performance of the guest operating system, para-virtualized drivers are provided when available. Although they are not required, it is strongly recommended to use them. The para-virtualized drivers are available as follows:

Change the proposed configuration by clicking on a headline in the Summary page of the Create Virtual Machine Wizard:

4.1.1.2. Hardware¶

Change memory and CPU assignments in this screen. It is recommended not to specify values larger than the resources the VM Host Server can provide (overcommit), since it may result in errors or performance penalties.

The Advanced Settings lets you activate or deactivate ACPI, APIC, and PAE. It is recommended not to change the default settings. You can also enable or disable para-virtualized I/O with virtio or choose to execute the kernel on boot (linux only) here.

	Para-Virtualized I/O
If you enable para-virtualized I/O by activating virtio, all hard disks you create will be configured as virtio disks. If your operating system does not have appropriate drivers, the installation will fail. A Windows operating system installation even fails if providing a driver. By default, this feature is only activated for operating systems known to ship with virtio drivers.

4.1.1.4. Disks¶

Disks: Manage virtual hard disks and CD/DVD drives in this dialog. A VM Guest must have at least one virtual disk—either an existing one or a newly created disk. Virtual disks can be:

• a single file with a fixed size

• a single file that grows on demand (Sparse Image File)

  	Sufficient Space for Sparse Image Files
  When creating sparse image files, the partition on which you create them always needs sufficient free space. The VM Guest has no means to check the VM Host Server disk space. Having no space left on the host partition causes write errors and loss of data on the guest system.

• a block device, such as an entire disk, partition, or a network volume.

For best performance, create each virtual disk from an entire disk or a partition. For the next best performance, create an image file but do not create it as a sparse image file. A virtual disk based on a sparse image file delivers the most disk space flexibility but slows installation and disk access speeds.

	Live Migration
If you need to be able to migrate your VM Guest to another host without shutting it down (live migration), all disks must reside on a network resource (network file system or iSCSI volume) that is accessible from both hosts.

By default, a single sparse raw disk image file is created in /var/lib/kvm/images/VM_NAME/ where VM_NAME is the name of the virtual machine.

	Supported Disk format
Currently, only the disk formats raw, qed and qcow2 are supported by SUSE.

Procedure 4.1. Creating a Virtual Disk

1. Click Harddisk.

2. Enter a Source. If creating a file-backed disk, either enter the path directly or click New. When creating a disk from a device, enter the device node, for example /dev/disk/by-path/path. It is strongly recommended not to use the simple device paths such as /dev/sdb or /dev/sda5, since they may change (by adding a disk or by changing the disk order in the BIOS).

3. Specify the Protocol. For creating raw disks, choose either file for file-backed virtual disks or phy for device-backed disks. qcow2 or qed disks can be created by choosing the corresponding value.

4. Enter a Size in GB. This option is only available for file-backed disks.

5. Choose whether to create a Sparse Image File. This option is only available for file-backed disks. If you want to disable write-access to the disk, choose Read-Only Access.

If you want to install from DVD or CD-ROM, add the drive to the list of available hard disks. To learn about device nodes of the available optical drives, run:

hwinfo --cdrom | egrep "(Device File:|Model:)"

Instead of the real DVD or CD-ROM drive, you can also add the ISO image of an installation medium. Note that each CD-Rom drive or ISO image can only be used by one guest at the same time.

To add a CD/DVD-ROM device or an ISO image, proceed as follows:

1. Click CD-ROM.

2. Enter a Source. If adding a device, enter its node. If adding an ISO image, either enter the path directly or click Browse to open a file browser.

3. Specify the Protocol. Choose file for an ISO image and phy for a device.

The disks are listed in the order in which they have been created. This order also represents the boot order. Use the Up and Down arrows to change the disk order.

vm-install provides the --no-install parameter. With this parameter the XML configuration file defining the VM Guest is created, but the guest is not booted automatically. You may use it regardless whether you start vm-install in wizard mode or whether you specify all other options in the command line. You can start the installation.

	No Virtual Disk Creation
When using the --no-install parameter with vm-install, no virtual disks will be created. Therefore, you have to create the disks in advance using either qemu-img or virsh.

Once the VM Guest XML configuration file is successfully created, you need to “register” it so it is recognized by Virtual Machine Manager or virsh. Do so by running:

virsh -c qemu:///system define PATH_TO_XMLFILE

Some operating systems such as openSUSE and SUSE Linux Enterprise Server offer to include add-on products in the installation process. In case the add-on product installation source is provided via network, no special VM Guest configuration is needed. If it is provided via CD/DVD or ISO image, it is necessary to provide the VM Guest installation system with both, the standard installation images and the image for the add-on product.

First add the standard installation image, and second the physical CD/DVD-ROM or add-on image. The image or device added first is automatically chosen as the boot image. In case you install openSUSE or SUSE Linux Enterprise Server, it will be configured as /dev/sr0, while the add-on product source will be configured as /dev/sr1.

The main Window of the Virtual Machine Manager shows a list of all VM Guests for each VM Host Server it is connected to. Each VM Guest entry contains the machine's name, its status (Running, Paused, or Shutoff) displayed as icon and literal, and a CPU usage bar.

Use the command virsh list to get a list of VM Guests:

virt-viewer is a simple VNC viewer with added functionality for displaying VM Guest consoles. It can, for example, be started in “wait” mode, where it waits for a VM Guest to start before it connects. It also supports automatically reconnecting to a VM Guest that is rebooted.

virt-viewer addresses VM Guests by name, by ID or by UUID. Use virsh list --all to get this data.

To connect to a guest that is running or paused, either use the ID, UUID, or name. VM Guests that are shut off do not have an ID—you can only connect by UUID or name.

For more information, see virt-viewer --help or man 1 virt-viewer.

Changing a VM Guest's state can either be done from Virtual Machine Manager's main window, or from a VNC window.

In the following examples the state of a VM Guest named “sles11” is changed.

Save a running VM Guest with the command virsh save and specify the file to where it is saved.

To restore it, use virsh restore:

virsh restore /virtual/saves/opensuse11.vmsave

To delete a VM Guest with virsh run virsh undefine VM_NAME. There is no option to automatically delete the attached storage files.

libvirtd authentication is configured in /etc/libvirt/libvirtd.conf. The configuration made here applies to all libvirt tools such as the Virtual Machine Manager or virsh.

libvirt offers two sockets: a read-only socket for monitoring purposes and a read-write socket to be used for management operations. Access to both sockets can be configured independently. By default, both sockets are owned by root.root. Default access permissions on the read-write socket are restricted to the user root (0700) and fully open on the read-only socket (0777).

In the following instructions you learn how to configure access permissions for the read-write socket. The same instructions also apply to the read-only socket. All configuration steps have to be carried out on the VM Host Server.

	Default Authentication Settings on openSUSE
The default authentication method on openSUSE is access control for UNIX sockets. Only the user root may authenticate. When accessing the libvirt tools as a non-root user directly on the VM Host Server, you need to provide the root password through PolicyKit once and are granted access for the current and for future sessions.

6.1.1.2. Local Access Control for UNIX Sockets with PolicyKit¶

Access control for UNIX sockets with PolicyKit is the default authentication method on openSUSE for non-remote connections. Therefore, no libvirt configuration changes are needed. With PolicyKit authorization enabled, permissions on both sockets default to 0777 and each application trying to access a socket needs to authenticate via PolicyKit. openSUSE

	PolicyKit Authentication for Local Connections Only
Authentication with PolicyKit can only be used for local connections on the VM Host Server itself, since PolicyKit does not handle remote authentication.

Two policies for accessing libvirt's sockets exist:

• org.libvirt.unix.monitor: accessing the read-only socket

• org.libvirt.unix.manage: accessing the read-write socket

By default, the policy for accessing the read-write socket is to authenticate with root password once and grant the privilege for the current and for future sessions (auth_admin_keep_always).

In order to grant users access to the read-write socket without having to provide the root password, there are two possibilities:

1. Using the polkit-auth command, you can grant the privilege without any restrictions:

   polkit-auth --user tux --grant org.libvirt.unix.manage    # grant privilege
   polkit-auth --user tux --revoke org.libvirt.unix.manage   # revoke privilege

2. Editing /etc/PolicyKit/PolicyKit.conf offers more advanced options. Add the following XML snippet in between the existing <config version="0.1"> and </config> tags:

   <match action="org.libvirt.unix.manage">
     <match user="tux">
       <return result="yes"/>
     </match>
   </match>

   	The name of the policy; org.libvirt.unix.manage stands for accessing the read-write socket.
   	The username(s) which to grant the privilege. Use the | symbol to separate entries (user="tux|wilber").
   	The privilege that is granted. The following options exist: yes (no restrictions), no (block access completely), auth_self or auth_admin (authenticate with own password/root password every time the privilege is requested), auth_self_keep_session or auth_admin_keep_session (authenticate with own password/root password once per session) and auth_self_keep_always or auth_admin_keep_always (authenticate only once with own password/root password).

6.1.1.3. Username and Password Authentication with SASL¶

SASL provides username and password authentication as well as data encryption (digest-md5, by default). Since SASL maintains its own user database, the users do not need to exist on the VM Host Server. SASL is required by TCP connections and on top of TLS/SSL connections.

	Plain TCP and SASL with digest-md5 Encryption
Using digest-md5 encryption on an otherwise unencrypted TCP connection does not provide enough security for production environments. It is recommended to only use it in testing environments.

	SASL Authentication on Top of TLS/SSL
Access from remote TLS/SSL connections can be indirectly controlled on the client side by restricting access to the certificate's key file. However, this might prove error-prone when dealing with a large number of clients. Utilizing SASL with TLS adds security by additionally controlling access on the server side.

To configure SASL authentication, proceed as follows:

1. Change the configuration in /etc/libvirt/libvirtd.conf as follows:

   1. To enable SASL for TCP connections:

      auth_tcp = "sasl"

   2. To enable SASL for TLS/SSL connections:

      auth_tls = "sasl"

2. Restart libvirtd:

   rclibvirtd restart

3. The libvirt SASL configuration file is located at /etc/sasl2/libvirtd.conf. Normally, there is no need to change the defaults. However, if using SASL on top of TLS, you may turn off session encryption to avoid additional overhead— TLS connections are already encrypted— by commenting the mech_list. For TCP connections this parameter must be set to digest-md5:

   mech_list: digest-md5   # mandatory for TCP connections
   #mech_list: digest-md5   # apply default (username+password) TLS/SSL only!

4. By default, no SASL users are configured, so no logins are possible. Use the following commands to add, list, and delete users:

   mercury:~ # saslpasswd2 -a libvirt tux                  # add user tux
   Password: 
   Again (for verification): 
   mercury:~ # sasldblistusers2 -f /etc/libvirt/passwd.db  # list users
   tux@mercury.example.com: userPassword
   mercury:~ # saslpasswd2 -a libvirt -d tux               # delete user tux

	virsh and SASL Authentication
When using SASL authentication you will be prompted for a username and password every time you issue a virsh command. Avoid this by using virsh in shell mode.

Since access to the graphical console of a VM Guest is not controlled by libvirt, but rather by QEMU, it is always necessary to additionally configure VNC authentication. The main configuration file is /etc/libvirt/qemu.conf.

Two authentication types are available: SASL and single password authentication. If you are using SASL for libvirt authentication, it is strongly recommended to use it for VNC authentication as well—it is possible to share the same database.

A third method to restrict access to the VM Guest is to enable the use of TLS encryption on the VNC server. This requires the VNC clients to have access to x509 client certificates. By restricting access to these certificates, access can indirectly be controlled on the client side. Refer to Section 6.2.2.4.2, “VNC over TLS/SSL: Client Configuration” for details.

6.1.2.1. Username and Password Authentication with SASL¶

SASL provides username and password authentication as well as data encryption. Since SASL maintains its own user database, the users do not need to exist on the VM Host Server. As with SASL authentication for libvirt, you may use SASL on top of TLS/SSL connections. Refer to Section 6.2.2.4.2, “VNC over TLS/SSL: Client Configuration” for details on configuring these connections.

To configure SASL authentication for VNC, proceed as follows:

1. Create a SASL configuration file. It is recommended to use the existing libvirt file. If you have already configured SASL for libvirt and are planning to use the same settings including the same username/password database, a simple link is suitable:

   ln -s /etc/sasl2/libvirt.conf /etc/sasl2/qemu.conf

   In case you are setting up SASL for VNC only or planning to use a different configuration than for libvirt, copy the existing file to use as a template and edit it according to your needs:

   cp /etc/sasl2/libvirt.conf /etc/sasl2/qemu.conf

2. By default, no SASL users are configured, so no logins are possible. Use the following commands to add, list, and delete users:

   mercury:~ # saslpasswd2 -a libvirt tux                  # add user tux
   Password: 
   Again (for verification): 
   mercury:~ # sasldblistusers2 -f /etc/libvirt/passwd.db  # list users
   tux@mercury.example.com: userPassword
   mercury:~ # saslpasswd2 -a libvirt -d tux               # delete user tux

3. Change the configuration in /etc/libvirt/qemu.conf as follows:

   vnc_listen = "0.0.0.0"
   vnc_sasl = 1

   The first parameter enables VNC to listen on all public interfaces (rather than to the local host only), and the second parameter enables SASL authentication.

4. Restart libvirtd:

   rclibvirtd restart

5. Restart all VM Guests that have been running prior to changing the configuration. VM Guests that have not been restarted will not use SASL authentication for VNC connects.

	Supported VNC Viewers
Currently only the same VNC viewers that also support TLS/SSL connections, support SASL authentication, namely Virtual Machine Manager, virt-viewer, and vinagre.

6.1.2.2. Single Password Authentication¶

Access to the VNC server may also be controlled by setting a VNC password. You can either set a global password for all VM Guests or set individual passwords for each guest. The latter requires to edit the VM Guest's config files.

	Always Set a Global Password
If you are using the single password authentication, it is good practice to set a global password even if setting passwords for each VM Guest. This will always leave your virtual machines protected with a “fallback” password if you forget to set a per-machine password. The global password will only be used if no other password is set for the machine.

Procedure 6.1. Setting a Global VNC Password

1. Change the configuration in /etc/libvirt/qemu.conf as follows:

   vnc_listen = "0.0.0.0"
          vnc_password = "PASSWORD"

   The first parameter enables VNC to listen on all public interfaces (rather than to the local host only), and the second parameter sets the password. The maximum length of the password is eight characters.

2. Restart libvirtd:

   rclibvirtd restart

3. Restart all VM Guests that have been running prior to changing the configuration. VM Guests that have not been restarted will not use password authentication for VNC connects.

Procedure 6.2. Setting a VM Guest Specific VNC Password

1. Change the configuration in /etc/libvirt/qemu.conf as follows to enable VNC to listen on all public interfaces (rather than to the local host only).

   vnc_listen = "0.0.0.0"

2. Open the VM Guest's XML configuration file in an editor. Replace VM NAME in the following example with the name of the VM Guest. The editor that is used defaults to $EDITOR. If that variable is not set, vi is used.

   virsh edit VM NAME

3. Search for the element <graphics> with the attribute type='vnc', for example:

   <graphics type='vnc' port='-1' autoport='yes'/>

4. Add the passwd=PASSWORD attribute, save the file and leave the editor. The maximum length of the password is eight characters.

   <graphics type='vnc' port='-1' autoport='yes' passwd='PASSWORD'/>

5. Restart libvirtd:

   rclibvirtd restart

6. Restart all VM Guests that have been running prior to changing the configuration. VM Guests that have not been restarted will not use password authentication for VNC connects.

	Security
The VNC protocol is not considered to be safe. Although the password is sent encrypted, it might be vulnerable, when an attacker is able to sniff both, the encrypted password and the encryption key. Therefore, it is recommended to use VNC with TLS/SSL or tunneled over SSH. virt-viewer, as well as the Virtual Machine Manager and vinagre from version 2.30 on, support both methods.

Enabling a remote connection that is tunneled over SSH on the VM Host Server only requires the ability to accept SSH connections. Make sure the SSH daemon is started (rcsshd status) and that the ports for service SSH are opened in the firewall.

User authentication for SSH connections can be done using traditional file user/group ownership and permissions as described in Section 6.1.1.1, “Access Control for UNIX Sockets with Permissions and Group Ownership”. Connecting as user root (qemu+ssh://root@mercury.example.com/system) works out of the box and does not require additional configuration on the libvirt side.

When connecting via SSH qemu+ssh://USER@SYSTEM you need to provide the password for USER. This can be avoided by copying your public key to ~USER/.ssh/authorized_keys on the VM Host Server as explained in Section “Copying an SSH Key” (Chapter 12, SSH: Secure Network Operations, ↑Security Guide). Using an ssh-agent on the machine from which you are connecting adds even more convenience—see Section “Using the ssh-agent” (Chapter 12, SSH: Secure Network Operations, ↑Security Guide) for instructions.

Using TCP connections with TLS/SSL encryption and authentication via x509 certificates is much more complicated to set up than SSH, but it is a lot more scalable. Use this method if you have to manage several VM Host Servers with a varying number of administrators.

6.2.2.1. Basic concept¶

Basically, TLS (Transport Layer Security) encrypts the communication between two computers by using certificates. The computer starting the connection is always considered as the “client” using a “client certificate”, while the receiving computer is always considered as the “server”, using a “server certificate”. This scenario applies, for example, if you manage your VM Host Servers from a central desktop.

If connections are initiated from both computers, each needs to have a client and a server certificate. This is the case, for example, if you migrate a VM Guest from one host to another.

Each x509 certificate has a matching private key file. Only the combination of certificate and private key file is able to identify itself correctly. In order to assure that a certificate was issued by the assumed owner, it is signed and issued by a central certificate called certification authority (CA). Both the client and the server certificates must be issued by the same CA.

User Authentication

Using a remote TLS/SSL connection basically only ensures that two computers are allowed to communicate in a certain direction. Restricting access to certain users can indirectly be achieved on the client side by restricting access to the certificates. Refer to Section 6.2.2.5, “Restricting Access (Security Considerations)” for details. libvirt also supports user authentication on the server with SASL. Read more in Section 6.2.2.6, “Central User Authentication with SASL for TLS Sockets”.

6.2.2.2. Configuring the VM Host Server¶

The VM Host Server is the machine receiving connections. Therefore, the server certificates have to be installed. The CA certificate needs to be installed, as well. Once the certificates are in place, TLS support can be turned on for libvirt.

1. Create the server certificate and export it together with the CA certificate as described in Section A.2, “Generating x509 Client/Server Certificates”.

2. Create the following directories on the VM Host Server:

   mkdir -p /etc/pki/CA/ /etc/pki/libvirt/private/

   Install the certificates as follows:

   /etc/pki/CA/cacert.pem
   /etc/pki/libvirt/servercert.pem
   /etc/pki/libvirt/private/serverkey.pem

   	Restrict Access to Certificates
   Make sure to restrict access to certificates as explained in Section 6.2.2.5, “Restricting Access (Security Considerations)”.

3. Enable TLS support by editing /etc/libvirt/libvirtd.conf and setting listen_tls = 1. Restart libvirtd:

   rclibvirtd restart

4. By default, libvirt uses the TCP port 16514 for accepting secure TLS connections. Open this port in the firewall.

	Restarting libvirtd with TLS enabled
If you enable TLS for libvirt, the server certificates need to be in place, otherwise restarting libvirtd will fail. You also need to restart libvirtd in case you change the certificates.

6.2.2.4. Enabling VNC for TLS/SSL connections¶

Currently, VNC communication over TLS is only supported by few tools. The widespread tightvnc or tigervnc viewer, for example, do not support TLS. Known to work are the Virtual Machine Manager (virt-manager), virt-viewer and the GNOME VNC viewer vinagre.

6.2.2.4.1. VNC over TLS/SSL: VM Host Server Configuration¶

In order to access the graphical console via VNC over TLS/SSL, you need to configure the VM Host Server as follows:

1. Open ports for the service VNC in your firewall.

2. Create a directory /etc/pki/libvirt-vnc and link the certificates into this directory as follows:

   mkdir -p /etc/pki/libvirt-vnc && cd /etc/pki/libvirt-vnc
   	ln -s /etc/pki/CA/cacert.pem ca-cert.pem
   	ln -s /etc/pki/libvirt/servercert.pem server-cert.pem
   	ln -s /etc/pki/libvirt/private/serverkey.pem server-key.pem

3. Edit /etc/libvirt/qemu.conf and set the following parameters:

   vnc_listen = "0.0.0.0"
   	vnc_tls = 1
   	vnc_tls_x509_verify = 1

4. Restart the libvirtd:

   rclibvirtd restart

   	VM Guests Need to be Restarted
   The VNC TLS setting is only set when starting a VM Guest. Therefore, you need to restart all machines that have been running prior to making the configuration change.

6.2.2.4.2. VNC over TLS/SSL: Client Configuration¶

The only action needed on the client side is to place the x509 client certificates in a location recognized by the client of choice. Unfortunately, each supported client—Virtual Machine Manager, virt-viewer, and vinagre—expects the certificates in a different location. However, Virtual Machine Manager and vinagre can either read from a system wide location applying to all users, or from a per user location.

Virtual Machine Manager (virt-manager)

In order to connect to the remote host, Virtual Machine Manager requires the setup explained in Section 6.2.2.3, “Configuring the Client and Testing the Setup”. In order to be able to connect via VNC the client certificates also need to be placed in the following locations:

System wide location

/etc/pki/CA/cacert.pem

/etc/pki/libvirt-vnc/clientcert.pem

/etc/pki/libvirt-vnc/private/clientkey.pem

Per user location

/etc/pki/CA/cacert.pem

~/.pki/libvirt-vnc/clientcert.pem

~/.pki/libvirt-vnc/private/clientkey.pem

virt-viewer

virt-viewer only accepts certificates from a system wide location:

/etc/pki/CA/cacert.pem

/etc/pki/libvirt-vnc/clientcert.pem

/etc/pki/libvirt-vnc/private/clientkey.pem

vinagre

System wide location

/etc/pki/CA/cacert.pem

/etc/pki/vinagre/clientcert.pem

/etc/pki/vinagre/private/clientkey.pem

Per user location

$HOME/.pki/CA/cacert.pem

~/.pki/vinagre/clientcert.pem

~/.pki/vinagre/private/clientkey.pem

	Restrict Access to Certificates
Make sure to restrict access to certificates as explained in Section 6.2.2.5, “Restricting Access (Security Considerations)”.

tls_allowed_dn_list = [
   "C=US,L=Provo,O=SUSE Linux Products GmbH,OU=*,CN=venus.example.com,EMAIL=*",
   "C=DE,L=Nuremberg,O=SUSE Linux Products GmbH,OU=Documentation,CN=*"]

certtool -i --infile /etc/pki/libvirt/clientcert.pem | grep "Subject:"

rclibvirtd restart

ps ax | grep qemu | grep "\-name sles11" | awk -F" -vnc " '{ print FS $2 }'

 -vnc 0.0.0.0:0,tls,x509verify=/etc/pki/libvirt

The Virtual Machine Manager uses a Connection for every VM Host Server it manages. Each connection contains all VM Guests on the respective host. By default, a connection to the localhost is already configured and connected.

All configured connections are displayed in the Virtual Machine Manager main window. Active connections are marked with a small triangle which you can click in order to fold or unfold the list of VM Guests for this connection.

Inactive connections are listed gray and are marked with Not Connected. Either double-click or right-click it and choose Connect from the context menu. You can also Delete an existing connection from this menu.

	Editing Existing Connections
It is not possible to edit an existing connection. In order to change a connection, create a new one with the desired parameters and delete the “old” one.

To add a new connection in the Virtual Machine Manager, proceed as follows:

To add a storage pool, proceed as follows:

Virtual Machine Manager's Storage Manager lets you create or delete volumes in a pool. You may also temporarily deactivate or permanently delete existing storage pools. Changing the basic configuration of a pool is currently not supported by SUSE.

7.1.2.1. Starting, Stopping and Deleting Pools¶

The purpose of storage pools is to provide block devices located on the VM Host Server, that can be added to a VM Guest when managing it from remote. In order to make a pool temporarily inaccessible from remote, you may Stop it by clicking on the stop symbol in the bottom left corner of the Storage Manager. Stopped pools are marked with State: Inactive and are grayed out in the list pane. By default, a newly created pool will be automatically started On Boot of the VM Host Server.

To Start an inactive pool and make it available from remote again click on the play symbol in the bottom left corner of the Storage Manager.

	A Pool's State Does not Affect Attached Volumes
Volumes from a pool attached to VM Guests are always available, regardless of the pool's state (Active (stopped) or Inactive (started)). The state of the pool solely affects the ability to attach volumes to a VM Guest via remote management.

To permanently make a pool inaccessible, you can Delete it by clicking on the shredder symbol in the bottom left corner of the Storage Manager. You may only delete inactive pools. Deleting a pool does not physically erase its contents on VM Host Server—it only deletes the pool configuration. However, you need to be extra careful when deleting pools, especially when deleting LVM volume group-based tools:

Deleting Storage Pools

Deleting storage pools based on local file system directories, local partitions or disks has no effect on the availability of volumes from these pools currently attached to VM Guests. Volumes located in pools of type iSCSI, SCSI, LVM group or Network Exported Directory will become inaccessible from the VM Guest in case the pool will be deleted. Although the volumes themselves will not be deleted, the VM Host Server will no longer have access to the resources. Volumes on iSCSI/SCSI targets or Network Exported Directory will be accessible again when creating an adequate new pool or when mounting/accessing these resources directly from the host system. When deleting an LVM group-based storage pool, the LVM group definition will be erased and the LVM group will no longer exist on the host system. The configuration is not recoverable and all volumes from this pool are lost.

7.1.2.3. Deleting Volumes From a Storage Pool¶

Deleting a volume can only be done from the Storage Manager, by selecting a volume and clicking Delete Volume. Confirm with Yes. Use this function with extreme care!

	No Checks Upon Volume Deletion
A volume will be deleted in any case, regardless whether it is currently used in an active or inactive VM Guest. There is no way to recover a deleted volume. Whether a volume is used by a VM Guest is indicated in the Used By column in the Storage Manager.

List all pools currently active by executing the following command. To also list inactive pools, add the option --all:

virsh pool-list --details

Details about a specific pool can be obtained with the pool-info subcommand:

virsh pool-info POOL

Volumes can only be listed per pool by default. To list all volumes from a pool, enter the following command.

virsh vol-list --details POOL

At the moment virsh offers no tools to show whether a volume is used by a guest or not. The following procedure describes a way to list volumes from all pools that are currently used by a VM Guest.

Use the virsh pool subcommands to start, stop or delete a pool. Replace POOL with the pool's name or its UUID in the following examples:

virsh offers two ways to create storage pools: either from an XML definition with vol-create and vol-create-from or via command line arguments with vol-create-as. The first two methods are currently not supported by SUSE, therefore this section focuses on the subcommand vol-create-as.

To add a volume to an existing pool, enter the following command:

virsh vol-create-as POOLNAME 12G --formatraw|qcow2|qed --allocation 4G

vol-clone NAME_EXISTING_VOLUMENAME_NEW_VOLUME --pool POOL

To permanently delete a volume from a pool, use the subcommand vol-delete:

virsh vol-delete NAME --pool POOL

--pool is optional. libvirt tries to locate the volume automatically. If that fails, specify this parameter.

	No Checks Upon Volume Deletion
A volume will be deleted in any case, regardless whether it is currently used in an active or inactive VM Guest. There is no way to recover a deleted volume. Whether a volume is used by a VM Guest can only be detected by using by the method described in Procedure 7.1, “Listing all Storage Volumes Currently Used on a VM Host Server”.

KVM provides a para-virtualized clock which is currently supported by openSUSE, SUSE Linux Enterprise Server 10 SP3 and newer and RedHat Enterprise Linux 5.4 and newer via the kvm_clock driver. It is strongly recommended to use kvm_clock when available.

Use the following command inside a VM Guest running Linux to check whether the driver kvm_clock has been loaded:

~ # dmesg | grep kvm-clock
[    0.000000] kvm-clock: cpu 0, msr 0:7d3a81, boot clock
[    0.000000] kvm-clock: cpu 0, msr 0:1206a81, primary cpu clock
[    0.012000] kvm-clock: cpu 1, msr 0:1306a81, secondary cpu clock
[    0.160082] Switching to clocksource kvm-clock

To check which clock source is currently used, run the following command in the VM Guest. It should output kvm-clock:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

	kvm-clock and NTP
When using kvm-clock, it is not recommended to use NTP in the VM Guest, as well. Using NTP on the VM Host Server, however, is still recommended.

The para-virtualized kvm-clock is currently not available for SUSE Linux Enterprise Server 9 and Windows operating systems. For Windows, use the Windows Time Service Tools for time synchronization (see http://technet.microsoft.com/en-us/library/cc773263%28WS.10%29.aspx for more information).

Correct time keeping in SUSE Linux Enterprise Server 9 SP4 can be achieved by using special boot parameters:

When using the Virtual Machine Manager to migrate VM Guests, it does not matter on which machine it is started. You can start Virtual Machine Manager on the source or the target host or even on a third host. In the latter case you need to be able to open remote connections to both the target and the source host.

To migrate a VM Guest with virsh migrate, you need to have direct or remote shell access to the VM Host Server, because the command needs to be run on the host. Basically the migration command looks like this

virsh migrate [OPTIONS] VM_ID_or_NAMECONNECTION URI [--migrateuri tcp://REMOTE_HOST:PORT]

The most important options are listed below. See virsh help migrate for a full list.

The following examples use mercury.example.com as the source system and jupiter.example.com as the target system, the VM Guest's name is opensuse11 with Id 37.

Transient vs. Persistant Migrations

By default virsh migrate creates a temporary (transient) copy of the VM Guest on the target host. A shut down version of the original guest description remains on the source host. A transient copy will be deleted from the server once it is shut down. In order to create a permanent copy of a guest on the target host, use the switch --persistent. A shut down version of the original guest description remains on the source host, too. Use the option --undefinesource together with --persistent for a “real” move where a permanet copy is created on the target host and the version on the source host is deleted. It is not recommended to use --undefinesource without the --persistent option, since this will result in the loss of both VM Guest definitions when the guest is shut down on the target host.

After starting Virtual Machine Manager and connecting to the VM Host Server, a CPU usage graph of all the running guests is displayed.

It is also possible to get information about disk and network usage with this tool, however, you must first activate this in the Preferences:

Afterwards, the disk and network statistics are also displayed in the main window of the Virtual Machine Manager.

More precise data is available from the VNC window. Open a VNC window as described in Section 5.2, “Opening a Graphical Console”. Choose Details from the toolbar or the View menu. The statistics are displayed from the Performance entry of the left-hand tree menu.

kvm_stat can be used to trace KVM performance events. It monitors /sys/kernel/debug/kvm, so it needs the debugfs to be mounted. On openSUSE it should be mounted by default. In case it is not mounted, use the following command:

mount -t debugfs none /sys/kernel/debug

kvm_stat can be used in three different modes:

kvm_stat                    # update in 1 second intervals
kvm_stat -1                 # 1 second snapshot
kvm_stat -l > kvmstats.log  # update in 1 second intervals in log format
                            # can be imported to a spreadsheet

kvm statistics

 efer_reload                  0       0
 exits                 11378946  218130
 fpu_reload               62144     152
 halt_exits              414866     100
 halt_wakeup             260358      50
 host_state_reload       539650     249
 hypercalls                   0       0
 insn_emulation         6227331  173067
 insn_emulation_fail          0       0
 invlpg                  227281      47
 io_exits                113148      18
 irq_exits               168474     127
 irq_injections          482804     123
 irq_window               51270      18
 largepages                   0       0
 mmio_exits                6925       0
 mmu_cache_miss           71820      19
 mmu_flooded              35420       9
 mmu_pde_zapped           64763      20
 mmu_pte_updated              0       0
 mmu_pte_write           213782      29
 mmu_recycled                 0       0
 mmu_shadow_zapped       128690      17
 mmu_unsync                  46      -1
 nmi_injections               0       0
 nmi_window                   0       0
 pf_fixed               1553821     857
 pf_guest               1018832     562
 remote_tlb_flush        174007      37
 request_irq                  0       0
 signal_exits                 0       0
 tlb_flush               394182     148

See http://clalance.blogspot.com/2009/01/kvm-performance-tools.html for further information on how to interpret these values.

qemu-img uses subcommands (like zypper does) to do specific tasks. Each subcommand understands a different set of options. Some of these options are general and used by more of these subcommands, while some of them are unique to the related subcommand. See the qemu-img manual page (man 1 qemu-img) for a complete list of all supported options. qemu-img uses the following general syntax:

qemu-img subcommand [options]

and supports the following subcommands:

This section describes how to create disk images, check their condition, convert a disk image from one format to another, and get detailed information about a particular disk image.

qemu-img create -f fmt -o options fname size

tux@venus:~> qemu-img create -f raw -o size=4G /images/sles11sp1.raw
Formatting '/images/sles11sp1.raw', fmt=raw size=4294967296

tux@venus:~> ls -l /images/sles11sp1.raw
-rw-r--r-- 1 tux users 4294967296 Nov 15 15:56 /images/sles11sp1.raw

tux@venus:~> qemu-img info /images/sles11sp1.raw
image: /images/sles11sp1.raw
file format: raw
virtual size: 4.0G (4294967296 bytes)
disk size: 0

qemu-img convert -c -f fmt -O out_fmt -o options fname out_fname

tux@venus:~> qemu-img convert -O vmdk /images/sles11sp1.raw \
/images/sles11sp1.vmdk

tux@venus:~> ls -l /images/
-rw-r--r-- 1 tux users 4294967296 16. lis 10.50 sles11sp1.raw
-rw-r--r-- 1 tux users 2574450688 16. lis 14.18 sles11sp1.vmdk

tux@venus:~> qemu-img convert -O vmdk /images/sles11sp1.raw \
/images/sles11sp1.vmdk -o ?
Supported options:
size             Virtual disk size
backing_file     File name of a base image
compat6          VMDK version 6 image
subformat        VMDK flat extent format, can be one of {monolithicSparse \
    (default) | monolithicFlat | twoGbMaxExtentSparse | twoGbMaxExtentFlat}
scsi             SCSI image

qemu-img check -f fmt fname

tux@venus:~> qemu-img check -f qcow2 /images/sles11sp1.qcow2
ERROR: invalid cluster offset=0x2af0000
[...]
ERROR: invalid cluster offset=0x34ab0000
378 errors were found on the image.

11.2.2.4. Increasing the Size of an Existing Disk Image¶

When creating a new image, you must specify its maximum size before the image is created (see Section 11.2.2.1, “qemu-img create”). After you install and run VM Guest for some time, the initial size of the image may no longer be sufficient and you need to add more space to it.

To increase the size of an existing disk image by 2 Gigabytes, use

qemu-img resize /images/sles11sp1.raw +2GB

You can resize the raw disk images only. To resize other image formats, convert it to raw with qemu-img convert first.

The image now contains an empty space of 2 GB after the final partition. You can resize the existing partitions or add new ones.

Figure 11.1. New 2GB Partition in Guest YaST Partitioner

Virtual machine snapshots are snapshots of the complete environment in which a VM Guest is running. The snapshot includes the state of the processor (CPU), memory (RAM), devices, and all writable disks.

Snapshots are helpful when you need to save your virtual machine in a particular state. For example, after you configured network services on a virtualized server and want to quickly start the virtual machine in the same state you last saved it. Or you can create a snapshot after the virtual machine has been powered off to create a backup state before you try something experimental and possibly make VM Guest unstable. This section introduces the latter case, while the former is described in Chapter 13, Administrating Virtual Machines with QEMU Monitor.

To use snapshots, your VM Guest must contain at least one writable hard disk image in qcow2 format. This device is usually the first virtual hard disk.

Virtual machine snapshots are created with the savevm command in the interactive QEMU monitor. You can assign a 'tag' to each snapshot which makes its identification easier. For more information on QEMU monitor, see Chapter 13, Administrating Virtual Machines with QEMU Monitor.

Once your qcow2 disk image contains saved snapshots, you can inspect them with the qemu-img snapshot command.

Do not create or delete virtual machine snapshots with the qemu-img snapshot command while the virtual machine is running. Otherwise, you can damage the disk image with the state of the virtual machine saved.

tux@venus:~> qemu-img snapshot -l /images/sles11sp1.qcow2 
Snapshot list:
ID       TAG               VM SIZE        DATE          VM CLOCK
1         booting                4.4M 2010-11-22 10:51:10   00:00:20.476
2         booted                 184M 2010-11-22 10:53:03   00:02:05.394
3         logged_in              273M 2010-11-22 11:00:25   00:04:34.843
4         ff_and_term_running    372M 2010-11-22 11:12:27   00:08:44.965

11.2.3.2. Creating Snapshots of a Powered-Off Virtual Machine¶

Use qemu-img snapshot -c snapshot_title disk_image to create a snapshot of the current state of a virtual machine which was previously powered off.

tux@venus:~> qemu-img snapshot -c backup_snapshot /images/sles11sp1.qcow2

tux@venus:~> qemu-img snapshot -l /images/sles11sp1.qcow2 
Snapshot list:
ID        TAG                 VM SIZE                DATE       VM CLOCK
1         booting                4.4M 2010-11-22 10:51:10   00:00:20.476
2         booted                 184M 2010-11-22 10:53:03   00:02:05.394
3         logged_in              273M 2010-11-22 11:00:25   00:04:34.843
4         ff_and_term_running    372M 2010-11-22 11:12:27   00:08:44.965
5         backup_snapshot           0 2010-11-22 14:14:00   00:00:00.000

Once something breaks in your VM Guest and you need to restore the state of the saved snapshot (id 5 in our example), power off your VM Guest and do the following:

tux@venus:~> qemu-img snapshot -a 5 /images/sles11sp1.qcow2

Next time you run the virtual machine with qemu-kvm, it will be in the state of snapshot number 5.

The qemu-img snapshot -c command is not related to the savevm command of QEMU monitor (see Chapter 13, Administrating Virtual Machines with QEMU Monitor. For example, you cannot apply a snapshot with qemu-img snapshot -a on a snapshot created with savevm in QEMU's monitor.

tux@venus:~> qemu-img snapshot -d 2 /images/sles11sp1.qcow2

Imagine the following real-life situation: you are a server administrator who runs and manages a number of virtualized operating systems. One group of these systems are based on one specific distribution, while another group (or groups) is based on different versions of the distribution or even on a different (and maybe non-Unix) platform. And to make the case even more complex, individual virtual guest systems based on the same distribution usually differ according to the department and deployment: a file server typically uses different setup and services than a Web server does, while both may still be based on SUSE® Linux Enterprise Server 11 SP1.

With QEMU it is possible to create “base” disk images. You can use them as template virtual machines. These base images will save you plenty of time because you will never need to install the same operating system more than once.

11.2.4.2. Creating Derived Images¶

While you can use the raw format for base images, you cannot use it for derived images because the raw format does not support the backing_file option. Use for example the qcow2 format for the derived images.

For example, /images/sles11sp1_base.raw is the base image holding a freshly installed system.

tux@venus:~> qemu-img info /images/sles11sp1_base.raw 
image: /images/sles11sp1_base.raw
file format: raw
virtual size: 4.0G (4294967296 bytes)
disk size: 2.4G

The image's reserved size is 4 GB, the actual size is 2.4 GB, and its format is raw. Create an image derived from the /images/sles11sp1_base.raw base image with:

tux@venus:~> qemu-img create -f qcow2 /images/sles11sp1_derived.qcow2 \
-o backing_file=/images/sles11sp1_base.raw 
Formatting '/images/sles11sp1_derived.qcow2', fmt=qcow2 size=4294967296 \
backing_file='/images/sles11sp1_base.raw' encryption=off cluster_size=0

Look at the derived image details:

tux@venus:~> qemu-img info /images/sles11sp1_derived.qcow2 
image: /images/sles11sp1_derived.qcow2
file format: qcow2
virtual size: 4.0G (4294967296 bytes)
disk size: 140K
cluster_size: 65536
backing file: /images/sles11sp1_base.raw \
(actual path: /images/sles11sp1_base.raw)

Although the reserved size of the derived image is the same as the size of the base image (4 GB), the actual size is 140 KB only. The reason is that only changes made to the system inside the derived image are saved. Run the derived virtual machine, register it, if needed, and apply the latest patches. Do any other changes in the system such as removing unneeded or installing new software packages. Then shut the VM Guest down and examine its details once more:

tux@venus:~> qemu-img info /images/sles11sp1_derived.qcow2
image: /images/sles11sp1_derived.qcow2
file format: qcow2
virtual size: 4.0G (4294967296 bytes)
disk size: 1.1G
cluster_size: 65536
backing file: /images/sles11sp1_base.raw \
(actual path: /images/sles11sp1_base.raw)

The disk size value has grown to 1.1 GB, which is the disk space occupied by the changes on the filesystem compared to the base image.

tux@venus:~> qemu-img convert /images/sles11sp1_derived.qcow2 \
-O raw /images/sles11sp1_base2.raw

tux@venus:~> qemu-img info /images/sles11sp1_base2.raw
image: /images/sles11sp1_base2.raw
file format: raw
virtual size: 4.0G (4294967296 bytes)
disk size: 2.8G

11.2.4.4. Mounting an Image on a VM Host Server¶

Sometimes it is useful to mount a virtual disk image under the host system. For example, if VM Host Server does not have a network support, this can be the only way to transfer files in and out of a VM Guest.

Linux systems can mount an internal partition of a raw disk image using a 'loopback' device. The first example procedure is more complex but more illustrative, while the second one is straightforward:

Procedure 11.1. Mounting Disk Image by Calculating Partition Offset

1. Set a loop device on the disk image whose partition you want to mount.

   tux@venus:~> losetup /dev/loop0 /images/sles11sp1_base.raw

2. Find the sector size and the starting sector number of the partition you want to mount.

   tux@venus:~> fdisk -lu /dev/loop0
   
   Disk /dev/loop0: 4294 MB, 4294967296 bytes
   255 heads, 63 sectors/track, 522 cylinders, total 8388608 sectors
   Units = sectors of 1 * 512 = 512 bytes
   Disk identifier: 0x000ceca8
   
          Device Boot      Start         End      Blocks   Id  System
   /dev/loop0p1              63     1542239      771088+  82  Linux swap
   /dev/loop0p2   *     1542240    8385929     3421845   83  Linux

   	The disk sector size.
   	The starting sector of the partition.

3. Calculate the partition start offset:

   sector_size * sector_start = 512 * 1542240 = 789626880

4. Delete the loop and mount the partition inside the disk image with the calculated offset on a prepared directory.

   tux@venus:~> losetup -d /dev/loop0
   tux@venus:~> mount -o loop,offset=789626880 \
   /images/sles11sp1_base.raw /mnt/sles11sp1/
   tux@venus:~> ls -l /mnt/sles11sp1/
   total 112
   drwxr-xr-x   2 root root  4096 Nov 16 10:02 bin
   drwxr-xr-x   3 root root  4096 Nov 16 10:27 boot
   drwxr-xr-x   5 root root  4096 Nov 16 09:11 dev
   [...]
   drwxrwxrwt  14 root root  4096 Nov 24 09:50 tmp
   drwxr-xr-x  12 root root  4096 Nov 16 09:16 usr
   drwxr-xr-x  15 root root  4096 Nov 16 09:22 var
   

5. Copy one or more files onto the mounted partition and unmount it when finished.

   tux@venus:~> cp /etc/X11/xorg.conf /mnt/sles11sp1/root/tmp
   tux@venus:~> ls -l /mnt/sles11sp1/root/tmp
   tux@venus:~> umount /mnt/sles11sp1/

Procedure 11.2. Mounting Disk Image while Utilizing kpartx

1. Set a loop device on the disk image whose partition you want to mount.

   tux@venus:~> losetup /dev/loop0 /images/sles11sp1_base.raw

2. Create a device map from the disk image's partitions.

   tux@venus:~> kpartx -a /dev/loop0

3. Mount any partition of the disk image on a prepared mount point.

   tux@venus:~> mount /dev/mapper/loop0p1 /mnt/p1

   You can replace loop0p1 with the number of the partition you want to mount, for example loop0p3 to mount the third partition on the disk image.

4. Copy or move files or directories to and from the mounted partition as you like. Once you finish, unmount the partition and delete the loop.

   tux@venus:~> umount /mnt/p1

   tux@venus:~> losetup -d /dev/loop0

Never mount a partition of an image of a running virtual machine in a read-write mode. This could corrupt the partition and break the whole VM Guest.

Following is an example of a working qemu-kvm command line:

qemu-kvm -name "SLES 11 SP1" -M pc-0.12 -m 512 -cpu kvm64 \
-smp 2 /images/sles11sp1.raw

Figure 12.1. QEMU Window with SLES 11 SP1 as VM Guest

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

To simplify defining of block devices, QEMU understands several shortcuts which you may find handy when entering the qemu-kvm command line. You can use qemu-kvm -cdrom /images/cdrom.iso instead of qemu-kvm -drive file=/images/cdrom.iso,index=2,media=cdrom and qemu-kvm -hda /images/imagei1.raw -hdb /images/image2.raw -hdc \ /images/image3.raw -hdd /images/image4.raw instead of qemu-kvm -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

Using Host Drives Instead of Images

Normally you will use disk images (see Section 11.2, “Managing Disk Images with qemu-img”) as disk drives of the virtual machine. However, 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 filenames. To access the host CD-ROM drive, use qemu-kvm [...] -drive file=/dev/cdrom,media=cdrom To access the host hard disk, use qemu-kvm [...] -drive file=/dev/hdb,media=disk When accessing the host hard drive from VM Guest, always make sure the access is read-only. You can do so by modifying the host device permissions.

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

There are basically 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.

12.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-kvm [...] -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
[...]

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.

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

Assignment of graphics cards is not supported by SUSE.

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 13, Administrating Virtual Machines with QEMU Monitor for more information) and issue the following commands:

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

qemu-kvm [...] -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 backend's suboptions, see the manual page (man 1 qemu-kvm). A brief description of the available backends 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 just mentioned purposes. The following options will help you:

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

qemu-kvm [...] -net nic,vlan=1,macaddr=00:16:35:AF:94:4B,\
model=virtio,name=ncard1

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

qemu-kvm -hda /images/sles11sp1_base.raw

qemu-kvm -hda /images/sles11sp1_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 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 to do 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-kvm [...] -net user,vlan=1,name=user_net1,restrict=yes

qemu-kvm [...] -net user,net=10.2.0.0/8,host=10.2.0.6,dhcpstart=10.2.0.20,\
hostname=tux_kvm_guest

qemu-kvm [...] -net user,tftp=/images/tftp_dir,bootfile=/images/boot/pxelinux.0

qemu-kvm [...] -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:

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.

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=br0
tap=$(sudo tunctl -u $(whoami) -b)
sudo ip link set $tap up
sleep 1s
sudo brctl addif $bridge $tap
qemu-kvm -m 512 -hda /images/sles11sp1_base.raw \
-net nic,vlan=0,model=virtio,macaddr=00:16:35:AF:94:4B \
-net tap,vlan=0,ifname=$tap,script=no,downscript=no
sudo brctl delif $bridge $tap
sudo ip link set $tap down
sudo tunctl -d $tap

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-kvm [...] -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.

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 which 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 A.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 6.2.2, “Remote TLS/SSL Connection with x509 Certificate (qemu+tls)” and Section 6.2.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-kvm [...] -vnc :5,password -monitor stdio

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

Figure 12.4. Authentication Dialog in Vinagre

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

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

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

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

qemu-kvm [...] -fsdev local,id=exp1,path=/tmp/,security_model=mapped
-device virtio-9p-pci,fsdev=exp1,mount_tag=v_tmp

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