Metztli Information Technology Blog

Through Citrix acquisition of the open source virtualization entity formerly known as XenSource, Metztli Information Technology became an Citrix solution provider/advisor --at least for the time being. With XenServer 4.1 --free Express (formerly named XenExpress), Standard, and Enterprise-- an organization is enabled to execute 32 and 64-bit operating systems side-by-side in dedicated server(s); those virtual machine instances are controlled by a virtualization management console referred to as XenCenter. The downside is that XenCenter is not operating system agnostic; that is, a customer must have an proprietary operating system to control the Linux based hypervisor where the virtual machines are executing.

The XenExpress, XenServer, and XenEnterprise, 3.x versions, prior to Citrix acquisition of XenSource, had a Java based virtualization management console that could be used under Linux (I was using it under Debian even if the relevant packages were distributed as RPMs). Due to Citrix close relationship to the closed source proprietary software monopoly, it is to be questioned whether Citrix will release an virtualization management console that does not require the customer to have at least one closed source operating system to manage the XenServer virtual machines.

Under current Citrix XenServer virtualization management solutions strategy, the only way to control the virtual machines is through the XenCenter management console; hence the requirement that XenCenter runs on a proprietary operating system leaves XenServer solutions at a disadvantage against competitors like VirtualIron and VmWare (possibly not) that offer Linux and WinXX virtualization management consoles.

Having elaborated the above, recently I had the opportunity to show a proof of concept for an prospective customer using an entry level Sun MicroSystems Ultra 20 M2 AMD64 workstation, with a single dual-core Opteron hardware assisted virtualization CPU and 1GB of RAM. I selected an 32-bit evaluation copy of Windows Server 2003 (WS03) and a free-to-use never-expire 64-bit GNU/Linux Fedora 9 distribution, code named Sulphur. I had to prepare and test the installation, often during after hours, and decided to take a few snapshots to include in this entry.

I began by downloading the core installation ISO image of the XenServer hypervisor and the additional Linux pack ISO that contains paravirtualized enabled templates for a number of enterprise grade GNU/Linux distributions. Subsequently, the MSI code for the XenCenter was downloaded to be installed in the client closed source operating system. And the trial Licenses for Standard and Enterprise editions of XenServer are also available for an evaluator. It should be noted that the licenses for Standard and Enterprise editions of XenServer are activated by simply applying them to the core free (or Express) XenServer through the XenCenter management console.

The license key is, of course, applied to the XenServer product –the WinXX image in the background has no relevance to its application: it just happened to be there when I applied the procedure above.

The user selects the location of the trial license keys and elects either the XenServer Standard or Enterprise from the location where those were saved after the download.

XenConsole: Virtualization management console installation under proprietary operating system.

I installed the (virtual machine host) XenServer 4.1 hypervisor in the bare metal of the Sun Ultra 20 workstation –an user should be forewarned that the procedure wipes away all the data in the target hard disk since XenServer is designed to be installed into dedicated server class hardware-- using the XenServer burned ISO image and the optional GNU/Linux pack that provides templates for enterprise grade GNU/LInux.

Evidently, the hardware assisted virtualization feature of the AMD64 Opteron in the Sun Ultra 20 workstation is ideal to provide full virtualization for proprietary operating systems --like the WS03 that I installed-- and for unsupported GNU/Linux operating systems; that is, those for which no templates are provided in the XenServer GNU/Linux pack ISO available for download and optional installation. This is a snapshot of those templates available --if the GNU/Linux pack option is selected during the host XenServer 4.1 installation-- as seen from the XenConsole:

I proceeded to start up the proprietary operating system that came in one of my machines. It is a WinXPP operating system that fulfills the requirements specified in the documentation:

• Proprietary operating system: Windows XP, Windows Server 2003, or Windows Vista
• Proprietary Java alternative: .NET framework version 2.0 or above
• CPU Speed:750 MHz minimum, 1 GHz or faster recommended
• RAM: 1 GB minimum, 2 GB or more recommended
• Disk space: 100 MB minimum
• Network: 100Mb or faster NIC interface card

