Disclaimer: This article was written using VMware vSphere 4.1. This is a very new version of VMware's flagship platform, and as such might not yet be fully supported by Microsoft. My experience
must be seen in that light.
Right from the beginning, there's something you should know about managing VMware virtual machine using Microsoft System Center Virtual Machine Manager (SCVMM). The level of functionality is that of VMware Virtual Infrastructure 3 (VI3) -- not the current vSphere 4 product.
As Microsoft states on its download page, SCVMM 2008 R2 offers:
"Support for VMware vSphere 4 (VMware VI3 feature parity only)"
In other words, even if you have the latest greatest version of VMware, the level of support for managing it brings you right back to the same functionality of the previous system it replaced more than a year ago.
The other important requirement is that your VMware environment must be using vCenter. This is because SCVMM communicates to the ESX hosts via VMware's management system to allow access to the VMs. So don't imagine you can use SCVMM as a way of saving money just by having VMware's ESX hypervisor while forgoing the license fees associated with acquiring vCenter.
With that in mind, you might wonder why you would want to manage VMware with a Microsoft management tool to begin with. Well, there are a couple of reasons:
- You might be supporting a multi-vendor virtualization environment and want the ability to carry out core management tasks from a single management system. Currently, VMware's vCenter only recognizes its own virtualization platform of ESX, and there is no support for managing Citrix XenServer or Microsoft Hyper-V with it.
- You are in the process of migrating from one virtualization platform to another and looking for a way of managing your legacy VI3 environment.
- You are attracted to the way Microsoft management tools integrate into Windows and the applications you're supporting, like Exchange Server or SharePoint.
Bringing VMware to SCVMM
Adding the vCenter server into System Center Virtual Machine Manager is a simple process. Over in the far right-hand corner of the SCVMM management console is a link called Add VMware VirtualCenter, which brings up the following dialog box:
The important thing to note are the two links at the bottom of this page that say "What restrictions apply?" and "How do I enable full management?" Depending on how you import vCenter, this will affect the level of management you're capable of carrying out.
After the import process you will see either OK (Limited) or OK next to the names of the ESX hosts. An administrator sees the OK (Limited) status if the Secure Mode is set to off. The table below indicates which features are available in the two modes:
Table 1. Supported VM actions for ESX server hosts by host status
|Virtual Machine Action||OK (Limited Status)||OK Status|
|Discard saved state||No||Yes|
|Modify properties||Yes (restricted)||Yes|
|Migrate by using VMware VMotion||Yes||Yes|
|Migrate across VirtualCenter Server||Yes||Yes|
|Store in VMM library||No||Yes|
|Clone within the same VirtualCenter||Yes (restricted)||Yes (restricted)|
|Clone on the same ESX Server host||Yes (restricted)||Yes|
|Convert virtual machine (V2V conversion)||No||Yes|
|Create virtual machine from a VMM template||No||Yes|
|Create virtual machine from a blank VMware virtual hard disk (.vmdk file)||Yes (restricted)||Yes|
Note: I've been using VMware virtualization technologies since 2003. I have no idea what Microsoft means by "Migrate across VirtualCenter Server". Technically, VMware has never supported the move of a VM from one vCenter to another. Ever. It transpires that this might be a typo. Microsoft can indeed migrate VMs from one vCenter to another -- but only by first copying the VM into its own internal "library" and then copying into the vCenter.
Getting the fully-secured mode to gain access to all the features under OK status requires more than merely accepting a certificate from the ESX hosts. The Microsoft Knowledge Base article 145051 outlines in detail the requirements for secure mode. Fear not, I will tell you all about this in the following paragraphs.
For all the features to work, SCVMM must speak to the ESX hosts directly, and as such, authenticate to them. In the world of VMware, the administrator account is called "root" as it would be in Unix or Linux. Now it is possible to use an account with lower-level privileges, though this is not supported in some editions of ESX. The bottom line is this -- to allow the fully-secure mode that enables all the possible features, the only supported method from Microsoft is to use the "root" account. Many corporate environments might baulk at the thought of exposing this account to a third-party system. The Microsoft KB article seems to go back and forth on the issue – at one point indicating that you could use a "virtual machine delegate" account, but later stating very clearly:
"IMPORTANT: In VI3 environments, using a virtual machine delegate is considered experimental by VMware. In VMware vSphere 4, ESX and ESXi do not support delegate user functionality. Your only option is to use root credentials."
You will see this Limited (OK) status after first adding vCenter to SCVMM for the first time.
Once the ESX hosts have been added, you can right-click each one and choose Configure Security in the menu to set the additional security options. This dialog allows you to provide the root account password for the ESX host in question, use the Retrieve button to query the host for its Certificate Thumbprint and Public Key fingerprint, and click the option to accept them. The process can be sped up by giving the ESX host a trusted certificate, but this in itself is a time consuming process that most VMware shops wouldn't undertake.
Note: In the case of vSphere 4.1. I found you must go through this dialog box, otherwise the Job Status would be marked as "Failed". I imagine that Microsoft will issue an update to correct this shortly. Additionally, after completing this dialog box, one or two of my ESX hosts reported failures to SCVMM; a right-click and refresh fixed this issue.
The other important part of using SCVMM to manage ESX hosts is the effect on the vCenter server. Once SCVMM is configured to communicate to vCenter it effectively "owns" the ESX hosts, so when it connects to the vCenter it will disconnect all vSphere client connections. So by embarking down this road you are to a great degree saying goodbye to managing ESX by vCenter. This is not a permanent situation; if a vSphere Client connects to vCenter, it then disconnects the SCVMM connection.
Note: This dialog box appears if a vSphere client connects.
Note: This dialog box appears to the vSphere client if you force SCVMM to reconnect to the vCenter server.
The only other thing you might want to install and configure is an ActiveX control to your Web browser. This will allow you to open a window on a virtual machine using the APIs that drive VMware's Remote Console functionality.
I must admit this aspect of the configuration defeated me. I followed all the guidelines to try and get the ActiveX control to load and install -- but failed miserably. I even tried cranking up the vCenter Web service and installing the software to make the Remote Console work. While this did work for the VMware Web service, SCVMM did not recognize that installation, and at the time of my evaluation I was unable to connect to any of my virtual machines using SCVMM.
I think this is mostly because the latest version of vSphere 4.1 has done away with the old ActiveX control and now installs a Remote Console application that looks and feels like VMware's Player system. You may have better luck than me in your environment, especially if you're running on VI3.
After that I decided to use Microsoft's supported list of actions and go through each and every one. After all, saying you can do something is one thing, but actually doing it is quite another in my book. I won't bore you with the tedious details, but instead draw your attention to the odd anomalies:
- You can edit the settings of a VMware virtual machine from SCVMM, but I wasn't able to take advantage of some advanced functionality like the hot-add of memory, CPU, disk or network interfaces. I take this to be expected behavior as the Microsoft table indicates that modifying some settings are "restricted."
- SCVMM failed to indicate what operating system type was in use inside the virtual machine.
- I was able to move the virtual machine with VMotion, although SCVMM did come up with strange messages. All my VMs were already in a VMware HA/DRS cluster, but when I went to move a VM, an odd dialog box would come up:
- Additionally, I found the VMotions triggered by SCVMM to be somewhat unreliable. It was hard to tell if this was a Microsoft issue or a VMware one, but given that I was able to carry out a VMotion from vCenter without an error, I suspect SCVMM isn't yet compatible with vSphere 4.1. Occasionally, SCVMM indicated my ESX hosts were "unsuitable" for VMotion, which was very odd since all the ESX hosts were identical.
- When cloning a virtual machine, I found that SCVMM couldn't enumerate my Distributed vSwitches port groups. I did have some Standard vSwitch port groups, but they didn't appear either. Additionally, I wasn't able to select which resource pool the VM resided in.
- Converting a VMware virtual machine to a Microsoft virtual machine worked, but oddly not all of my VMs appeared in the list for conversion. This was despite them all being Windows Server 2008, Windows 7 and Windows XP virtual machines.
I started this article by discussing the merits of using one vendor's management system to control the platform belonging to another. After my experiences, however, I think I will restate something I've believed for some time. You see, when VMware first came up on my horizon, there were other third-party tools you could adopt to manage virtual machines. This was especially true back in the ESX 2.x.x days when most VMware shops didn't have vCenter. This was long before vCenter more or less became a mandatory component to gain access to features like VMware VMotion, High Availability (HA), Distributed Resource Scheduler (DRS), Distributed Power Management (DPM) and Fault Tolerance (FT).
Back then there were tools like Hewlett-Packard's Virtual Machine Manager, which was plugged into its System Insight Tools. Similar to the SCVMM support for VMware, it wasn't bad, but if you wanted to get down and dirty and do some real administration it just didn't cut the mustard. Even the awful ESX 2.x.x Management User Interface (MUI) driven through webpages was preferable to these third-party tools.
And that is my general point: When one vendor decides it can manage another vendor's platform, they invariably don't do as good as job of it as they could. Why? Well essentially the driver to do it isn't to create an uber-admin tool that acts as your main management solution. Instead, these features are nearly always offered in order to allow customers to manage legacy environments. They never do the same job as the original vendor's system, and why should they? After all, the vendors' priority is to manage their own platforms as efficiently as possible.
I've often wondered if VMware itself would benefit from something like the old style Hyena or DameWare tools. If you are as old and Jurassic as me, you might remember that back in the Windows NT 4.0 days, Microsoft management tools like User Manager didn't really come up to scratch. Often companies would invest in third-party tools like Hyena and DameWare that allowed more sophisticated options.
While vSphere and its client are generally very good, they usually fail in the area of bulk administration tasks -- and they have failed at this for some time. In part this has driven the adoption of Windows PowerShell and PowerCLI in the absence of suitable clients to do these repetitive tasks simply.
Sadly, it seems unlikely that any third-party will enter this market at such a late stage, and in the foreseeable future it seems that using a vendor's own management tools to do serious administration is the way to go. Still, in my book that doesn't totally block the usage of Microsoft System Center as a monitoring tool for keeping a check on your ESX hosts or the VMs that are running upon them.
ABOUT THE EXPERT
Mike Laverick (VCP) is an award-winning expert and author who has been involved with the VMware community since 2003. He is a VMware forum moderator and member of the London VMware User Group Steering Committee. Laverick is the owner and author of the virtualization website and blog RTFM Education, where he publishes free guides and utilities aimed at VMware ESX/VirtualCenter users.
This was first published in August 2010