The Book of Xen Part 16

Easy, right? Let's get started.

Installing Windows Manually The first thing to do is get a copy of Windows. In our case, we used a physical CD-ROM, which we put in the Xen server's CD-ROM drive. For convenience, you can of course create an image from the CD and use it just like the physical disc: #ddif=/dev/cdromof=/var/tmp/windows2k3.iso (If you go that route, specify file:/var/tmp/windows2k3.iso file:/var/tmp/windows2k3.iso instead of instead of phy:/dev/cdrom phy:/dev/cdrom in the following steps.) in the following steps.) While you're at it, create the backing store in the usual way. Here we'll use a file-backed device, but you can use any storage backend that Xen knows about.

#ddif=/dev/zeroof=/opt/xen/falstaff/falstaff.imgbs=1Mcount=8192 Next, create a config file. Here's a sample (pulled from Chapter12 Chapter12 with minor changes). We'll save this as with minor changes). We'll save this as /etc/xen/falstaff /etc/xen/falstaff: importos,re arch=os.uname()[4]

ifre.search('64',arch): arch_libdir='lib64'

else: arch_libdir='lib'

device_model='/usr/'+arch_libdir+'/xen/bin/qemu-dm'

kernel='/usr/lib/xen/boot/hvmloader'

builder='hvm'

memory=512 name='falstaff'

vif=['type=ioemu,bridge=xenbr0']

disk=['file:/opt/xen/falstaff/falstaff.img,ioemu:hda,w', 'phy:/dev/cdrom,ioemu:hdc:cdrom,r']

boot='d'

vnc=1 This should be pretty familiar by now. Note that we're leaving ACPI and APIC at their default "off " values to avoid confusing the Windows installer. You'll want to point the entries in the disk= disk= lines to the appropriate locations for your install, of course. You might also want to diverge from our configuration by setting lines to the appropriate locations for your install, of course. You might also want to diverge from our configuration by setting sdl=1 sdl=1 rather than rather than vnc vnc-SDL works only on the local X display but has the virtue of popping up automatically.

Then create the machine as usual: #xmcreatefalstaff Start a VNC session so that you can talk to it, a.s.suming you decided against SDL. Insert the correct host and display number-in this case we're on the local machine, and this is the first VNC session running: #vncviewerlocalhost:1 Now Windows Setup will start in its accustomed fas.h.i.+on. Install Windows as usual.

A Discussion of HALs One problem that occasionally pops up at this stage involves the Windows HAL (hardware abstraction layer). Windows s.h.i.+ps with a selection of possible DLLs to implement the abstraction layer, picking one of six choices during the install process. The correct HAL to use with the system is affected by the acpi, apic acpi, apic, and vcpus vcpus configuration directives, as indicated in configuration directives, as indicated in Table13-1 Table13-1.

Table13-1.HALs Available with Windows

OPTIONS HAL COMMENTS acpi=0,apic=0 HAL.DLL Standard PC Non-ACPI Programmable Interrupt Controller (PIC) Works with everything acpi=0,apic=1 HALAPIC.DLL MPS (Multiprocessor Specification) Uniprocessor PC Non-ACPI APIC uniprocessor HAL Uniprocessor only Doesn't work with PIC machines acpi=0,apic=1 HALMPS.DLL Non-ACPI APIC multiprocessor HAL Does not work with ACPI machines acpi=1,apic=0 HALACPI.DLL Advanced Configuration and Power Interface (ACPI) ACPI PIC (not APIC) HAL Do these even exist in hardware?

acpi=1,apic=1 HALAACPI.DLL ACPI Uniprocessor PC ACPI APIC uniprocessor HAL ACPI only APIC only Uniprocessor only acpi=1,apic=1 HALMACPI.DLL ACPI Multiprocessor PC ACPI APIC multiprocessor HAL

The lucky winner becomes $SYSTEMROOTsystem32HAL.DLL $SYSTEMROOTsystem32HAL.DLL.

The easy answer, therefore, is to use HAL.DLL HAL.DLL, regardless of the values of ACPI and APIC. This should always work, but it might reduce performance. Microsoft also warns that such a configuration is unsupported.[80] We generally turn ACPI and APIC on so that Windows will install the ACPI APIC HAL, and it hasn't caused the machine to burst into flames yet. We generally turn ACPI and APIC on so that Windows will install the ACPI APIC HAL, and it hasn't caused the machine to burst into flames yet.

With Windows XP, however, this sometimes doesn't work. Setting ACPI can cause the install process to fail, usually by hanging at Setup is Starting Windows. The easiest way to install Windows XP is to leave ACPI and APIC off during the initial boot from the CD-ROM and then turn them on before the first boot into graphical mode.

acpi=0 apic=0 on_reboot='destroy'

