April 14, 2009, 10:58 AM — DynamicOps describes its Virtual Resource Management (VRM) tool as a "unified approach to managing both server and desktop virtualization" regardless of the hypervisor platform.
But we found that VRM is more of a provisioning tool for deploying and controlling access to virtual machines, and is less effective when it comes to the subsequent management of the successfully installed VMs. (See screenshot.)
Also, not all hypervisors are equal in terms of VRM's ability to control and manipulate VMs running on top of them. VMware-based VMs are definitely more malleable under VRM's control than instances running atop Hyper-V and XenServer.
Generally, there were more manual steps to use the DynamicOps tools to control non VMware-grounded VMs.
DynamicOps VRM (we mainly tested Version 3.1.0 except for when the company supplied 3.1.1 to address issues we had with Windows 2008 Server support of Windows Imaging Format [WIM] imaging needed to support Hyper-V) must be installed on a 32-bit version of Windows Server 2003 R2. We were able to install it inside an appropriate Windows 2003R2 virtual machine without issue. The program needs access to at least two CPUs, 2GB of RAM and 40GB of disk space.
It also needs a database. We tested it with SQL Server Express 2005, but it also works with SQL Server 2005. Microsoft .Net 3.5 and Microsoft IIS 6.0 with ASP.NET are also required.
The supported virtual environments are XenServer 5 or later, VMware ESX 2.5 or later with VirtualCenter 2 or later included and Hyper-V 1.0. It was necessary to install proxy agents for each kind of virtual environment that we had deployed in the test bed.
Starting up
The default installation was not complicated. Configuring the product did require a careful reading of the manual. But the upgrade to Version 3.1.1 was an error-ridden process. For example, some user-based data did not correctly transfer during the upgrade. We had to add those manually to the database. A DynamicOps spokesperson said these database problems we incurred ought to be fixed by the time you read this.
In our initial test with VMware ESX, we had to enter information for many different configuration settings such as blueprints, provisioning groups, cost profiles and VM machine name prefixes before we were able to add our VirtualCenter information and import our guests into the VRM console. Then, we were able to start and stop the machines that were imported by using the VRM Infrastructure Organizer tool
When we tested VRM with XenServer, we had to add XenServer information manually, first adding the host in the hosts category, then creating a reservation to make sure there is enough storage and CPU, then assigning the reservation to the host. After that, we could finally add a VM by entering in the details about each VM.
This process could become very tedious if you had many Xen-based VMs. A rudimentary discovery process in the application would grease this application mightily. DynamicOps representatives said the Infrastructure Organizer should be able to handle XenServer and Hyper-V environments in the next major release (3.2) of VRM.
Creating virtual machines from scratch from within the VRM infrastructure is not possible. It's only possible to copy an existing blueprint, which are forms we filled in with various desired settings after which we could provision VMs. The requested VMs were created in the same storage location that was set in the reservation.
We had some virtual machines on local storage and some on shared storage. When the blueprints were used to create a new VM, that VM was created in the same location (either local or shared folders). We were able to set parameters within the blueprint regarding whether the VM needed to permission to clone itself. And depending on the user group that we had defined, our user role allowed us to get specific blueprints, where we were allowed to get them. Then a group leader (or VRM administrator) had to approve our request to provision a new VM. The approval process is a good security measure that we did not see in other products.
The blueprint process gives fine control for replicating VM templates, but is a tedious process. You can create blueprints for all kinds of VMs on all hypervisor platforms. But creating blueprints requires carefully going through the documentation to make sure each setting was correct for the desired VM on the desired platform. Generally the data entered in our test was similar but some fields were required for VMware that weren't required for others. So when we wanted to create a blueprint for Windows 2008 Server, we needed to create three blueprints -- one for each environment.
Setting up the blueprint to clone a VM was pretty difficult because the documentation was not clear and every setting had to be entered manually. VMware VirtualCenter has specific clone-time attributes needed to be set within the blueprint. For example, the setting "VMware.VirtualCenter.OperatingSystem" was the one that gave us the most trouble. If DynamicOps had this information in the docs or a link to a list of values that go here, the process would been simpler.
Of course, DynamicOps recommends using WIM for all cloning purposes. WIM is a file-based disk image format that can be used to deploy Windows-based machines or in this case virtual machines. But this way of cloning only works with Windows based VMs and it does not work with Windows 2008 x64 at this moment. We could only import Linux VMs or clone them via the VMware clone method.
DynamicOps implementation of WIM Imaging was error-prone and the documentation was unclear, quirky and sometimes wrong on how to properly use the product. For example, when creating the WIM image for Windows 2008, which should be a relatively simple process, we had to create an unattend.xml file to be read by Sysprep (a Microsoft command that prepares a system for virtualization from physical to virtual conversion) to configure certain items like license keys and admin passwords. The manual also described a number of laborious WIM imaging choices, which could have easily been re-made into templates.
Seeing as you can create both Windows and Linux VM clones using VirtualCenter alone, we don't see the benefit of jumping through the WIM Imaging hoops.
When we created provisioning groups -- where you establish which users play which roles and belong to which groups -- we also set up resources for each group.
You can import your existing virtual machines from VMware only. Really, VRM seems to be mostly for setting up your environment. Even when we imported the machines, we couldn't copy them or really do anything with them. We still had to create separate templates, blueprints, WIM images and other setup related duties in order to do anything. Linux support is almost non-existent except for VirtualCenter cloning, while other operating systems are completely left out. There is no moving or migrating VM functionality at all.
Operational management
User administrative roles are highly evolved. There are four basic roles for each provisioning group: administrator, user, group manager and support personnel roles. VRM uses Active Directory for users' credential for authentication and authorization purposes so that users can get appropriate access to the VRM Web console. Each user role allows those users to undertake certain administratively defined roles. The enterprise administrator for VRM can assign users to each role.
VM instance control was comparatively weak across platforms. The only commands available to use with the VM are start and stop via the VRM Web console. And stop doesn't seem to shutdown the machine completely, it just turns it off, like pushing the power button when something is running, Other management applications tested know how to trigger an orderly guest shutdown.
Also, if you don't use the VRM interface to turn on or turn off the virtual machines, it doesn't seem to recognize any state change. Other options like changing the memory, amount of allocated CPUs or other setup options for VM guests are not available and must be done within the native management environment. Although, there is a connect-via-RDP option available, we were unable to get this process to work properly.
VRM lacks alarms and event triggers, but there were logs and reports we could view. The views included capacity usage, inventory, top 10 resources, VM status and audit logs. We could filter by different criteria such as host, user and machine name. Some of the views included nice graphs which were useful to get a quick idea about what is going on.
Besides strong user roles and tying those to Active Directory, there was not anything in particular that made the virtualized environments more or less secure using VRM.
