- Top 10 Recession-Proof IT Jobs
- 7 Hot IT Jobs That Will Land You a Higher Salary
- Link Building Strategies and Tips for 2014
- Top 10 Accessories for Your iPad Air
Network World - The final version of SC VMM – which began shipping in November – is much improved over the beta code we tested last fall, but it has still got some rough patches in terms of integration with Microsoft's Operations Manager (needed for monitoring and trending) and as supporting non-Windows VMs goes.
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 screenshot.)
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.
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.
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.