SC VMM now conveniently manages VMware's ESX-based VMs, but that support requires that VMware's own VirtualCenter management application (which VMware charges for) already be in place to perform much of the actual work when managing ESX VMs. This condition exists for other products tested as well.
Hosting SC VMM requires hardware resources that depend on how many hosts you plan to install. Each machine that runs the SC VMM management console needs at least a 2GHz x64 processor, 2GB of memory and 10GB of hard disk space. (See a .)
Windows 2008 Server is required as well. You also need to deploy (on a separate machine if you like) Microsoft Operations Manager (MOM) 2007, a prerequisite for the Performance and Resource Optimization (PRO) tips tool that handles monitoring, alerting and trending tasks. The list of other required Microsoft piece parts includes Windows PowerShell 1.0+, Windows Remote Management, WAIK 1.1 and IIS 7.0.
Starting up
Using SC VMM to initially make a VM image instance wasn't easy or intuitive.
When we tried to make a new VM on the VMware ESX using SC VMM we wanted to use dynamic disk VMs, but we could only select fixed-sized disks.
Using its GUI, we tried to add standard ISO images of operating systems that would serve as image sources in our SC VMM image library. But it's not obvious how to do this, so we simply manually copied and moved images into the required folder.
We wanted to use an ISO image to initially install a guest VM onto Hyper-V. We setup the guest and chose Novell's SLES 10.2 (64-bit) as the operating system to run on the Hyper-V host. We chose the ISO image we had manually added to the library. We didn't want to copy the ISO image so we chose: 'Share image file instead of copying it'. But when we did that we got an inarticulate error message, telling us in a roundabout way that the machine requesting the image did not have proper access rights. Eventually, the problems were solved with a change in file/folder permissions. But it was no mean feat to get the Library function to work.
Moving things around
When we initially attempted to migrate VMs between Hyper-V hosts we got an error message advising us of processor incompatibility issues. The only way to perform a cross-CPU migration with SC-VMM is to shut the VM down, copy the image file, then restart it elsewhere. Why would you want to use this function in a shutdown VM, when this action is no different than taking a snapshot and reloading it as a VM? This means additional downtime is required to complete a very simple and ostensibly common act of migration.
It would have been nice to move or copy an ESX VM to Hyper-V or vice versa, but that option is not offered here. (None of the other management tools can do this either, though.) We were able to clone ESX VMs onto the same VMware host and complete an ESX VM to ESX VM migration with local storage or an NFS share.
Using VMware's live VM migration utility, VMotion, migrations of live VMware ESX to ESX VM guests under SC-VMM's control worked quite well.
Whether the VMware VMs used Linux or Windows, the VMs were able to successfully migrate, although after a migration we found the VM was slow to connect to the viewer subsequently (and we had to close the VM viewer session and open a new one because it was on a different server).
SC-VMM's Operational Management
The first step toward achieving any form of daily operational management is being able to actually see the various VM platforms on the network. Under SC-VMM, getting to 'watch' the various VM hypervisor screens was possible, but the quality was not great.
The SC VMM VM viewer uses a separate window from the main GUI (a plug-in is required to see VMware VMs). Unfortunately, the options available from within the viewer itself are limited. You can reconnect to host, send ctrl-alt-delete commands, and use all of the real estate of the monitor. There are no start/stop, shutdown or pause buttons available from the viewer.
Every time we clicked inside to give focus to the viewer while installing a VM, it would pop up with the message, "You can't control the mouse while running a remote session without virtual tools installed." This was very annoying because when we installed a SLES VM onto a Hyper-V server, we couldn't even use the mouse, and still had trouble using the VM afterwards trying to install the Hyper-V Linux components.
While working with ESX machines, we could not turn off the ESX machines remotely, as is possible with ESX Infrastructure Client (like shutdown, reboot or enter maintenance mode for the physical machine). Secondly, we were not able to use templates created in ESX within the SC VMM interface. Therefore, it is still necessary to use VMware's client for certain tasks, and we wondered why we would use SC VMM when we had to reference VMware's utilities anyway.
Besides the primary SC VMM administrator role, there are two other roles -- a delegated administrative role, and a self-service user role. The user and group management scheme uses existing Active Directory roles, so there is no need to create new ones. We just assign those users VM management duties from within the SC VMM GUI. We were also able to restrict the actions users could perform on the VM using self-service users role establishment. The available actions are start, stop, checkpoint (similar to the snapshot feature with other tools), remote desktop control, pause/resume, shutdown and remove.
You can place deeper restrictions on VMs if you tap into the concept of Host groups. This allows users to create new virtual machines, setting a quota of how many VMs can be created or if users can store the VMs in the Library.
As an example, we created a self-service user role that was restricted to Start and Stop privileges only on our Hyper-V hosts.Then we added some users to this role. Those users could not interact with the ESX servers at all, were only able to start or stop Hyper-V VMs and could not create new VMs.
As for the delegated admin role, it is quite similar to the full administrator role except that we could specify a certain Library or Host group for them to administer.
SC VMM Incident Management
We had trouble configuring PRO tips. Integrating it with MOM and SC VMM was unreasonably difficult. We were able to get PRO tips working on a per-host basis and were eventually able to get VMs to report errors on a per VM basis, but only for Windows VMs, not for Linux ones.
The alarms take quite a while to show up also in the management interface. According to a Microsoft tech person, PRO tips works by gathering data over a period of time. Therefore the updating process could take six hours to a couple days. A real-time monitoring system for alarm conditions, this is not.
Instead, PRO tips works as a reasonable heuristics system for monitoring VM conditions and making recommendations as how to proceed based on criteria we set. We can't recommend it for larger installations, and certainly not for those installations that have non-Windows VM guests.
In order for PRO tips to pull data from specific VMs and their host platforms, you have to install the appropriate agent software. These agents are only available for Windows environments. We had to install agents on each Hyper-V host and each individual VM. For the ESX platform, we installed an agent on ESX Windows VMs. Microsoft does not yet offer PRO tips agent software for Linux-based VMs.
The reports are useful, but only for trend analysis and audit purposes, as data discovery isn't really trigger-based, but rather, trend-based. For those looking for trend analysis, the PRO tips reports were the best of the products tested this round.
Security management
There doesn't seem to be anything inherent in SC VMM that makes it more secure other than the role-based management capabilities outlined above. In reality, SC VMM uses whatever security policies that are setup in the Windows Active Directory domain.