Then go through the initial format, copy, and so on. When the first phase of Windows Setup completes and the VM turns off, change the config file to read: acpi=1 apic=1 on_reboot='restart'

This will cause Windows to install the correct HAL during its second-phase installation.

If you need to change the HAL later on-for example, if you decide to move from a uniprocessor to a multiprocessor configuration-we recommend reinstalling Windows. It's possible to change the HAL manually by overwriting the various driver files, but it's probably not a great idea.

Installing Windows the Red Hat Way Red Hat's virt-manager virt-manager app can handle most of the trouble of setting up Windows for you. Just create a machine from the app can handle most of the trouble of setting up Windows for you. Just create a machine from the virt-manager virt-manager GUI, select Fully Virtualized rather than Paravirtualized in the appropriate dialog, and indicate the location of Windows install media (either an ISO file or physical CD-ROM). Indicate whether you'd like to connect to the network using a virtual network or shared physical device (corresponding to networking via GUI, select Fully Virtualized rather than Paravirtualized in the appropriate dialog, and indicate the location of Windows install media (either an ISO file or physical CD-ROM). Indicate whether you'd like to connect to the network using a virtual network or shared physical device (corresponding to networking via virbr virbr and and xenbr xenbr, respectively). Install Windows as normal, using Microsoft's install program.

The configuration generated by virt-manager virt-manager will look something like this: will look something like this: name="hal"

uuid="5b001f4d-7891-90d8-2f55-96a56e8d07df"

maxmem=512 memory=512 vcpus=1 builder="hvm"

kernel="/usr/lib/xen/boot/hvmloader"

boot="c"

pae=1 acpi=0 apic=0 on_poweroff="destroy"

on_reboot="restart"

on_crash="restart"

device-model="/usr/lib/xen/bin/qemu-dm"

sdl=0 vnc=1 vncunused=1 keymap="en-us"

disk=["file:/var/lib/xen/images/falstaff.img,hda,w"]

vif=["mac=00:16:3e:7e:f3:15,bridge=virbr0,type=ioemu"]

serial="pty"

Unfortunately, this doesn't get you quite to the end of the Windows install. For whatever reason, the emulated CD-ROM isn't presented to Windows after the first reboot in the install process, so Windows will complain that it can't find its files.

Red Hat's doc.u.mentation will tell you that Windows needs to format its virtual disk as a FAT or FAT32 part.i.tion so that you can copy the install files to it. While this approach will work, we prefer to avoid FAT32 in favor of NTFS. To get around this problem, we use the I/O emulator. Modify the disk= disk= line to use QEMU's I/O emulation as follows: line to use QEMU's I/O emulation as follows: disk=['','file:/mnt/winxp.iso,ioemu:hdc:cdrom,r']

(Put your definition for the first hard drive in the appropriate place, of course.) The second stanza specifies an ISO to use as a virtual CD-ROM drive, with hardware emulation provided by Xen's hardware emulation layer (inherited from QEMU). When you've made this change, the CD will appear to the domU as a QEMU emulated device, and you can proceed with the installation.

[80] So is everything else about running Windows under Xen, as far as we can tell. So is everything else about running Windows under Xen, as far as we can tell.

Windows with the Virtual Framebuffer "What's the best remote administration tool for Windows NT?""A car."-Anonymous, Usenet However you've gone about installing Windows, you'll almost certainly want to log in and use the system when it's running. That's where the virtual framebuffer comes in.

Xen's virtual framebuffer allows you to interact with the domU at all stages-from BIOS load, through the bootloader, to postsystem boot. It can be accessed through SDL on the local console or via VNC over the network. It's one of the neater features of HVM domUs, and it really helps to cement the illusion of a real machine.

Wonderful though the virtual framebuffer is, however, it's got some annoyances. Mouse tracking, for example, can be kind of iffy out of the box. Here are some ways to fix the most common problems that we've had with the VNC framebuffer.

First, by default Xen's built-in VNC server won't listen on interfaces other than the loopback. To change this behavior, set vnc-listen vnc-listen in in /etc/xen/xend-config.sxp /etc/xen/xend-config.sxp to listen on all interfaces: to listen on all interfaces: (vnc-listen'0.0.0.0') You can also specify the IP address of the interface that you want the VNC server to listen on. Note that this will expose the machine's console over the network and should probably only be done on trusted networks.

One useful trick when working with the VNC framebuffer under Windows is to specify a tablet as the pointing device, rather than a mouse. This improves the mouse tracking by using absolute positioning.

usb=1 usbdevice="tablet"

(The usb=1 usb=1 line isn't strictly necessary-it's turned on implicitly by line isn't strictly necessary-it's turned on implicitly by usbdevice= usbdevice=. However, it's a useful reminder that Xen's USB emulation has been turned on.) One last minor annoyance: Sometimes the VNC mouse and keyboard interface just stops working (or else the display stops updating). Nine times out of ten, if you close and reopen the VNC session, it'll come back.

In addition to Xen's virtual framebuffer, you can handle access at the OS level-for example, by installing the VNC server under Windows or using Microsoft's built-in RDP (Remote Desktop Protocol). These have the advantage of allowing the virtual machine to handle its own graphics tasks rather than involving an emulator in dom0. RDP is also a higher-level, more efficient protocol than VNC, a.n.a.logous to X in its handling of widgets and graphics primitives. We recommend using it if possible. As Figure13-1 Figure13-1 shows, VNC, RDP, and SDL can coexist, with multiple independent sessions on the same VM. shows, VNC, RDP, and SDL can coexist, with multiple independent sessions on the same VM.

To enable RDP in administration mode, access System Properties, click the Remote tab, and check the box marked Enable Remote Desktop.

Figure13-1.Here we see two domains: one running Windows XP and being accessed through VNC; and one Windows Server 2003 domU being accessed through VNC, RDP from the Windows XP domain, and rdesktop from a Linux machine.

Windows XP and Windows Server 2003 include RDP clients. On other platforms, the open source rdesktop client allows you to access Windows machines from Unix-like operating systems (including Mac OS X). Simply run the following: #rdesktop

Et Voila!

Now you have Windows running. This would be a good time to make a backup of your clean Windows install so that you can conveniently reimage it when something goes wrong. Just create an LVM snapshot or file-based CoW device, as we outline in the Chapter4 Chapter4. It'll be good for your peace of mind.

When you've got a backup, you can do whatever it is you are accustomed to do with Windows. We would not presume to instruct you in this regard.

There are, however, some things to keep in mind about this new Windows install.

Windows Activation Windows licenses and activations are tied to hardware unless you've got a volume license. Thus, it would be a good idea to decide on a hardware configuration ahead of time and keep it constant to avoid the computer demanding reactivation.

In particular, specify a MAC address so that Xen doesn't randomly generate a new one on every reboot-this is the single most important value in Windows XP's hardware hash calculation. Other things to keep in mind are the memory amount and virtual CD-ROM.

Graphics Cards Another of the big caveats about Windows under Xen is that it still won't allow you to use 3D hardware-so the scenario of a desktop Linux box that runs games in a Windows domU is still purely in the realm of fantasy for now. As our discussion above has shown, the virtual Windows machine uses an emulated framebuffer via SDL or VNC. Neither of these modes supports any sort of acceleration.

The problem with hardware access in HVM mode (this applies to any PCI device, not just graphics cards) is that there's no way to map the hardware's memory s.p.a.ce into the memory of the guest-the guest has an additional layer of abstraction, translating a discontiguous block of physical memory into something that the unmodified domU operating system can use. Recently, chipsets have been incorporating an IOMMU IOMMU, which is hardware that can do this translation job in a manner a.n.a.logous to the processor's memory management unit (hence the name). Xen's support for Intel's IOMMU implementation, under the name of VT-d, is progressing, but it hasn't gotten to the point where it can make a graphics card usable by a Windows domU.

VT-D SUPPORTIf you're curious about whether your machine supports VT-d, you can run xm dmesg grep -i vt-d xm dmesg grep -i vt-d in the dom0 to find out. A machine with VT-d will say something like in the dom0 to find out. A machine with VT-d will say something like Intel VT-d has been enabled Intel VT-d has been enabled. If you see this, congratulations! The next Xen version will likely include facilities to enable you to use this advanced feature.

Another approach to graphics-one that wouldn't require replacement of all existing hardware-would be for the the graphics driver authors to implement the translation from domU addresses to machine addresses in driver software. Rumor has it that NVIDIA has a Xen-aware driver that could be a.s.signed to an HVM domU and used for 3D acceleration; however, it hasn't yet been released, so there's a good chance it doesn't actually exist.

One other promising direction uses a virtual 3D graphics driver to forward OpenGL calls to the actual graphics hardware. There are a couple of Xen-based projects that use this principle, but they are Linux only at the moment. VMware has also done some work on a driver architecture that allows for 3D, which appears to take the same tack.

No finished products exist, that we know of, to allow hardware 3D support under Windows. Nonetheless, it's a much-requested feature, and it is being worked on. We wouldn't make it an essential part of any Xen deployment just yet, however.

Paravirtualized Drivers for Windows As we've already mentioned (several times), HVM is somewhat slower than paravirtualization. Partially this is because of the need to virtualize memory access; however, this overhead is minimal compared with emulated I/O and its attendant context switches. (See Chapter12 Chapter12 for mind-numbing detail.) for mind-numbing detail.) You can address many of the speed issues related to HVM by swapping the emulated devices for paravirtualized devices after the install process completes. These devices will improve I/O speeds dramatically; however, Windows driver support is lacking. There are two options: proprietary and expensive drivers, or free and unfinished ones.

Proprietary Windows PVM Drivers Three companies have so far provided Windows drivers that take advantage of paravirtualization: XenSource, Virtual Iron, and Novell. All of these drivers are signed by Microsoft for trouble-free installation on Windows.

Citrix, wearing its XenSource hat, produces paravirtualized drivers for Windows as part of its Xen-based virtualization suite. These drivers work well, and you can test them for yourself by downloading the free version of the XenSource product. Unfortunately, these drivers don't work with the open source version of Xen.

Virtual Iron (http://virtualiron.com/) also provides paravirtualized drivers for Windows as part of its product. These drivers work with open source Xen, and Virtual Iron has been working on contributing changes to the Xen community. However, the drivers themselves are still closed source.

Finally, Novell offers Windows PV drivers that work with open source Xen as an independent product. These drivers are quite expensive (to say the least)-they are so expensive that we haven't actually tried them. More information is at http://www.novell.com/products/vmdriverpack/ if you're curious. if you're curious.

At this point, while all of these drivers (in our experience) function as advertised, none of them seem especially compelling to us. We're content to use Windows, with the HVM drivers, solely in light productivity tasks.

GPL Windows Paravirtualized Drivers There is one thing that you can try if you're sufficiently adventurous. GPL Windows PV drivers do exist. They are under active development, which is developer-speak for "don't use these for anything important." They work pretty well for us, but occasionally they do something surprising (usually unpleasant). These drivers try to improve performance by avoiding some of the inefficient device emulation and by using advanced techniques such as TCP Segmentation Offload, or TSO.

The GPL PV drivers are easy to install. First, we recommend checking the xen-devel xen-devel archives to figure out which version is the latest. As of this writing, 0.8.8 is the most current version, and it's available at archives to figure out which version is the latest. As of this writing, 0.8.8 is the most current version, and it's available at http://www.meadowcourt.org/WindowsXenPV-0.8.8.zip. Unfortunately, there's no web page that lists releases, so you'll want to search the archives of the xen-devel xen-devel mailing list to find out the most recent version. (Alternatively, you can check the current version using Mercurial-check the repository at mailing list to find out the most recent version. (Alternatively, you can check the current version using Mercurial-check the repository at http://xenbits.xensource.com/ext/win-pvdrivers.hg.) We opted to download the binary driver package directly within an HVM Windows XP Professional instance. It includes a fairly comprehensive set of installation instructions, but we'll go over what we did anyway, just for convenience.

First, unpack the drivers. We just dragged the appropriate folder to the desktop.

Next, run install.bat install.bat. Windows will complain several times about the drivers not being signed. Just click OK.

When the install finishes, reboot to make sure that everything still works.

a.s.suming you rebooted successfully, you should now be able to access PV devices from Windows. Try creating a scratch device in the dom0, then running an xm block-attach xm block-attach command like the following (with appropriate names, as always): command like the following (with appropriate names, as always): #xmblock-attachfalstaffphy:/dev/mapper/falstaff_sdbsdbw This should cause Windows to notice a new device, use the correct driver, and present a blank disk, which we can then format, as shown in Figure13-2 Figure13-2. Similarly, you can attach a network device with the xm network-attach xm network-attach command. command.

Finally, you'll need to edit the boot.ini boot.ini file to tell the GPL PV drivers to activate. (You might need to turn on Show Hidden Files and Folders and uncheck Hide Protected Operating System Files in Tools Folder Options to make file to tell the GPL PV drivers to activate. (You might need to turn on Show Hidden Files and Folders and uncheck Hide Protected Operating System Files in Tools Folder Options to make boot.ini boot.ini accessible.) accessible.) [bootloader]

timeout=30 default=multi(0)disk(0)rdisk(0)part.i.tion(1)WINDOWS

[operatingsystems]

multi(0)disk(0)rdisk(0)part.i.tion(1)WINDOWS="WindowsXPProfessional"/noexecute=optin/fastdetect multi(0)disk(0)rdisk(0)part.i.tion(1)WINDOWS="WindowsXPProfessional(PVdrivers)"

/noexecute=optin/fastdetect/gplpv Here we've modified the boot entry by putting /gplpv /gplpv on the end to tell the GPL PV drivers to activate. on the end to tell the GPL PV drivers to activate.

Figure13-2.Adding a paravirtualized disk with the GPL PV drivers Now shut down the Windows install.

Reboot, select the Windows XP Professional (PV Drivers) entry from the boot menu, and you should have a full set of PV devices.

Ongoing Development Windows under Xen is still immature, but it's already developed far enough to be useful. Using Xen, you can consolidate Windows servers in a robust, manageable platform and run client software in a native environment on the desktop. You have a reasonable way of accessing the machine via the framebuffer or rdesktop, and finally you have PV drivers for reasonable speed.