BMC Software Virtualizer

I tested Virtualizer in our Syracuse University Real-World Labs®, installing it on a Red Hat Linux Enterprise Server 4. I also implemented Virtualizer Service Agents on virtual machines (VMs) running on VMware ESX Server 2.5.2 and a conventional Intel PIII server (dual 1,400-MHz processors) with 1,024 MB of RAM running Microsoft Windows 2003. Virtualizer scaled out new servers and other enterprise resources on demand. However, it didn't create new virtual machines on the fly. I'll have to wait for the next version for that.

Virtualizer comprises the Virtualizer itself and the server agents. Virtualizer orchestrates server management and hosts a Web console to configure and set policies or rules that trigger virtualization actions in demanding situations. If an application is down on one server, for example, or another server is suffering high CPU utilization, Virtualizer can add server, application, and storage resources automatically from a global pool to meet the failure or the demand.

The server agents run on Linux, Solaris or Windows. Agents collect server and application availability and performance data and communicate that information to the Virtualizer. They also let local command execution implement and enforce policies. All this is done over multicast, so you must enable multicast on switches and routers.

Getting Started

Virtualizer runs only on Red Hat Linux Advanced Server (AS) or Enterprise Server (ES) 2.1, 3, and 4. I used ES 4 on a dual processing Intel Xeon (3 GHz) server with 3,072 MB of RAM. That made for plenty of horsepower to meet BMC's minimum requirements: Intel P4 (3.4 GHz) with 512 MB of RAM.

BMC recommended that I install everything (all Linux packages). I followed those instructions. Otherwise, I would have gotten bogged down in package dependencies--not an ideal way to spend a morning.

Virtualizer needs Linux's optional systat utility, for example, as well as MySQL to house configuration and policies and sendmail to send alerts to administrators. If SELinux (Security-Enhanced Linux) is installed for advanced security, it must be set to "permissive" mode in the /etc/selinux/config file. Otherwise, the Virtualizer won't have the right permissions to run on the OS.

A shell script installed the Virtualizer and all its components, including a policy engine to set rules for virtualization, adapters that interact with F5's BigIP load balancer and Altiris' Deployment Server, and APIs that integrate with other BMC management tools like BMC Patrol and Impact Manager. It also set up MySQL without input, set the multicast address and port (IP 239.0.0.1: 48000) to communicate with agents, and gave me a choice of running the console on HTTP or HTTPS. I took the secure route (HTTPS) and fired up my browsers.

I accessed the Virtualizer console using both IE 6.0 and Firefox 1.03 (Solaris). Mozilla 1.4.3 and above will also work. I quickly got to work and finished some configuration tasks. I tuned up the alert threshold and redirected alerts to a nonproduction e-mail account. But there was no way to configure NTP (Network Time Protocol) from the console. That must be done while installing the Virtualizer or the Linux command-line interface. Either way, make sure clocks are synchronized across all systems. That's important in policy-based, virtualized environments--especially when the Virtualizer aims to stop and start servers, services and applications on demand.

Virtualization Station

Using VMware VirtualCenter 1.3 (Build 16701), I created four virtual machines on VMware ESX Server: two Windows 2003 Servers and two Red Hat Linux Servers (version 9). BMC says the next version of Virtualizer will create VMs without VirtualCenter or the ESX Web console.

Next, I installed agents onto the VMs. On Windows, the agent is a self-extracting and -installing file. For Linux/Unix, I had to unpack the file and run a script. Neither operation requires user input. The information for the agent to communicate back to the Virtualizer is contained in the configuration. But Virtualizer supports only those agents running on the same subnet as the server. And there's no facility to update agents unless you use BMC's Marimba product. Short of that, you must reinstall if you update agents.

After install, the agents touched base with the Virtualization server to report and respond to tasks. The Virtualizer added the servers (with agents) to a global pool of resources. I assigned the agents to server and application policies to virtualize resources for redundancy and scalability. I returned to the console to give the servers something to do and the agents something to report.

Setting up policies and rules to distribute and implement server resources, like CPU, applications and storage, was as easy as completing a Web page. There is no new scripting language to learn and no complex syntax to command. I set up two application-monitoring policies for HTTP using Apache and IIS. These policies were included in the base package along with other policies for JBOSS, LDAP, NAMED, Oracle9i and Squid. I only needed to create an application name, set a period to monitor the application for failure, and identify the command-line syntax on the server to monitor the application. A return code of "1" can trigger an action.

I monitored HTTP on Linux using the Perl script lwp-request. On Windows, I used the "ServiceStatus" command. Then I designated servers from the global pool to the policies and configured for the specific rules to scale Linux Apache and Windows IIS Service on demand.

Auto-Virtualization

I set a priority of 1 (the range is 1 to 99) for my Linux Apache rule. Then I set a minimum of 1 and maximum of 2 servers to run the httpd daemon. In effect, the rule stated that there should always be one Web server available to browsers.

I turned off the Apache httpd daemon on one VM and perched on the console. There, I set the refresh rate to 10 seconds and watched as the Virtualizer identified the daemon I turned off as "failed." It then proceeded to turn on an httpd daemon on my redundant Linux VM to match my rule to have at least one Web process running on a Linux server. All this occurred within 30 to 60 seconds--the configurable interval within which the Virtualizer goes out and checks whether the application is running. You can tune the interval appropriately for your own SLA.

Using the Windows 2003 virtual machines, I set a policy to maintain at least one Windows IIS running. In addition, I wanted to increase the number of IIS servers if one sustained 90 percent CPU utilization over 60 seconds. With the Windows cpuhog.exe utility, I generated CPU load sufficient to trigger the policy. Once done, Virtualizer activated another IIS server in the global pool to handle Web load when one of my Windows VMs had limited CPU time available.

Virutalizer makes it easy to automate virtual environments to create redundant and scalable servers, applications, and storage on demand using an advanced policy engine and agents supporting Linux, Solaris, and Windows. But it cannot create virtual machines in ESX Server and support a redundant mode of operation. Those capabilities will have to wait for a future release.

Sean Doherty is a senior technology editor and lawyer based at our Syracuse University Real-World Labs®. Write to him at [email protected].