Managing Virtual Machines

Contents

5.1. The Virtual Machine Manager (virt-manager)
5.2. Managing Virtual Machines from the Command Line
5.3. Remote Access Methods

The Virtual Machine Manager (virt-manager)

The Virtual Machine Manager provides a graphical tool for managing and administrating Xen and KVM based virtual machines. You can not only perform basic tasks like starting, stopping, pausing and saving virtual machines, but also migrate or clone virtual machines. It also allows you to create new virtual machines or to modify existing virtual machines. last it provides basic monitoring information for the host system.

The Virtual Machine Manager does not need to run on the KVM or the Xen Dom0 host, it also lets you control virtual machines via secured remote connections. This enables you to manage virtual machines centrally from a single workstation without having to login on the hosts.

Starting the Virtual Machine Manager

In order to use the Virtual Machine Manager the libvirt management daemon must be running. Use the following commands to start, stop or check libvirtd

~ # rclibvirtd start
Starting libvirtd                              done
~ # rclibvirtd status
Checking status of libvirtd                 running
~ # rclibvirtd stop
Shutting down libvirtd                         done
~ # rclibvirtd status
Checking status of libvirtd                  unused

To automatically start libvirtd at boot time, either activate it using the YaST System Services (Runlevel) module or by entering the following command:

insserv libvirtd

To start the Virtual Machine Manager itself, enter

virt-manager

at the command prompt.

[Note]User permissions

Using the Virtual Machine Manager requires root permissions.

Connections

The Virtual Machine Manager uses a Connections for every KVM host it manages. Each connection contains all virtual machines of 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 virtual machines for this connection.

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

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

  1. Choose File+Add Connection

  2. Choose the remote host's Hypervisor (Xen or QEMU/KVM)

  3. Choose a Connection type—either Local for a connection to the hist the Virtual Machine Manager was started on, or one of the remote connections (see Section 5.1.2.1, “Setting Up Remote Connections” for more information)

  4. In case of a remote connection, enter the Hostname of the remote machine

  5. If you do not want the connection to be automatically activated when starting the Virtual Machine Manager, remove the tick from Autoconnect.

  6. Finish the configuration by clicking on Connect.

[Important]libvirtd

The libvirtd needs to run on each server that is to be managed remotely via the Virtual Machine Manager. Please refer to Section 5.1.1, “Starting the Virtual Machine Manager” for instructions.

Setting Up Remote Connections

The following table lists the differences between the four remote connection types available. Two of them— Kerberos and Username/Password authentication—are currently not supported by VNC, yet, so you will not be able to use the graphical console. Therefore these remote connection types are not described here. Please refer to the following web pages for setup instructions:

Username/Password authentication: http://virt-manager.org/page/RemoteDigest
Kerberos Authentication: http://virt-manager.org/page/RemoteKerberos

Table 5.1. Virtual Machine Manager: Remote Connection Types

SSH

SSL/TLS

Username / Password

Kerberos

Centralized Access Control

X

Supported by VNC

X

X

Easy Setup

X

X

Firewall Rules needed

X


Remote Tunnel over SSH

Setting up a remote connection that is tunneled over SSH is easy. The only requirement is the ability of the host machine to allow SSH connections.

To be able to connect, the user starting the Virtual Machine Manager needs to have an SSH key pair (please refer to Section “SSH Authentication Mechanisms” (Chapter 14, SSH: Secure Network Operations, ↑Security Guide) for instructions on generating a key pair). the public part of that key pair needs to be copied to the list of allowed keys for the root of the remote machine:

ssh-copy-id -i ~/.ssh/id_rsa.pub root@remote_host

If the Key pair is password protected, you will be asked to provide that password every time the connection is activated and whenever you access a virtual machine via VNC from the Virtual Machine Manager. Use the ssh-agent to automatically authenticate (please refer to Section “SSH Authentication Mechanisms” (Chapter 14, SSH: Secure Network Operations, ↑Security Guide) for more information).

Remote SSL/TLS with x509 Certificate

