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()
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 fashion. 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 ships 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. 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"
maxmem=512 memory=512 vcpus=1 builder="hvm"
pae=1 acpi=0 apic=0 on_poweroff="destroy"
sdl=0 vnc=1 vncunused=1 keymap="en-us"
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.
 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.
*** You are reading on https://webnovelonline.com ***
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.
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]
/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.
*** You are reading on https://webnovelonline.com ***