Thus, after the application of the proprietary alternative to Java,

After confirmation of the default path for XenCenter, the installation proceeds and an prominent X icon is created in the Win desktop. When the icon is clicked the XenConsole starts up, the visual clue is, of course, the initial splash picture.

Clicking the button available in the XenCenter, the user is allowed to add the physical server(s) --those where an XenServer hypervisor has been intalled-- that are to be managed; clearly, a pool of those can be created that will allow virtual machines to be transferred “live” for dynamic fail over solutions, as an instance.

Here I simply provided the IP address previously obtained from the host XenServer 4.1 successfully installed and rebooted in the Sun Ultra M 20 workstation.

As can be seen, the user is provided the option of saving the credentials for subsequent use:

And to protect those credentials with a password:

In the left pane, under XenCenter, we can highlight our host XenServer 4.1 denoted by its name GNU/Linux hostname (xenSunUltra) and we can see its current devices and resources, like DVD drives, local and removable storage. Selecting the console from the tabs on the right pane, we can manipulate our host XenServer 4.1 hypervisor, if needed. Here we can simply verify that the Xen hypervisor is based on a modified GNU/Linux 64-bit SMP kernel.

Installing an 32-bit proprietary operating system server for illustrative purposes.

From the templates on the left pane, I select the WS03 and double click on it; alternatively, an user could have selected the New VM in the next to upper menu bar.

And provide a name and description to our proprietary virtual machine:

An source location for the installation should be selected. In my specific case, I had an evaluation Cd-media, however an ISO image probably installed in a local or remote repository might be selected.

Depending in the license acquired, the user is allowed to manipulate the number of virtual CPU's and the random access memory (RAM) for the virtual machine instance.

Yes, the default virtual disk allocation for WS03 of 8GB specified in the template may be modified according to the intended use of the virtual machine. Here we simply leave it unmodified.

And the number of virtual network interface control (NIC) devices may be manipulated:

After the finish phase in XenCenter, I start the virtual machine; it boots from the DVD device and executes WS03 installation routine and we can see that the installation proceeds as in an regular operating system physical installation.

WS03 installation routine finishes transferring relevant files to virtual hard disk and the virtual machine is ready to reboot itself.

Subsequently, the machine reboots and the graphical user interface for WS03 to complete the second phase of the its installation kicks in.

As an aside, this is where Red Hat's VirtManager front end for Xen needs improvement because an user often experiences problems during the second phase installation procedure. The CD or DVD media device often disconnects in a second phase install when using VirtManager, forcing the GNU/Linux Red Hat and derivatives user to use Xen command line directives to proceed with the second phase of an install.

In due time the installation finishes and the proprietary colorful logo is displayed, alerting the user that WS03 is about to allow him/her to log in.

An CTR+ALT+DEL can be sent from the View menu of XenCenter, so as not to bring up the process utility in the Win client where XenCenter is an application.

For those selected operating systems in the template section of XenCenter, the application of the XenServer tools will provide a view of important parameters of the virtual machine execution.

Accordingly, I proceed to install the XenServer tools to monitor WS03 application and resource usage from the cascading VM menu,

The installation location option is shown in the subsequent XenServer tools setup screen:

XenServer Tools setup finishes and the virtual machine needs to be rebooted for the changes to take effect.

Upon rebooting our virtual machine, we find that we can now monitor WS03 performance metrics like memory usage, network input/output, and disk input/output –cool! On the other hand, unsupported operating systems, like 64-bit Fedora 9 Sulphur, could not take advantage of that important XenServer tools feature --even though GNU/Linux pertinent XenServer Tools RPM packages apparent apply .

Yes, we can undock (or detach) the WS03 virtual machine instance from XenCenter --as can be seen in this snapshot after the resolution was adjusted to a more comfortable size for the user/administrator of the virtual machines. We can detach from XenCenter even the console to our host xenSunUltra hypervisor.

