I recently had the opportunity of testing Sun Microsystem's Sun Ultra 20 M2 AMD powered workstation http://www.sun.com/desktop/workstation/ultra20/.

My intention was to install XenSource's implementation of open source software (OSS) Xen on the bare metal of Sun Ultra 20 and subsequently install several Linux distributions from within XenSource's Java based console utility executing in another machine --as VirtualIron's Xen implementation also does. I must point out that XenSource recommends their product to be installed on a server class machine since it is aimed at enterprises.

 

 

 

 

 

 

 

The Sun Ultra 20 comes with a standard 512MB of RAM and an AMD 64 Opteron, 1210 series 1.80 GHz, dual core CPU. Although I was aware that XenSource minimum requirements for their Xen implementation products is 1024MB of RAM (as VirtualIron's), often a customer will insist (understandably) that a proposed solution be tested on their existing resources –which may not be the latest and most powerful hardware.

Since Metztli Information Technology addresses the needs of Small and Medium Business (SM above, the Sun Ultra 20 represented a compromise between the ideal and what exists in the real world of an SMB. At Metztli IT we are interested in providing e-business solutions that focus on addressing the problem the SMB is having. We are aware that SMBs often will use as much of their existing resources as possible. We are also aware that we must be flexible to accommodate the SMB's need in the manner that makes the most sense to them.

 

 

 

 

 

 

 

An interesting feature of Sun Ultra 20 is its price: $845 U.S. Dollars (as of 06-26-2007). Making it appealing for SMBs on a budget. Obviously, adding RAM in increments of 512MB provides options for the SMB to upgrade its investment as its needs change over time.

The virtualization extension in AMD's CPU, enabled by default in the Sun Ultra, will allow an SMB to run (with the proper amount of RAM, of course) unmodified (proprietary) operating systems. Although Metztli IT recommends the Linux operating system due to its open source nature (GPL) and security, it is evident that an SMB has Windows applications that demand an underlying Windows operating system. And here is where the Sun Ultra 20 flexibility shines.  Whether an SMB is contemplating a migration away from proprietary and expensive operating systems and applications, or the SMB is simply aiming for coexistence of proprietary and open source superb alternatives, executing its Windows and Windows dependent applications inside a Linux operating system's Xen virtual machine will provide an SMB flexibility and added security.

 

 

 

 

 

 

 

Both, XenSource and VirtualIron, provide an implementation of Xen running on a modified minimum Linux operating system on the bare metal of your hardware. But since XenSource's XenExpress refused to boot in the Sun Ultra 20 due to having only half of the RAM resources recommended, I decided to install Novell's OpenSuSE Linux 10.2, subsequently adding Novell's modified Linux Xen kernel implementation. Please note that Novell OpenSuSE as well as Red Hat Fedora and Debian, are unsupported Linux distributions. For an SMB that --naturally-- demands support and stability, Novell and Red Hat offer client and/or enterprise-level supported Linux implementations adequate for the needs of an SMB at a fraction of the cost of proprietary closed-source equivalents.  Please, ask us at Metztli IT if you desire installation assistance and/or maintenance support for a deployment of the Debian operating system.

Being based on AMD 64 Opteron, the Sun Ultra 20 accepts 32 and 64-bit operating systems. It provides more flexibility for an SMB whose existing software resources are based on the older architecture but evidently will move towards the 64-bit path traced out by the computer hardware industry. Consequently, I decided to install the 64-bit version of Novell's OpenSuSE Linux distribution.

 

 

 

 

 

 

 

After partitioning the Sun Ultra 20 160 GB mass storage disk and allocating OpenSuSE 10.2 approximately 30GB, the 64-bit operating system installation went smoothly --with the exception of a required update to YaST, OpenSuSE's packaging facility. At that almost final phase one must not select anything other than the default package management update; doing otherwise will introduce dependency issues.

After OpenSuSE's installation, security and software package updated –which are done effortlessly through the 64-bit package management interface, I proceeded to install the included Novell modified Linux Xen kernel, hypervisor (Dom0 in Xen parlance), and related support utilities from YaST. After waiting for a short while the package management utility finished and I rebooted the Sun Ultra 20.

 

 

 

 

 

 

 

In effect, OpenSuSE's automated utility even added the modified Linux Xen kernel to its Grand Unified Boot Manager (GRU. So I selected that and pressed the enter key. Recalling that XenSource's XenExpress had refused to boot into an environment that did not meet its 1024MB minimum requirement, I was pleasantly surprised that OpenSuSE 64-bit booted “normally” into the Dom0 environment. Furthermore, the Sun Ultra 20 built-in ATI ES1000 graphics card actually did not exhibit an issue with Xorg's X window graphical user interface. Refreshing. In the past I had an issue with an (older) 64MB ATI in an older machine that would end its OpenSuSE Xen based booting process with an black screen –refusing to boot into graphical mode-- until I replaced the video card with an Nvidia roughly equivalent unit.

Considering that SMBs have investments in proprietary software, the first virtual machine guest (DomU, in Xen parlance) I tried was Windows XP Professional. I had my reservations. It was one thing to boot into OpenSuSE's Xen hypervisor (Dom0) mode and another to carve out memory that I knew the machine did not have left over. It might crash the machine according to Xen documentation.

 

 

 

 

 

 

 

I also knew, however, that having initially allocated four(4) times as much as physical RAM to OpenSuSE's swap file might provide a safeguard  and even though slow, Windows might install and run, effectively serving as a test case for an SMB. Another issue that bothered me somewhat is that I was running a 64-bit modified Linux Xen kernel and I would be installing a 32-bit Windows client operating system in the Xen virtual machine (DomU). Fortunately, the OpenSuSE Linux Xen modified kernel was based on the latest Xen release (3.0.3) --and it worked.

Following the instructions for a full virtualization example at Novells OpenSuSE's pertinent site, I modified the files myxm.hvm and myxmhdd.hvm. The former to accesss the DVD ROM device in the Sun Ultra 20, and the latter to access a locally created file as a hard drive for the Windows virtual machine. Please, note that it is possible to access a physical partition --as an SMB would desire-- specifically allocated for its Windows related software resources.

Although the virtual machine creation is manual in OpenSuSE, Novell's supported alternative is more automatic and provides a Virtual Machine Driver Pack to make your proprietary Windows resources run smoother inside their SuSE Linux supported environment. Since I simply was interested in a proof of concept that I may leave at the customer's site, OpenSuSE will be an adequate option, clearly (thank you, Hana).

 

 

 

 

 

 

 

Following the Xen full virtualization example at http://en.opensuse.org/Xen_Full_Virtualization_Example , I proceeded (being the root or super user at the Linux command shell prompt) to locate my file system position at /var/lib/xen/images in OpenSuSE. Once there, I proceeded to type at my command shell prompt:

dd if=/dev/zero of=windisk.img bs=1k seek=4096k count=1

dd if=/dev/zero of=windisk.img bs=1k count=1 conv=notrunc

That creates the initial file of the name windisk.img that Xen will allocate to the Windows virtual machine --and the Windows virtual machine subsequently will regard as its “hard disk.”

Subsequently, and adhering to the instructions referenced priorly, I changed my file system position directory to /etc/xen/vm where I placed my modified versions of the files myxm.hvm and myxmhdd.hvm.

I specified 128MB of RAM in the file myxm.hvm that accesses the initial DVD physical device, in the Sun Ultra 20, for the initial installation of Windows. In this phase, besides the hardware recognition process, the Windows install routine merely copies the bootstrap files to the file/partition for the second phase of its installation.

I specified 256MB of RAM in the file myxmhdd.hvm that represents the configuration for the Windows second phase of the installation onto its “hard disk” file (created priorly): /var/lib/xen/images/windisk.img.

And that is it. Being the root or super user and positioned at the directory where the configuration files for the virtual devices reside (i.e., /etc/xen/vm), I referenced first the file myxm.hvm that maps the physical DVD device on the Sun Ultra 20 to the virtual machine by typing:

xm create myxm.hvm

A small window appears and the Windows installation routine begins. After the user agrees to the usual restrictions of the proprietary software which are obfuscated for us, the non lawyers, the installation utility proceed and recognizes our file at /var/lib/xen/images/windisk.img as a four(4) GB “hard disk” and prompts the user if s/he desires the installation to proceed into it.

The installation on the virtual machine continues as if it were on actual hardware, and the Windows operating system install finishes without hiccups

 

 

Conclusion:

The Xen hypervisor on an AMD x64 Opteron based Sun Ultra 20 provides small and medium business (SM organizations flexibility to address their proprietary software investments concerns.  Additionally, Xen  provides an SMB an viable resource to consider an migration to an open source and open standards, cost effective and more robust alternative to a uniform proprietary environment. SMBs should consider that investments in an heterogeneous environment --and more specifically in Linux-- will provide superb resilency to the focused malware and attacks that take advantage of their unstable closed-source proprietay operating systems and applications.

Although I referenced Novell's SuSE Linux platform for easier and a more smooth migration away from –or coexisting with proprietary software-- if an SMB has a more knowledgeable IT stuff, it may consider Red Hat Linux Enterprise Server or Debian Linux.

Although I downloaded Sun MicroSystems' Solaris Express, Developer Edition, it refused to install because it required a minumum of 700+MB of RAM and, as mentioned priorly, the base Sun Ultra 20 comes with only 512MB or RAM.

As an additional option, Oracle's Unbreakable Linux –based on Red Hat-- will even provide indemnification for its customers concerned about the Fear, Uncertainty, and Doubt (FUD) approach by a certain proprietary software vendor that apparently can not compete on technical creativity.

This latter entity engages in what Professor Eben Moglen refers to as, "Be very afraid" tours designed to inflict fear in the OSS developers --with the effect of potentially undermining the excellent quality, rich variety, and superb community support, currently provided by the dynamic OSS community of which Metztli IT is a member and advocate.