Xen virtualization and Microsoft Windows come from two separate worlds -- open source and proprietary, respectively – but they'll still play well together…with a little tweaking.
Xen virtualization, when running on machines with the latest generation of chips from AMD and Intel, can now support unmodified operating systems such as Windows. However, in order for Xen to support those systems, it must use an emulation layer of software, which imposes a performance penalty.
In this tip, part two of my XenExpress tutorial, I'll show you how to create a Windows virtual machine and load the Windows operating system into it. In the first part of this series, I gave a brief overview of Xen's virtualization technology and provided step by step instructions on installing XenExpress.
XenSource has a close working relationship with Microsoft. Together, they have created Windows drivers that enable Windows virtual machines to operate with XenServer products without requiring the use of emulation software. These drivers, referred to as PV drivers, restore near-native performance to unmodified guest operating systems. I will show you how to install PV drivers for Windows guests later in this article. Finally, I will also show you how to use remote desktop protocol (RDP) to communicate between Windows virtual machines and the XenConsole. Using RDP improves console responsiveness and graphics performance (though it should be noted that even the higher-quality graphics are still shown at a low-quality – if you're interested in playing computer games, XenExpress virtualization is not the right avenue for you).
Creating a Windows XP virtual machine
In this example, I'm going to illustrate how to install Windows XP, although the exact same methods are used to install Windows Server. Before starting, put a Windows install disk into the disk tray of the XenExpress machine.
In the XenConsole, click the "New VM" button underneath the menu bar (see figure six). A dialog box is then displayed showing a number of choices for virtual machine templates, with a list of the steps that must be taken for virtual machine (VM) installation listed along the left. In figure seven, you can see Windows XP is fourth on the list (Note: XenExpress requires Windows XP Service Pack 2; earlier versions of XP are not supported).
Figure six: Click the "New VM" button.
Figure seven: Windows XP is fourth on the list.
The next dialog box (see figure eight) offers the opportunity to select a name for the virtual machine. For this example, I'll leave the default suggestion; in a real production environment you'd choose something more appropriate for the VM's role – e.g., a DNS server would be called something like Windows DNS Machine.
Figure eight: Select a name for the virtual machine.
The next dialog box (see figure nine) asks for the location of the installation media, with both an ISO image or a physical disk supported. Since I already put the installation disk into the XenExpress tray, I'll keep the default suggestion.
Figure nine: The next dialog box asks for the location of the installation media.
After selecting the installation media location, the VM installer asks for the number of virtual CPUs and amount of memory to be set for the new VM (see figure 10). Obviously, the selection will vary according to the operating system and the expected load, but I'll leave the defaults in place. Note that XenServer can support more virtual CPUs than the number of physical CPUs actually present on the underlying hardware. This can be a useful option for testing software designed for high-performance boxes in the absence of actual high-performance hardware.
Figure 10: The VM installer asks for the number of virtual CPUs and amount of memory to be set for the new VM.
The next dialog box is used to set the amount of disk space available to the VM (see figure 11). The default suggestion is 8 GB, which I will leave in place. Note the two buttons available for "Add" and "Shared." The former is to increase the amount of storage for the VM. The latter is used for environments in which the VM may migrate to another server, which requires use of a storage medium that can be accessed by more than one physical server.
Figure 11: The next dialog box is used to set the amount of disk space available to the VM.
The penultimate dialog box (see figure 12) is used to set the network interface for the new VM. XenServer (as well as all Xen-based virtualization) offers a number of network options, including an option that allows all the VMs on a given server to intercommunicate but unable to talk to the network outside the physical server. The default is the simplest case, in which XenExpress provides one virtual network interface that talks to the physical network card on the server and allows the VM to communicate with outside network resources.
Figure 12: The next dialog box is used to set the amount of disk space available to the VM.
The final dialog box (see figure 13) merely asks for confirmation of the previous choices and kicks off creation of the VM. A few seconds later, a new entry is present on the left hand panel (see figure 14), indicating that a new Windows XP VM is available.
Figure 13:The final dialog box merely asks for confirmation of the previous choices and kicks off creation of the VM.
Figure 14: A few seconds later, a new entry is present on the left hand panel.
Clicking on that entry and then clicking on the console tab (see figure 15) shows the Windows installer welcome screen, indicating that it is now time to install the Windows operating system into the Windows VM. Click anywhere in the console window, press enter, and the venerable Windows installer goes into action (see figure 16). Since you've most likely installed Windows more often than you'd like to remember, I won't discuss these steps; suffice it to say that the standard install routine now commences.
Figure 15: Clicking on that entry and then clicking on the console tab shows the Windows installer welcome screen.
Figure 16: Click anywhere in the console window, press enter, and the venerable Windows installer goes into action.
At the end of the Windows installation process, voila! Windows is installed in a XenExpress virtual machine. For an illustration, please see figure 17, which shows MSN running in the new VM. Note that the VM is identified in the left hand panel as "Windows XP SP2 (1)."
Figure 17: MSN running in the new VM.
Getting better performance with PV drivers
As mentioned earlier in the article, thanks to the new generation of chips from AMD and Intel, unmodified operating systems can run as guest VMs within Xen; however, the use of a software emulation layer imposes a performance hit. XenSource provides a set of PV drivers for Windows guests, and that is the next task I'll turn to.
In essence, the PV drivers make it possible for unmodified VMs to talk directly to the Xen hypervisor. XenExpress makes it extremely simple to get PV drives installed, and it's well worth doing so, as performance can be increased significantly.
In order to begin the installation process, choose "VM->Install Tools" from XenConsole's main menu, as shown in figure 18. You will be shown a EULA Agreement (see figure 19), which you must accept in order to proceed with PV installation. You will be shown a dialog box asking where to install the drivers. I always accept the default location.
Figure 18: choose "VM->Install Tools" from XenConsole's main menu.
Figure 19: Accept in order to proceed with PV installation.
The installation then commences and takes no more than two or three minutes, tops. At the end, you will be asked to reboot the VM. That's it – three minutes work to improve performance by 10 or 20% -- worth it, don't you think?
Installing RDP support
Xen is primarily a server-oriented virtualization solution. It doesn't really offer great support for graphics, to the point where even the simplest mouse interaction looks like the cursor is swimming through molasses. This is due to the use of VNC as the VM access mechanism. Fortunately, that can be fixed by changing to Microsoft's remote desktop protocol (RDP), which offers much snappier responses (although it must be noted that this by no means turns a XenExpress VM into a gaming machine; if you want rich graphics, your best bet is to stick with non-virtualized arrangements).
Most of the work in setting this up takes place in the VM operating system itself, not XenExpress, but it's not too hard.
First, you need to configure the Windows firewall to allow RDP access. Go to the Windows Control Panel and click on "Windows Firewall." Then bring up the Exceptions tab and click the "Remote Desktop" radio button (see figure 20).
Figure 20: Bring up the Exceptions tab and click the "Remote Desktop" radio button .
You might think having enabled Remote Desktop would make the VM accessible via RDP – but you'd be wrong. You still have to go into the Control Panel System Properties and click on the "Remote" tab, where you can set the "Allow Users to Connect Remotely to This Computer" checkbox (see figure 21).
Figure 21: You still have to go into the Control Panel System Properties and click on the "Remote" tab, where you can set the "Allow Users to Connect Remotely to This Computer" checkbox.
Now you're done setting the VM to accept RDP!
The only thing remaining to do to begin using RDP to access the Windows VM is to click the "Switch to Remote Desktop" button in the upper right hand corner of the XenConsole screen (see figure 22). You'll be asked to login to Windows.
Figure 22: The only thing remaining to do to begin using RDP to access the Windows VM is to click the "Switch to Remote Desktop" button.
After you switch to RDP you'll notice an immediate improvement in cursor responsiveness, which is a relief (though, as noted, don't imagine it's ready for shoot-'em-up computer games).
That's it. You've now installed XenExpress and gotten a Windows guest up and running. Not very difficult at all.
About the author: Bernard Golden is CEO of Navica Inc., a systems integrator based in San Carlos, Calif. He is the author of Succeeding with Open Source (Addison-Wesley, August 2004) and the creator of the Open Source Maturity Model (OSMM), a formalized method of locating, assessing, and implementing open source software.