Contents
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.
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 module or by entering the following command:
insserv libvirtd
To start the Virtual Machine Manager itself, enter
virt-manager
at the command prompt.
![]() | User permissions |
---|---|
Using the Virtual Machine Manager requires |
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 from the context menu. You can also
an existing connection from this menu.
To add a new connection in the Virtual Machine Manager, proceed as follows:
Choose
+Choose the remote host's
( or )Choose a Section 5.1.2.1, “Setting Up Remote Connections” for more information)
type—either for a connection to the hist the Virtual Machine Manager was started on, or one of the remote connections (seeIn case of a remote connection, enter the
of the remote machineIf you do not want the connection to be automatically activated when starting the Virtual Machine Manager, remove the tick from
.Finish the configuration by clicking on
.![]() | libvirtd |
---|---|
The |
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 |
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).
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