“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.