Share via

VMware Management and SCVMM - Why does SCVMM require Virtual Center in order to integrate?

  • Article

A popular question that seems to be floating on various blogs and message boards is related to why SCVMM integrates with Virtual Infrastructure by proxying requests through Virtual Center Web Service APIs as opposed to talking directly to ESX. There are several reasons for this and I'll go through them roughly in priority order to hopefully clarify some confusion.

 1) ESX doesn't support all of the same APIs that Virtual Center does. Most notably, you can't use VMotion without going through Virtual Center and this was a key requirement from customers in doing SCVMM/VMware integration. There are other management constructs and features also exposed only through Virtual Center and in order to do a complete job of integration, we used that API route. There seems to be some debate across various blogs as to whether the APIs on ESX/Virtual Center are equivalent or not and it's a pretty cut and dry issue. This is from VMware's programming guide:

The full API doc is here , the snippet is from page 28.

 2) Most VMware customers already use Virtual Center (in part due to licensing and packaging of Virtual Infrastructure features) and don't want to re-implement everything that they have configured in Virtual Center in SCVMM. With the current architecture and design, we simply synchronize and import the information from Virtual Center so you don't need to re-run lots of configuration steps. You can literally start managing your entire VMware environment in 5 mins and we demo this for customers with their actual live environments all the time.

 3) For environments that already use Virtual Center, SCVMM effectively becomes a "manager of managers" which is an appealing and low-risk way of introducing SCVMM in the eyes of many customers. You don't need to rip out and replace your existing Virtual Center instances to begin using SCVMM (but of course, you will only be able to manage the VMware environment with Virtual Center whereas SCVMM manages ESX, Hyper-V, Virtual Server and eventually Xen). SCVMM can even let you manage multiple Virtual Center instances through our console, something VMware currently does not offer. Since we synchronize with Virtual Center instances bi-directionally, this means that any action you take on the VMware environment through SCVMM is automatically reflected in the Virtual Center UI and vice versa. Plus, we do all of this without installing additional software/agents on the VMware boxes. Our goal of course is to show you that you'll want to live in our console since it provides a more complete picture for mixed environments in addition to the value-add management capabilities.

4) Technically speaking, we have a dependency on the Virtual Center web service, not the console but you'll still need to use the Virtual Center console to on-board new ESX servers and a handful of other tasks. Again, our goal from a management perspective is to allow you to live in one console day to day and automate using one PowerShell interface across hypervisors. With that said, just as you occasionally need to access Windows features directly on the Hyper-V box (MMC snap-ins, storage configuration, bare metal configuration etc.), the same holds true of ESX.

Hopefully this helps clarify things.

Rakesh

Comments