Using TCP connections with SSL/TSL encryption and authentication via x509 certificates is much more complicated to setup as using SSH, but it is a lot more scalable. Use this method if you have to manage several virtualization hosts with a varying number of administrators.

Steps to setup TLS/SSL access for virt-manager

xref -> cha.security.yast_ca

* Create a CA with the YaST CA management module
  Export via
  Description tab -> Advanced -> Export to file -> Only the certificate in PEM format
* Create a server certificate for the server
  Export via
  Certificates tab -> select cert -> Export -> Certificate and the Key in Unencrypted PEM Format
  csplit -z -f server server.pem '/\-\-\-\-\-BEGIN/' '{1}'
  server00 -> servercert.pem
  server01 -> serverkey.pem

* Create a client certificate for virt-manager
  Export, see above
  csplit -z -f server client.pem '/\-\-\-\-\-BEGIN/' '{1}'
  client00 -> clientcert.pem
  client01 -> clientkey.pem

Places to copy the files:

Server:
/etc/pki/CA/cacert.pem
/etc/pki/libvirt-vnc/cacert.pem

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

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


Client:
/etc/pki/CA/cacert.pem

/etc/pki/libvirt/private/clientkey.pem
/etc/pki/libvirt/clientcert.pem

~/.pki/CA/ca-cert.pem
~/.pki/libvirt-vnc/clientcert.pem
~/.pki/libvirt-vnc/private/clientkey.pem


The following short guide assuming you are starting from scratch and don't have any TLS/SSL certificate knowledge. If you are lucky enough to have a certificate management server you can probably skip the first steps.

libvirt server setup

The libvirt website has a walkthrough on creating certificates, and placing
      them in the correct places on the server (ie, /etc/pki/libvirt). Consult
      http://libvirt.org/remote.html

Xen VNC Server

The Xen VNC server can have TLS enabled by editing the main configuration file

 /etc/xen/xend-config.sxp

The following config parameter should be uncommented:

 (vnc-tls 1)

It then requires, that the /etc/xen/vnc directory be populated with 3 files:

    * ca-cert.pem - The CA certificate
    * server-cert.pem - The Server certificate signed by the CA
    * server-key.pem - The server private key 

This provides encryption of the data channel. If clients are to continue using passwords for authentication it is practical to stop here. It may be desirable to also require that clients present their own x509 certificate as a form of authentication. To enable this use

 (vnc-x509-verify 1)


KVM VNC Server

The KVM VNC server can be TLS enabled by editing the main libvirt daemon configuration file for the QEMU driver

 /etc/libvirt/qemu.conf

The following config parameter should be uncommented:

 #vnc_tls=1

It then requires, that the /etc/pki/libvirt-vnc directory be populated with 3 files:

    * ca-cert.pem - The CA certificate
    * server-cert.pem - The Server certificate signed by the CA
    * server-key.pem - The server private key 

This provides encryption of the data channel. If clients are to continue using passwords for authentication it is practical to stop here. It may be desirable to also require that clients present their own x509 certificate as a form of authentication. To enable this use

 #vnc_tls_x509_verify=1

Latest libvirt releases run QEMU as a dedicated user account 'qemu:qemu', so make sure that user/group has permission to read the certificate files in /etc/pki/libvirt-vnc

virt-manager/virsh/virt-viewer client setup

The setup for clients is slightly inconsistent at this time. To enable the use of the libvirt management API over TLS, the CA and client certificates need to be placed in /etc/pki. For details on this consult http://libvirt.org/remote.html

In the virt-manager UI, then use the 'SSL/TLS' transport mechansim when connecting to a host.

For virsh/virt-viewer, the qemu://hostname.domainname/system or xen://hostname.domainname/ URIs should be used.


To enable the use of SSL/TLS for VNC, it is neccessary to put the CA and client certificates into $HOME/.pki, providing three files

    * CA/ca-cert.pem - The CA certificate
    * libvirt-vnc/clientcert.pem - The client certificate signed by the CA
    * libvirt-vnc/private/clientkey.pem - The client private key


Managing Virtual Machines from the Command Line

Remote Access Methods