April 14, 2009, 9:54 AM — Of the products we compared, CA's NSM/ASM pairing served up the best combination of VM management components. But it wasn't problem free.
NSM provides the base systems management infrastructure, while the ASM piece serves up the virtualization and cluster management wares. CA's virtualization management support for VMware's VirtualCenter/ESX and Hyper-V is only one aspect of the package used to manage large networks of systems. But for our purposes, we limited the scope of testing to the virtualization components only.
We set up NSM/ASM to run on a Windows 2003 Server R2 machine (it can also run on a Unix server) with a SQL Server 2005 server using mixed-mode authentication.
As for physical resources necessary, CA recommends 4GB of memory and at least 20GB of hard drive space in total. For CPU, minimum requirements are 2 GHz Pentium 4 or AMD Athlon XP 2000+. We then had to install NSM and ASM management and performance agents on each machine and also ASM virtual agents for it to work with Hyper-V or VirtualCenter host machines we wanted to manage.
CA recommended that we download a best practices utility which should have enabled us to install NSM and ASM together but the installer utility would not run. CA technical support walked us through a manual install that took four hours. When installing NSM, we had to select things such as Management Database, Agent Technologies, WorldView (a visual representation of your network showing all machines and devices connected to the network), Enterprise Management, Notification Services, Configuration Manager and Web Reporting options.
To get the CA combination to discover our VMware VMs, we had to use the command line to point the management system in their directions. To connect to the VirtualCenter host machine, we had to configure some text files manually for CA's distributed intelligence analysis engine, which uniformly retrieves information from all managed devices.
We did notice that NSM/ASM was a bit sporadic about rediscovering VMware VMs. For example, a cold reboot of a VMware instance was not displayed in the CA GUI. Other times, we needed to stop and start some of the NSM/ASM services on the VirtualCenter host machine in order for the NSM/ASM services to collect the data from it.
According to CA tech support, we needed to setup an SNMP trap on the VirtualCenter host machine so that NSM would rediscover VMware VMs after we'd shut them down and restarted them. But even after we set the SNMP trap, when we were checking out performance monitoring, there would be a similar problem where we had to stop the performance agent on the VirtualCenter-based machine and start it again. The use of SNMP in this case could also open up the installation to known security issues surrounding SNMP and community naming strings.
The overall VM discovery and connection process was similar for the Hyper-V VMs, except we had to apply a support patch first, and then install the Hyper-V agent.
With the arduous installation process behind us, we were able to view quite a bit of information about the virtual machines.
There were three main GUI components: the main NSM GUI called the Management Command Center from where we controlled the underlying management infrastructure; the main ASM GUI called the Systems Command Center from where we managed our VMs; and, the NSM Performance Scope GUI from where we peered into statistics collected about all managed servers.
Each uses a three-pane view (see screenshot). There was a narrow tree-hierarchy on the left side of each to allow you to dig down into the VM environment.
We were able to do all the usual VM controlling commands, such as start, stop and shutdown; suspend, clone and make template from the Systems Command Center tool. But to be clear, CA's VM management and monitoring capabilities don't extend beyond what you can do within each VM environment, and those controls vary by hypervisor (such as HyperV commands are slightly different from the VirtualCenter commands).
The one task we were not able to do inside of CA's interface was create a new VM from scratch in either the VMware or Microsoft hypervisor environments. To create a new VM, we had to either clone another VM or use an existing template.
Cloning and migrating VMs are simple processes with CA's offering. For cloning, we clicked both the VM we wanted to clone and then the cloning option. A dropdown menu allowed us to add some details about the VM including name, storage location and host (even though we had to keep the same host, because choosing another one brought on failure of the process). You complete a similar process when migrating VMware VMs, except you need to choose the host to which the VM is to be moved.
A VM Library feature that could be used to deploy subsequent images and work out some VM vetting processed -- things like production proofs -- are not yet part of the CA offering.
We found ASM's Administrative and User Roles capabilities to be quite advanced. ASM does not rely on Active Directory so we had to create our own roles and users manually. (Although, it was possible to use Active Directory with security management part of NSM.) There are two default roles provided, admin (who can do anything) and viewer (who can just look).
If you don't like the ones offered, you can roll your own roles and the options are limitless. In each instance where we built our own custom role, we were able to specify exactly what roles were permitted to carry out which VM management tasks and have access to which VMs.
The monitoring and alerting functionality requires that a specific performance agent be installed on the host machine running VMware's VirtualCenter, but there is no additional agent needed for Hyper-V. The setup is quite complicated, but once we tackled that with the help of tech support, we could monitor many performance metrics such as VM disk and memory size, reads per second and network connections per second. We could also configure how often the information is updated in the CA GUI.
We were able to setup a threshold for the percentage of CPU usage and set some actions (via a command line programming) to be taken should the threshold be exceeded for VMs running under VMware VirtualCenter and successfully triggered the alarm.
The reactive measures that can be taken should a threshold be broken include running other applications, popping up an alert, triggering a sound and sending a notation to a log.
As for Hyper-V VMs, we were able to view some performance data from Hyper-V, but not all metrics (such as CPU or RAM usage). Some of the ones we could view included network connections per second and the Hyper-V VM health summary.
Security gets more direct attention in NSM/ASM than the other products we tested, including the aforementioned definable user roles. There is also a security management component within NSM, even though it is not specifically targeted toward its virtualization management components. With NSM security management, we were able to lock down parts of NSM. There were different assets permission, asset groups and user groups available to create a secure environment. With these assets, we could control access to the NSM/ASM consoles and commands available to them.