There are a plethora of packages to provide Virtual systems. Please add details and characteristics below. They vary as to whether they need modifications to the hosts (Para Virtualisation) or can run them unaltered (Full Virtualisation) either by emulation or use of FV HW. See documents such as Fedora 8.

Related are sections on cross apps and login.

Determining that a machine is using xen, VirtualPC or VMWare

A plausible static hint about whether a host uses xen is to see if it has the XEN_client or XEN_server property in hosts.props. Also, "host -t ptr $host" for a service may return the host which provides that service (for shared servers) or a pointer to $host for dedicated servers which provide a single service.

The command "cl-onserver --xen-clients" looks in the database to see what should run where, and probes dom0s to see what is actually running (or in the case of XenE, all domUs).

See /anfs/www/html/sys-admin/ix86-servers so a cached snapshot of what services ran where at some point.

If the machine is responding to ARPs, look at the MAC addresss. xensource has left MAC addresses of the form 00:16:3E:xy:yy:yy (x=8-F, y=0-F, i.e. 23 bits) available for site use. For fixed IP hosts we use the prefix 00:16:3E:E8: followed by the bottom two bytes of the IP address, e.g. uses 00:16:3E:E8:09:88. (E8 was chosen as the XOR of the top two bytes of the IP address masked to 15 bits). For machines using dynamic DHCP, we use 00:16:3E:80:00:xx where xx is the hex representation of the machineID. VirtualPC uses a "00:03:FF" prefix. VMWare uses "00:0C:29" for dynamic and "00:50:56" (with a mask of 3FFFFF, making 00:50:56:28:xx:xx) for static (as well as 001C14 and 000569).

If you can login, look for /proc/xen/ which is present only on machines running a xen kernel. On dom0 machines, /proc/xen/capabilities will include "control_d". Also ParaVirtualised (PV) domU machines can normally be detected by /proc/partitions having disc subpartitions, but not the discs (e.g. "sda1" but no "sda")

Determining that a machine is using other

to be written

Locating a domain

Two of the main features of xen are that domains can move between xen servers, and that domains don't care or know where they are hosted. This makes locating a domain harder. Having ssh'ed in to a domU, there is no way to determine the dom0 which is hosting it. However, in steady state (e.g. after a reboot) with xendomains enabled, the config files in /etc/xen/auto/ should define the domUs which run.

If the machine is responding to ARP requests, it is possible to find the MAC address, and inspect the Cisco switch tables to locate the port to which it is connected.

If the machine is "running", issuing the command "virsh list" or "xm list" on all dom0's should locate it. On FC3 machines, the command "/usr/opt/etc/xen-clients" (use "--help" for details) can be used to ask machines listed in hosts.props as having the XEN_server property. As this may need root privs, it can be run on a trusted server using "cl-onserver --xen-clients" on any machine. For SRG domains (such as fletcher and stanier) use /usr/groups/xeno/service-box/tools/xenfind

In the database, the MAC address of a xen host is associated with the inventory number of the dom0, with Media set to xen_virtual, and the Comment set to the last two digits of the IP address, followed by the name of the machine (e.g. "1.6 resolv5" and "VLAN190 xen-pb1.al"). These can be found by looking in SCG requesting

 SELECT inventoryid,mac FROM nc_details WHERE media = 'xen_virtual' ORDER BY inventoryid,mac

e.g. using /homes/pb/pl/NC_details.pl to see the current details. To check a dom0's current clients, use

really ssh -n -x $host xm list --long  | grep mac

and look for MAC addresses starting 00:16:3E:E8 (any other 00:16:3E addresses should be fixed).

If the machine isn't running, look in /etc/xen/auto/* on all dom0's, and in /usr/groups/linux/xen/vm-configs.


xen provides paravirualization (available on any machine) or full virtualization (only if the CPU has VT or SVM) allowing multiple Virtual Machines (domains) to run on a single machine. See the xen Users' Manual for more details. The hyperviser (xen) runs in ring 0 (normally used by the kernel), with the domains running in ring 1, and user processes running in ring 3 as usual. xen itself (the hypervisor) is minimal, with most of the management being performed by the privileged kernel in the first domain ("dom0"), which xen starts at boot time. The dom0 can then create unprivilidged user domains (domU). The domains appear very similar to normal Linux systems, except that domUs have virtualised devices. One particularly useful feature is that the console of domUs can be accessed from dom0.

dom0 appears very similar to a standard machine. Users may well not even realise that xen is there. PCI and USB devices are seen as normal. The most likely difference is that they kernel version may be different, and thus certain facilities may not be visible.

domU machines on the other hand may appear quite different to any users who poke around. /proc/partitions will show partitions without the corresponding disc (e.g. sda5 but no sda). Things like USB memory sticks, audio and direct graphics will not work. However, if a user logs in remotely and just gets on with doing things, the differences may not be noticed.

For non personal use, consider XenEnterprise.

Below is information for dom0 users, domU users, and there are separate pages for

We normally use the xen RPMs which come with the distribution. There may be test Processor Bank machines available, e.g. as pbtest1 and pbtest2.

Users of dom0

dom0 machines should appear pretty much like a non-xen machine. Lab managed machines may allow xm commands to be run under cl-asuser by the registrred user of a machine (e,g, to "cl-asuser xm list" to list the domains) as root.

Users of domU

