Basic XEN configuration

Once we have the Xen hypervisor and a Xen enabled kernel loaded we can begin to configure our installation to provide the services our virtualised guest domains will require. The first stage in this process is to configure the xend control daemon so that we can utilise the other Xen tools to create and manage our guest domains.

The ebuild for the xen-tools package installs an example configuration file for the xend daemon located at /etc/xen/xend-config.sxp which can be examined and modified if required. To ensure that we have covered all of the configuration options required to attain a secure and fully functional Xen installation we shall move this example configuration file and create our own from scratch, as shown below.

Logging

The first entries we shall add to our configuration file control the log output of the Xen control daemon. The first sets the log path for the log file while the second sets the level of logging output we require. As we shall be experimenting with different Xen configurations we shall set the log level to DEBUG to ensure the most information is displayed.

During configuration it is often helpful to have more output than usual so we have configured the log to contain DEBUG level log output. In production use log output of WARNING or ERROR levels would be more appropriate to avoid excessively large log files.

 

(logfile /var/log/xen/xend.log)
(loglevel DEBUG)

Communication Protocols

The xend daemon offers a variety of communication protocols over which the management utilities can connect and thereby control the virtual machines and perform other management functions.

xend-http-server

The first control protocol to be implemented was the xend-http-server which offered a, now very old and totally broken, HTML interface and a, generally still working, SXP-based interface, both on port 8000. As both of these control methods are deprecated it should be disabled unless required by legacy management software.

xend-unix-server

The control protocol described above is also available using a unix socket for local use.

xend-tcp-xmlrpc-server

The second control protocol to be implemented used XML-RPC as the communications protocol over TCP on port 8006. For all versions of Xen before 3.0.5 this is the recommended management server protocol.

xend-unix-xmlrpc-server

As before the control protocol described above is also available using a unix socket for local use.

xen-api-server

The most recent control protocol is known as the xen-api-server and offers a totally new interface. For versions of Xen after 3.0.5 this is the recommended management server protocol. As before it is available over both unix and TCP sockets, although the configuration mechanism is different as you can see in the example below.

As we shall be using a version of Xen much more recent than 3.0.5 we shall enable the latest xen-api-server protocol and disable all others, as shown below.

(xend-http-server no)
(xend-unix-server no)
(xend-tcp-xmlrpc-server no)
(xend-unix-xmlrpc-server no)
(xen-api-server ((unix)))

Relocation Services

One of the more compelling features of the Xen virtualisation environment is the ability to suspend a guest, migrate it to a different physical host and then resume it totally transparently to the guest operating system and applications. As we shall not be discussing relocation until a later section, and the xend-relocation-server is insecure with the default configuration, we shall disable it until we need it, as shown in the following example.

(xend-relocation-server no)
(xend-relocation-ssl-server no)

Networking

Current versions of Xen offer two distinct methods of connecting guest domains to the network of the host domain. For the sake of simplicity we shall be using the route method for the examples in the following sections. The alternative, bridge networking, will be discussed in a later section.

(network-script network-route)
(vif-script     vif-route)

If you have multiple network adaptors installed in the host machine, or you have renamed a network interface, and wish to specify that this interface is to be used by the route or bridge scripts you will need to specify the name of the network device using the netdev option as shown below.

(network-script 'network-route netdev=lan')
(vif-script     'vif-route netdev=lan')

Processor and Memory

The next group of configuration options we shall introduce allows control over the memory and CPU utilisation of the host domain. We have configured a minimum of 196MB to be reserved for the host domain using the dom0-min-mem setting and allowed the host domain to use any spare memory not allocated to a guest domain with the enable-dom0-ballooning option. The final line specifies that the host domain is only to run on a single CPU at a time, although on a multiprocessor system this could still be any of the available CPUs as we have not specified a cpu-pin directive. The special value of 0 (zero) may be used for the dom0-cpus setting to allow the host domain to run with the same number of virtual CPUs as the host has physical CPUs.

(dom0-min-mem 196)
(enable-dom0-ballooning yes)
(dom0-cpus 1)

Miscellaneous

Finally we can configure the default keymap setting for our guest domains. This setting can, of course, be overridden later should we wish to use a different keymap setting for some of our guests.

(keymap 'en-gb')

Starting and testing the Xen control daemon

Once the xend daemon has been configured it can be started using the provided init script, as shown here.

Assuming that the script executed without errors we can verify that the xend daemon is operating correctly by using the xm application to display a list of the running domains. As you can see from the example below there should only be a single domain running, the host domain. Other interesting information includes the amount of memory allocated to each domain, the number of virtual CPUs (VCPUs) and the current machine state, in this case r for running. The final column indicates the total CPU time that each domain has consumed since the xend daemon started.

Name                                        ID    Mem VCPUs      State   Time(s) 

Domain-0                                     0  17933     1     r-----    118.3 

When you are confident that the xend daemon is operating correctly the appropriate init script can be added to the default run level so that the daemon will be automatically started after a reboot using the command below.