There are three ways to install a VM (virtual machine) on the XenServer host—from the menu bar at the top, by right-clicking...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
on the host in the upper section, or from the upper section's task bar. When choosing to install a VM, a fifth tab labeled "Install XenVM" appears in the tabbed view. The AC's lower section then asks what template to use when installing this VM in addition to what to call it, how many virtual CPUs it should have, and what its initial memory allocation should be. It is also possible to resize the initial virtual hard disk of a VM and add additional virtual disks. Whether or not the VM is attached to the host server's physical optical drive or uses an ISO image is also an option. Finally, the number of network interfaces available to the VM can also be configured. To finish the configuration, click on the button labeled "Install" in the bottom right-hand corner of the AC. The bottom section switches to the "History" tab to display the "Install XenVM" command that has been submitted to the host server's command queue.
The XenVM has now been installed. Selecting the VM from the list in the upper section will change the tasks in the task bar; the tasks—such as the ability to reboot and shutdown—will only apply to the VM . As with selecting a XenServer host in the upper section, selecting a VM also causes the lower section to show a tabbed view. The tabs are also similar to the ones when selecting a XenServer host: "Overview," "Performance," and "History."
The "Overview" tab displays what type of guest OS the VM has been configured for, as well as its virtual hardware configuration—virtual CPUs, memory, virtual disks, how the CD-ROM of the VM is configured and the network interface settings of the VM. The "Performance" tab details the VM's CPU usage. Additional performance indicators are listed once the XenVM tools package is installed in the VM's guest OS. As with the host server's "History" tab, the VM's "History" tab lists events that the VM or the user have generated on behalf of the VM.
While the host server has a "Text Console" tab, the VMs have a tab labeled "Graphical Console" that is inserted between the "Overview" and "Performance" tabs. This tab displays a console connection to the selected VM. This is labeled a "Graphical Console" because the guest OS installed in the VM could be Windows (which uses a GUI) or a Linux distribution with Xen installed.
Installing a guest OS
It is still necessary to install the guest OS inside of the VM. To do this, either insert a Windows Server 2003 install CD into the host server's optical drive or copy an ISO image over to the XenServer host. For an ISO image to appear in the XenServer AC, the ISO image must be copied to the following path on the host server: "/opt/xensource/packages/iso/." Copy an ISO image of the Windows Server 2003 install CD to the host server, for example, "microsoft_windows_server_2003_standard_edition_sp1.iso".
To use the ISO image to install the guest OS inside of the VM, select the VM in the upper section and then click on the VM's "Overview" tab in bottom section. The right-hand of the display contains a section labeled "Configuration." Find the section labeled "CD-ROMs" and click on the entry under the column header "Disk." This action causes a drop-down select box to appear. The ISO image that was copied to the host server is listed here. Select the ISO image and click "Apply" in the lower right-hand corner to apply the changes. Select the VM's "Graphical Console" and click on the "Reboot" task in the upper section's task bar in order to reboot the VM. The Xen AC asks if it is okay to reboot the VM; go ahead and confirm this prompt. When the XenVM reboots, it boots off of the ISO image into the Windows installer. Go ahead and install Windows just as you would do on a physical server. After the Windows installer completes, it is time to install the XenVM tools package.
Installing the XenVM tools package
The first step to installing the XenTools package is to mount the XenTools package ISO image for the VM. To do this, follow the same procedure used to mount the Windows installer ISO image, except this time select the ISO image named "xswindrivers.iso." Mounting the XenTools package ISO image will cause the Windows guest OS to auto-run the XenTools installer. Run through the installation steps, installing the XenTools drivers even though they are not signed. After the installation completes, reboot the VM for the new drivers to take affect.
Once the XenVM tools installation completes and the VM has been rebooted, click on the "Performance" tab for the VM. In addition to the CPU usage, there are now performance indicators for memory usage, disk rate, and network rate. This information is also reflected in the list in the upper section next to the VM's name. Additionally, now that the XenVM tools have been installed, it is possible to resize the display of the VM to a much higher resolution. To take advantage of the larger display area, use the "Undock" button that sits on the right-hand side above the VM's graphical console.
Exiting the AC disconnects the client from the XenServer host, but it does not halt the VMs that are running on the host. To reconnect to the host, re-open the AC and either enter the Master Password to restore the last session or log into the XenServer host again.
XenServer pros and cons
All software has its strengths and weaknesses, and XenServer 3.1.0 is no exception. But where exactly does XenServer shine, and where does it lag behind its competitors?
XenSource XenServer uses the open-source project Xen as its hypervisor, and why not? XenSource is after all run by the people who created Xen. No one should know Xen better than its creators, and that is why the hypervisor is the most polished of all of XenServer's components. There are a few nit-picky issues, however beginning with the XenServer installer. The XenServer installer's cursor is a blinking yellow bar, and this by itself would not be a problem; it's just that the installer's text-entry fields are underlined with yellow bars. As a result, a user never knows exactly which field is awaiting input. Another problem with the installer is the continued insistence that the person installing XenServer choose Dynamic Host Configuration Protocol (DHCP). After choosing between DHCP and a "Different Network Configuration" the installer still defaults to DHCP on most prompts including IP address settings and domain name server settings.
Once the user chooses to go a different route than DHCP, the installer should remember this and stop assuming that on the next menu the user will change his mind. Yes, those two complaints about the installer are trivial. However, XenSource is aiming to build a beautiful virtualization solution, and all blemishes, no matter how tiny, will scar the result. Therefore it is important to recognize even the smallest errors so they can be fixed.
A very obvious capability the XenServer hypervisor lacks is snap shots. Users have become accustomed to associating virtualization with the ability to easily roll-back changes thanks to snap shots. Administrators may quickly find themselves wondering where this capability is in XenServer, and if they can live without it.
64-bit guest operating systems
Currently the hypervisor does not support any 64-bit Windows guest OSes. Support for 64-bit guests is on the XenServer road map. Another annoyance with the hypervisor is that the XenTools package used to enhance the performance of the guest OS does not include signed drivers for Windows. This problem is not unique to XenServer; many vendors that include drivers for Windows do not sign those drivers. The point of signed drivers is much like the point of purchasing SSL certificates from a well-known CA—sure it's possible to roll your own, but you buy from the public vendors to create a sense of enterprise and assuredness to the customers that you're not just messing around.
As for other issues with the XenServer hypervisor, I was unable to find any. The XenServer hypervisor is a rock-solid and stable piece of software.
XenSource XenServer 3.1.0 uses CentOS 4 as its control OS, and XenSource does not do much to modify an already very stable distribution of Linux. There are, however, a few areas where XenSource can improve XenServer's control OS.
All commands related to Xen should start with a command prefix, such as "xen-". Many commands do begin with "xen-", but not all of them. When trying to find a specific command, it is confusing if all Xen commands are not grouped together. For example, arguably the most useful Xen command, "xe," is not even displayed if a user types "xen" and then uses the shell's tab completion feature to list all available commands. For the sake of user friendliness, XenSource should group all Xen-related commands together with a single prefix.
All commands should also have associated man pages that detail their purpose and usage. The command "xenstore-control" does not have any man page associated with it; executing the command prints out the command's usage, but executing the command with the correct options does not appear to have any actual effect. What does this command do? A man page would be really handy.
The command "xentop" should be familiar to anyone who uses Linux because of the similarity of its name to the traditional "top" command. The command displays the server's performance statistics in real time as well as the performance statistics of the VMs running on the host. However, the format in which "xentop" prints out the name of the VMs greatly reduces the command's usefulness. Xentop uses the VM's Universally Unique Identifier (UUID) when labeling a VM instead of the much more useful name of the VM. (A quick tip: Use the command "xe host-vm-list" to print out a list of the VMs on the host as well as their UUIDs). Xentop is free to print the UUID in addition to the name of the VM, but the name is a must.
To be fair, some of the above complaints do not fall solely upon the shoulders of XenSource; because XenSource uses the open source Xen hypervisor, they are beholden to use the software as it comes. Yes, XenSource could modify commands, but that confuses users who already have an understanding of Xen in the wild. It would be useful if XenSource could help guide the Xen community and developers in such a way that these problems are fixed.
This last issue with domain-0 is highly detrimental to administering the XenServer host via a console session. The method the XenServer uses to catalog installed VMs in the file system is by UUID and not by the names of the VMs. Because of this choice it is extremely hard for newcomers to Xen to understand where a VM's files are stored on the Xen host. It would be more logical to store all of a VM's files in a single directory instead of separating them, but XenServer stores files inside a Xen store that exists at the root of the file system and is labeled by a UUID. For example, this is the file system that was created in the above hands-on experience:
/SR-49a99eef-1015-4637-9983-b05fcd594e7c - This is the Xen store.
/SRM/configs - This is the directory that contains the configuration files of the XenVMs.
/images - This is the directory that contains the XenVMs' virtual hard disks.
Even a user who has used Xen before may not be familiar with XenServer's VM configuration files since they do not follow the same format as detailed in the Xen documentation in the Xen Users' Manual, even though XenServer includes "example" configuration files in this format in /etc/xen. It seems that XenSource has implemented its own custom XenVM configuration format after writing way too much code in LISP.
Aside from the above complaints, no other real issues cropped up when puttering around inside domain-0. As mentioned, the control OS installed in domain-0 is CentOS 4, and it contains all the normal commands and daemons one would expect to find in a CentOS 4 release.
One of the really nice features of domain-0 is that it exists in a fairly pure state. There are no special configuration utilities created by XenSource to modify basic functionality, such as the control OS's firewall. The firewall is simply the standard iptables set up, controlled by /etc/sysconfig/iptables-config and /etc/sysconfig/iptables.
There's not much more to say about domain-0 other than users familiar with a CentOS 4 distribution will feel right at home. In the final part of my evaluation (coming soon), I'll take you through the administrative console.
About the author:Andrew Kutz is an avid fan of .NET, Open Source, Terminal Services, coding, and comics. He is a Microsoft Certified Solutions Developer (MCSD), a SANS/GIAC Certified Windows Security Administrator (GCWN), and a VMware Certified Professional (VCP) in VI3. Andrew graduated from the University of Texas at Austin with a BA in Ancient History and Classical Civilization and currently lives in Austin, Texas with his wife Mandy and their two puppies, Lucy and CJ.