domU systems are generally suitable for remote access, but not local. Devices such as the graphics card, keyboard, mouse, USB ports and audio are not available. However, if connected to remotely, they should appear fairly normal. Describe SysInfo/VirtualMachines here.


This is the enterprise version of xen. As of 2008/05 we are using 4.1 on a pool of three machines (godmanchester, biggleswade and donham) although it will soon be upgraded to have more machine added (aria etc).

Filespace can be local, NFS (as .vhd files), iSCSI (as LVM on a single LUN) or NetApp (LUN per VD - not tried as of 2008/02). It supports dynamic changes in memory and VCPUs (from CLI only as of 2008/02). It supports live migration of machines. It supports conversion of physical machines (P2V).

Note that it only supports (P2V and installation of?) a restricted set of domUs, as FV is not "full", in particular it does not support Linux. As such, all Linux systems need to be installed as PVs. The PV installer works by applying "work arounds" for certain known systems. If it doesn't recognise the DVD as one it knows, select a similar looking distribution, try a "URL" install, pointing it at an unpacked image. If that fails, try other distribution templates. Xensoure's target is large corporations, so if a distribution isn't supported, tough!

WXP SP2 from ISO image fails after the first boot complainig about missing "D:\I386\asms" (See microsoft, xensource and msfn).

If there is no reason to select a particular distribution, consider CentOS, as it is fully supported.

Basic install using XenCenter

To do an install:


Long established FV emulating commercial offering.

Version 6 is the first to have a 64b RPM. This appears not to work under Fedora 8 (with or without the patches), but seems to configure OK under CentOS 5.

ESX is used on gremlin as of 2008/06


Windows "free" offering aimed at end users. See also Virtual Server.

Virtual Server 2008 Hyper-V

We run the "Enterprise" version of VirtualPC on a pair of Dual Quad core machine (tinsley and silvertown) with 32GB of RAM and 4 NICs. As of 2009/04, the clients virtual discs reside on iSCSI LUNs, which allows migration and copes with server hardware failure. Local discs (in caddies for each of changing) are needed as booting from iSCSI isn't supported.

Management is using https: to port 1025, requiring Active X (to which machine??), or using the System Center Virtual Machine Manager Admin Console on a suitable machine (e.g. feltham, which is itself a VM).

The MAC prefix is 0003FF. See Windows/VirtualServer for further details.

Sun vXM VirtualBox

FV using HW or SW. See their home page

Installation on CentOS 5 requires a kernel recompilation.

The MAC prefix is 08:00:27.

kvm - Kernel based Virtual machine

kvm is a "modprobe and go" FV.


lguest is a proof of how simple a hypervisor can be (5K lines). PV. 32b lguest Linux clients only.

UML - User-Mode Linux

uml is a special case of PV: Linux under Linux.


Containers provide lightweight separation between groups of processes on a machine, each of which can usually have its own IP address, etc. (wikipedia)


OpenVZ implements isolated containers which can be independently rebooted.


LXC (wikipedia) provides linux containers.


Linux-Vserver (wikipedia) provides virtual private servers.

FreeBSD jail

FreeBSD jail (wikipedia).

Solaris containers

Solaris containers and zones are used by the Computing Service to provide their Managed Web Servers.


qemu is the original emulator.

wubi - Windows UBuntu Installer

wubi puts a ubuntu image into a Windows directory and adds it as a boot option. It avoids the need to repartition the disc to run ubuntu.


Cooperative Linux allows linux to run "alongside" Windows.

cross apps

Below are some ways of running applications on a different system

cygwin: linux apps under windows


wine: windows apps under linux


crossover: commercial wine


wubi: ubuntu under windows

The Windows UBuntu Installer install a ubuntu image into a Windows directory and adds it as a boot option. It avoids the need to repartition the disc to run ubuntu.

ulteo: linux desktop under windows

Ulteo Virtual Desktop

login to other system

Below are some ways to login to a different system

rdesktop: linux RDP client

exceed: windows X client

PuTTY: windows ssh client

Machine Management

Below are some notes which apply to virtual machines.

MAC address assignment

xensource has allocates MAC addresses of the form 00:16:3E:xy:yy:yy (x=8-F, y=0-F) for site use, and for fixed IP hosts we put the XOR of the top two bytes of the IPv4 address as the top byte (128.232 becomes E8), followed by the bottom two bytes of the address, so uses 00:16:3E:E8:09:88. For machines using dynamic DHCP, use 00:16:3E:80:00:xx where xx is allocated sequentially (search the database to fine which is the next free one).

VirtualPC uses a "00:03:FF" prefix.

VirtualBox uses a "08:00:27" prefix, but permits any MAC address to be used.

VMWare uses "00:0C:29" for dynamic and "00:50:56" (with a mask of 3FFFFF, making 00:50:56:28:xx:xx) for static (as well as 001C14 and 000569).

DHCP allocation

Virtual machines using DHCP are registered as additional MAC addresses on the machine which hosts them (or the logical "master" in a pool). The name is set in the DHCP table.

If the host machine changes, simply edit the "Inventory" name on the MAC registration to that of the new server.

This information is used by the "cl-onserver --xen-clients" command, showing the expected allocation. If the machines which run this command (e.g. misbourne) can run commands on the server as root, the actual allocation can also be shown.

SysInfo/VirtualMachines (last edited 2013-09-20 05:19:21 by PieteBrooks)