Xen is one of those cool open source projects which seems like the kind of thing you’d probably want to run if it weren’t for the fact that everyone forces you to run ESX(i). It’s free, it’s well documented, and no matter how irrational salespeople can be, nobody can say there’s no support or documentation for it. So how does Xen work, and how does it compare with ESXi?
For starters, there’s no need to be overly concerned with what hardware is supported. Instead of being dependent on a specific OS, Xen is a driverless hypervisor which runs in conjunction with a host OS. This host OS might be GNU/Linux, NetBSD, Solaris or others. Since the host OS handles talking with hardware, any hardware which is supported by the host OS can be used with Xen. In a nutshell, Xen can be run on any x86 box, although full virtualization requires Intel’s VT-x or AMD’s AMD-V hardware support.
So let’s say you want to set up Xen. How? In many instances it’s as simple as installing a GNU/Linux distribution or a NetBSD distribution. Straightforward directions can be found here:
Let’s say you’ve already done all of that and you’re sitting at the command prompt of your Xen dom0. How do we create virtual machines? We’ll make an example using Windows 2012 Server since that just happens to be what I’m installing today.
Just like the how-to for installing a Xen dom0 instance, there are lots of how-tos for installing Windows and other OSes under Xen. We’ll summarize the important points using a minimal VM configuration file:
name = "win2012"
memory = "8192"
disk = [ 'file:/usr/xen/win2012/win2012.img,ioemu:hda,w', 'file:/usr/xen/win2012/winserver2012.iso,ioemu:hdb:cdrom,r' ]
vif = [ 'bridge=bridge0', ]
vcpus = 1
sdl = 0
vncconsole = 1
vfb = [ 'type=vnc,vncdisplay=12,vncpasswd=booboo' ]
on_reboot = 'destroy'
on_crash = 'destroy'
# boot on floppy (a), hard disk (c) or CD-ROM (d)
# default: hard disk, cd-rom, floppy
usbdevice = 'tablet' # Helps with mouse pointer positioning
Some of the options are pretty self-explanatory such as name, memory, vcpus, on_reboot and on_crash. Others may need a little explanation. Builder identifies the kind of virtualization. For paravirtualization, no builder need be specified, but you must be running a Xen-aware domu. For full virtualization, use hvm. device_model determines the executable run to emulate devices which the virtual machine will use. The default Xen qemu device model appears to work well nowadays with all versions of Windows. The disk line should make sense, but be aware that you’ll need to make the disk image yourself. If you wish to preallocate the entire file, use something like:
dd if=/dev/zero of=/usr/xen/win2012/win2012.img bs=1048576 count=32768
Which would write 32 gigs of zero to the disk image file. If you don’t care about preallocating the space, you can run:
dd if=/dev/zero of=/usr/xen/win2012/win2012.img seek=32767 bs=1048576 count=1
vif is the virtual network interface. A bridge to a real NIC is simplest, although other options are available if desired.
sdl is some other way of presenting the graphics screen, but I don’t know how that works. vnc, on the other hand, can be run on localhost and sent over X11 very easily. My options above create a vnc listener on display 12 (localhost:5912) with a simple password. One can forward X11, with compression if preferred, and run vncviewer on the Xen dom0. If X11 scares you, you can also use ssh to forward port 5912 from localhost of the dom0 to a port on your local machine and run VNC or Screen Sharing on your local machine.
There are great reasons to do something like this, like the ability to talk directly to the ssh daemon on the dom0 instance… But whatever… Blah blah blah. We’re now running Windows in Xen…