WS03 SystemInfo command and the graphical user interface (GUI) view of some WS03 resources.

Installing unsupported GNU/Linux operating systems in XenServer 4.1

Having recently installed 64-bit Fedora 9 Sulphur to show how to install the IBM Lotus Symphony 1 into unsupported operating systems, naturally I used the readily available DVD media for a test installation into the virtual environment provided by XenServer 4.1.

From the topmost menu bar, the VM menu is selected; proceed to select the New option from the subsequent cascading options.

As for the proprietary operating system above, we give our GNU/Linux 64-bit Fedora 9 Sulphur a name:

Again, we tell XenCenter utility the source of the installation for the new virtual machine.

We select the number of virtual CPUs and the amount of RAM; however note that if the prior proprietary virtual machine and this other one that we are creating will be executing simultaneously, the sum of RAM for both VMs is constrained by the shown physical limit of 759MB of our single host xenSunUltra.

Since we are installing an unsupported operating system into our virtual machine, there is no default virtual hard disk allocation set. Accordingly, we select the Add button and the Disk Settings Dialog pops-up where the size for our virtual hard disk can be specified. Please note the available local storage in our test host xenSunUltra machine in the bottom field of the pop-up dialog; note also other options like Disk Access Priority settings.

After selecting a 9GB virtual hard disk for 64-bit Fedora 9 Sulphur, we press the OK button to save our settings. And we are taken back to the Virtual Disks installation phase were we can see our changes reflected instead of an empty field.

We leave the default two network interfaces:

And finish the installation, leaving the default check mark in the tiny square to allow our unsupported virtual machine to start as soon as the Finish button is selected.

And our virtual machine starts up and the DVD media bootstraps 64-bit Fedora 9 installation routine.

As the 64-bit Fedora 9 Sulphur installation routine proceeds into the "new" virtual hard disk, it will throw the user the warning similar to:

The partition table on device sda was unreadable. To create new partitions it must be initalized, causing the loss of ALL DATA on this drive.

This operation will override any previous installation choices about which drives to ignore.

Would you like to initialize this drive, erasing ALL DATA?

The warning is understandable since the unsupported operating system installation routine detects a raw device with no traces of prior index table. We proceed by selecting the Yes button:

We set the hostname as MictlanCihuatl and allow it to obtain its IP through DHCP.

Subsequently, 64-bit Fedora 9 Sulphur installation completes and we are prompted to reboot the machine.

Well, after rebooting our GNU/Linux unsupported VM, at the final configuration Welcome screen we note that there are still a few more steps to complete:

For open source software projects, Metztli Information Technology contributes back with relevant data. After all, our 64-bit Fedora 9 Sulphur operating system will never time out as is the case with the proprietary operating system that we installed first. Hence I decide to send my "hardware" profile:

Well, we are finally ready to boot into our unsupported 64-bit GNU/LInux Fedora 9 MictlanCihuatl host.

And we simply verify that, in effect, our VM is executing in 64-bit:

Oh, and we can even install the IBM Lotus Symphony 1 productivity office suite in our 64-bit Fedora 9 Sulphur VM --following the instructions in my previous web log entry: IBM Lotus Symphony 1 on 64-bit GNU/Linux Fedora 9 Sulphur.:

Evidently, virtualization is not only for enterprises. The use of virtualization by small and medium business (SM organizations will provide a path to more fully utilize their investments in technology infrastructure. By testing their potential applications in virtual machines, SMBs are even enabled to migrate from proprietary operating systems to open source, open standards, more cost effective and robust alternatives like those of GNU/Linux. We at Meztli Information Techonlogy are eager to help. Do not hesitate to leave us a comment here or use our Contact page for any questions, concerns, comments, or even for a no charge initial consultation.

DISCLAIMER Due diligence has been applied in composing this entry. Notwithstanding, the potential reader(s)/user(s) who (that) may duplicate the instructions here described assume(s) all risks. Metztli Information Technology reserves the right to modify or even delete the information contained here --as in all my published web log entries; hence information is provided AS-IS.