eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
“Project Boston,” the current beta version of Citrix’s XenServer 6, includes a host of new features that make the virtualization platform worthy of consideration in modest-size organizations.
Project Boston integrates previously separate storage and virtual machine management components. The beta version, which has no announced release date, performed well in eWEEK Labs’ tests. Of particular interest is the new SSM (Self Service Manager), which is the focus of this first-look review.
The SSM is a virtual appliance that runs in the XenServer environment and is accessed via a straightforward, secure Web interface. As such, the module is simple to install and I was up and running in a matter of minutes. I ran the Citrix XenServer test environment on two physical hosts, including an Acer AR380 F1 server with two Intel Xeon X5675 CPUs, 24GB of DDR3 (double data rate type 3) RAM, eight 146GB, 15K rpm SAS (server-attached storage) hard disk drives and four 1GB on-board LAN ports. The second system was an HP Z800 Workstation with two Intel Xeon X5680 CPUs with 18GB of DDR3 RAM and a single 1G NIC (network interface card).
Because the physical systems used slightly different models of the Intel Xeon CPU, I had to use a XenServer Advanced edition license to enable both systems to work in a single resource pool. Competitor VMware vSphere uses a related technique to run similar, but not exactly equal, processors in a shared resource group. I used the XenServer License Server, which is itself supplied as a virtual appliance, to easily manage the licensing process.
Self-Serve
Much of the permanent eWEEK Labs test infrastructure runs on VMware vSphere 4.1. The Citrix XenServer Self Service Manager is able to integrate with VMware vCenter. I was able to exert control over these VMs using SSM lifecycle management tools. Similarly, IT managers who already use XenCenter 5.2 will be able to immediately integrate that environment, including all existing VMs, into the SSM by simply connecting to the XenCenter server. To get a full sense of SSM, I instantiated about 15 new VMs in the XenServer 6 beta environment.
The SSM documentation is in a terse, early form. Even so, I was able to bull my way through the setup. The only problems I encountered were from inconsistent network adapter settings that I selected during my initial XenServer installation.
SSM utilizes the concepts of tenants and catalogs, along with user role-based access controls to provide VM self service provisioning. Behind the scenes, IT managers will need to do a fair amount of setup to create the neatly bundled choices that are presented to users. None of these steps is so different from other self-service provisioning systems and IT managers who already manage physical machine images will have a good idea of the overall process. As is typical of many service catalog tools, SSM has an integrated request/fulfillment workflow process.
SSM enables a multi-tenant environment, which in most cases will be departments within the same private organization. My tenants were Editorial, Marketing and Human Resources. These tenants all shared the same compute, storage and network resources but were unable to see or act on the resources of the others.
Next, I populated tenants with users who could select VMs and vApps (another new addition to XenServer 6 beta 2, which will be discussed in my final review when the product is released). I assigned users to predefined roles that ranged from the powerful Tenant Admin to the weak Guest. I was able to create users by integrating with my existing Microsoft Active Directory infrastructure or by creating local users within the SSM environment.
Besides assigning user roles that limited what they could do when logged in, I was also able to assign memory, storage, VM and network quotas to users. While this is certainly a good first step in user-resource management, I can see room for improvement. For example, at the least it would be good to see a report added to the SSM module that compared physical resources to theoretical maximums based on user quotas.
With my VMs, tenants and users in place, I created catalogs for each tenant. I was able to log in to the SSM tenant, select resources from the catalog and deploy those resources without talking to anyone in IT.
From an IT point of view, I was able to see all deployed resources from both the SSM console and the XenCenter management client. I was able to run stock resource usage reports and process resource requests for new catalog items that were submitted by users. I was also able to assign storage and compute costs to resources so that I could generate charge back or show back reports to tenants. And when the lease on a resource was about to end, the SSM handled notification emails for me by sending automated messages to the registered user. The entire process was handled in a neat manner with no visible loose ends.
