SCVMM ignores own plank, emphasizes VirtualCenter’s speck

In my ongoing probe of the newly-released System Center Virtual Machine Manager 2008 (SCVMM), I have stumbled across something that stuck me as more than just a little hypocritical. First, some background:

Microsofties have gone out of their way this year to emphasize that environments with multiple VMware VirtualCenter Servers are in great pain.  A pain that not even VMware can solve.  Yes, indeed, it is a horrible situation.  (Well, not exactly.)  In order to manage a second VirtualCenter, one must use the VI Client to actually log in to that other server.  I won’t go into great detail about how cumbersome this is, because it’s pretty technical in practice.  Well, actually, it involves double clicking an icon and selecting a host, but trust me, it is a lot more troublesome than it sounds.  Especially if you are selling a competing product.

Enter SCVMM and an amazing breakthrough.  Through revolutionary Redmond technology, SCVMM is not only able to manage VMware, it can manage multiple VMwares.  And, by the way, this feature refers to the use of the rich VMware API that has been provided by VMware for just this very purpose.

Never mind the boring details about what this management of multiple VMwares VirtualCenter Servers buys you.  Can you VMotion from one VirtualCenter to another?  Of course not.  Can you cold migrate?  No.  Can you deploy a template?  You’ve got to be kidding! Do you still need to open VI Client for many, many tasks?  Yes!

If centralized virtualization management servers that can only be deployed as autonomous systems that share no data or information are seen as a pain point from Microsoft’s perspective, you might like to see what the documentation says about SCVMM in this regard:

If your business needs dictate that you install more than one VMM server, keep the following points in mind:

• Each VMM server must be installed on a separate computer and each VMM server must use a separate VMM database. Multiple VMM servers can use the same database instance but cannot use the same database.
• Each host or library server can be managed by only one VMM server at a time.
• Multiple VMM environments are not integrated and cannot share data.
• VMM does not provide a method for replicating physical files in the VMM library or metadata for objects that are stored in the VMM database. Physical files must be replicated outside of VMM and metadata must be transferred by using scripts or other means. VMM does not support DFS Namespaces (DFSN), formerly known as Distributed File System (DFS), or DFS Replication (DFSR).

Yes, it’s true; the third bullet there says that each of your SCVMM deployments are independent systems that cannot be managed from that so-called Microsoft “single pane of glass.”  Furthermore, the library server cannot even be shared among multiple SCVMM instances.  Now that would be useful.

Looks to me like a clear case of “do as I say, not as I do.”  The saddest part is that the mainstream technical media happily regurgitates it.  Are you using SCVMM to manage your VMware infrastructure?  How is it working for you?

Administrative note:  The title of this post refers to a Biblical parable.  Google it.