- Determining that a machine is using xen, VirtualPC or VMWare
- Determining that a machine is using other
- Locating a domain
- Virtual Server 2008 Hyper-V
- Sun vXM VirtualBox
- kvm - Kernel based Virtual machine
- UML - User-Mode Linux
- wubi - Windows UBuntu Installer
- cross apps
- login to other system
- Machine Management
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.
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. 22.214.171.124 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!
It is supported and tested locally for using ISO images for: Debian, 64b CentOS 5.1, and WXP SP2 (needs physical CD).
It work using the 64b Centos 5.1 template for Fedora Core 6 and 8 using a URL install.
- Fedora 7 hangs early on in install, but there is a "VM" template (an upgraded FC6 machine).
- Fedora 9alpha asks for help to locate the media.
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:
run XenCenter, e.g. from "Start -> all programs -> xencenter" on the "rdesktop" machines.
Click on "New VM and select the OS template. "Other install media" will do a FV install, which fails for Linux. So for Fedora, select CentOS, and use URL install. Next.
Fill in "Name" and "Description". Next.
Type in the Install URL (e.g. the CS), select "ISO Image" and select from from the pulldown menu (/a/misc-nosnap/XenE-SR/), or select "Physical DVD". Next.
Select a host to use, or let it choose automatically. Next.
Up memory from 256 to 1024, leave 1 CPU, Next.
Edit the virtual disk if it isn't suitable (should be 8GB on network storage). Next
Check that "interface 0" is "Network 2", and delete any others. Click on "auto-generated" and type in the "MAC Address" as required. Next
"Finish" to tell it to "Start VM automatically".
Click on the machine in the LH column, then click on Console tab.
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.
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.
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
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
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 126.96.36.199 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).
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.