UVMM does not yet support the creation of storage pools via the UMC. The creation of storage pools is described below.

To make an additional storage pool available on a virtualization server, it is necessary to create an XML file with a description. The creation of storage pools is documented in the virtualization chapter of the UCS manual. Below, a storage pool is defined which accesses an iSCSI storage device.

In the following example, a storage pool is defined, which mounts the iqn.2010-08.local.ucs:sdb iSCSI target from the xen6.ucs.local server:

<pool type='iscsi'>
	<name>iscsi</name>
	<source>
		<host name='xen6.ucs.local' port='3260'/>
		<device path='iqn.2010-08.local.ucs:sdb'/>
	</source>
	<target>
		<path>/dev/disk/by-path</path>
	</target>
</pool>

This description must firstly be saved in a file (for example, in the iscsi-pool.xml file). For it to be possible to use this storage pool, the following commands must be run:

virsh pool-define iscsi-pool.xml
virsh pool-start iscsi
virsh pool-autostart iscsi

The UVMM service will detect the new storage pool automatically after a certain period of time. Alternatively, the service can also be restarted once so that this new storage pool information is detected immediately:

/etc/init.d/univention-virtual-machine-manager-daemon restart

Hard disks in UVMM can then be used from the storage pool. When doing so, ensure that no new images are saved in an iSCSI storage pool and only existing ones are selected. The individual LUNs are offered as possible images.

If new iSCSI LUNs are set up, the iSCSI storage pool must still be re-imported manually at present. This can be done using the following command:

virsh pool-refresh "$pool_name"

For the example above:

virsh pool-refresh iscsi

When switching from Xen to KVM the drivers for para-virtual block and network devices must be changed. This switch is easier for Linux based virtual machines, as the Linux kernel already contains drivers for both hypervisors and automatically uses the right one. For Microsoft Windows bases systems the GPLPV drivers must be un-installed completely, before the replacement drivers VirtIO for KVM can be installed.

Univention recommends to setup a new virtualization server using KVM and to copy over the exiting image files to the new server. This has the advantage that the new setup can be tested thoroughly and a fallback to the old hypervisor using Xen is possible.

After this the virtual machine can be migrated to KVM. There are two alternatives:

Now the virtual machines must be re-defined. Depending on the number of virtual machines there are two alternatives:

The major differences between the UCS version and Debian version are:

The following commands can be used as a start to migrate to the Debian version of Xen.

# Remove xen-4.1 before update
apt-get remove xen-4.1 libxenstore3.0 libxen4.1 libxen-dev xen-4.1-dbg
# Upgrade to UCS-4
univention-upgrade
# Re-install xen
ucr set repository/online/unmaintained=yes
univention-install xen

After this more manual configuration might be needed, which is beyond the scope of this documentation.

(Live-)migration also transfers the domain configuration. This breaks when the network interface names differ between the source and destination host. Because of that it is strongly advised to shut down any virtual machine cleanly and to transfer them as described above.

There is a second option available which allows updating virtual machines while they are migrated from a UCS-3 to a UCS-4 host. libvirt provides a hook mechanism, which can be used to rewrite the virtual machine configuration on-the-fly for incoming migrations. This is fully described in the libvirt hook documentation.

The following example can be used to convert the network interface name eth0 to br0. The following script must be copied to /etc/libvirt/hooks/qemu and be marked as executable using chmod +x:

#!/bin/sh
object="${1}"
operation="${2}"
sub_operation="${3}"
extra_argument="${4}"

SRC_BRIDGE="eth0"
DST_BRIDGE="br0"

convert_network () {
	xsltproc \
		--stringparam src_bridge "${SRC_BRIDGE}" \
		--stringparam dst_bridge "${DST_BRIDGE}" \
		"${0}.xsl" -
}

case "${operation}/${sub_operation}" in
prepare/begin) ;;
start/begin) ;;
started/begin) ;;
stopped/end) ;;
release/end) ;;
migrate/begin) convert_network ;;
restore/begin) convert_network ;;
reconnect/begin) ;;
attach/begin) ;;
*) echo "${0} ${*}" >&2 ;;
esac

The script uses the xsltproc XSLT command line processor, which is provided by the package xsltproc. The corresponding style sheet file must be copies to /etc/libvirt/hooks/qemu.xsl, which looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
	<xsl:output method="xml" encoding="UTF-8" indent="yes" omit-xml-declaration="yes"/>
	<xsl:param name="src_bridge" select="'eth0'"/>
	<xsl:param name="dst_bridge" select="'br0'"/>

	<xsl:template match="node()" priority="-1" name="copy">
		<xsl:copy>
			<xsl:copy-of select="@*"/>
			<xsl:apply-templates select="node()|text()|comment()|processing-instruction()"/>
		</xsl:copy>
	</xsl:template>

	<!-- Convert network interface name -->
	<xsl:template match="/domain/devices/interface[@type='bridge']/source">
		<xsl:choose>
			<xsl:when test="@bridge=$src_bridge">
				<source bridge="{$dst_bridge}"/>
			</xsl:when>
			<xsl:otherwise>
				<xsl:call-template name="copy"/>
			</xsl:otherwise>
		</xsl:choose>
	</xsl:template>
</xsl:stylesheet>
<!-- vim:set ts=2 sw=2 noet foldmethod=marker: -->

In addition to that the UVMM profiles should be updated as well, as they name the network interface which is used to connect newly created virtual machines. This is described in the [ucs-manual] in UVMM chapter in the section Changing default network.