In a pre­vi­ous post, vCen­ter Inte­gra­tion Mantra, I made the point that vSphere vAd­mins wants the 3rd party mod­ules to inte­grate into the vCen­ter client and show their deli­cious addon-value there, and not in their own man­age­ment inter­face. Give the vAd­mins the info they need, where they do most, if not all their work. Open up the admin client and let us get all that juicy and fruity infor­ma­tion we need. Sounds good, right?

Yes, it does. It sounds really good, but there is this one small curve-ball that can change every­thing. The 500 pound gorilla in the room that no-one wants to talk about, but we all know is there. As a day-to-day VMware vSphere admin it’s really easy to get our blind­ers on and not see the for­est for all the trees.

Dur­ing Embotics pre­sen­ta­tion at Tech Field Day #6 in Boston, it dawned on me:

We might just be approach­ing this entirely the wrong way around.

This epiphany was caused by one sin­gle state­ment from Embotics: “Our plan is to be hyper­vi­sor agnos­tic, and sup­port other archi­tec­tures in future versions”.

Multi-hypervisor sup­port? Pro­vi­sion­ing VMs regard­less of hyper­vi­sor, just cre­ate what the busi­ness or appli­ca­tion owner needs, on the per­for­mance and stor­age tier that suits that par­tic­u­lar usage pat­tern best. Of course, this very much ties into the whole cloud mind­set, and as a con­cept of man­age­ment it is really interesting.

Con­sider the fol­low­ing scenario:

Your enter­prise has a high-performance VMware vSphere envi­ron­ment where mission-critical appli­ca­tions run. All the bells and whis­tles are avail­able in this envi­ron­ment; HA/DRS, High Per­for­mance SAN, 10GigE net­work­ing and loads of CPU and RAM.
For a given set of work­loads avail­able in the ser­vice cat­a­log, the default would be to cre­ate new mission-critical work­loads in this envi­ron­ment. Of course, charge­back mech­a­nisms would also come into play, and price work­loads in this envi­ron­ment at a pre­mium level.
For the sake of sim­plic­ity we’ll call this tier “Tier 1”

“Tier 2” would be your test/development and QA envi­ron­ment where you prob­a­bly won’t need the per­for­mance and high avail­abil­ity you get in “Tier 1”, and the charge­back mech­a­nisms would reflect this in the cost model. This envi­ron­ment runs Hyper-V, has cheaper stor­age and sim­pler networking.

“Tier 3” is your hosted envi­ron­ment, avail­able out­side of your own dat­a­cen­ters. Some work­loads belong here too, and of course, charge­back would come into play here as well. To fur­ther com­pli­cate things, the provider uses Xen for their environment.

If 3rd party appli­ca­tions where to tie into the admin­is­tra­tion tools for those three sep­a­rate hyper­vi­sors, admin­is­tra­tors would have to use three dif­fer­ent tools to man­age their environment.

What if we turn every­thing on its head, and look at it from the exact oppo­site direc­tion. Why should 3rd party ven­dors have to tie into the hyper­vi­sors man­age­ment tools? They wouldn’t have to if the hyper­vi­sor ven­dors made their admin tools avail­able in a man­ner that let 3rd party ven­dors inte­grate their man­age­ment tool into theirs instead?

Solar­winds does some­thing really inter­est­ing in their Vir­tu­al­iza­tion Man­ager prod­uct, the sta­tis­tics and sta­tus reports you get in your Solar­winds Vir­tu­al­iza­tion Man­ager dash­board are all avail­able as web “wid­gets” that you can include in other web pages. In other words, you can inte­grate Solar­winds Vir­tu­al­iza­tion Man­ager data into your exist­ing dashboards.

What if you could do the same with out­put from future VMware vSphere, Hyper-V and Cit­rix XenServer man­age­ment prod­ucts? VKer­nel could do the same for their data, and you could eas­ily cre­ate your own dash­board that con­tained infor­ma­tion from a wealth of sources.

Of course, there are a num­ber of issues with doing some­thing like this, like “what hap­pens if you want to move some­thing from Tier 2 to Tier 1, and the VMs run on dif­fer­ent hyper­vi­sors?”, “How do you enforce secu­rity between hyper­vi­sors with dif­fer­ent man­age­ment sys­tems?” and so on.

This is not some­thing that can be very eas­ily done today, and it might even be a pipe-dream, but it’s an intrigu­ing thought. I do think we will see more and more multi-hypervisor envi­ron­ments in the years to come, and get­ting into the mar­ket for man­age­ment of such envi­ron­ments seems like a good busi­ness oppor­tu­nity (Note: IANAA = I Am Not An Analyst).

Of course, this is an overly sim­pli­fied sce­nario, but it does show that the need for man­age­ment tools to be hyper­vi­sor agnos­tic is very much present, and will be even more so in the future.

We as vAd­mins need to apply pres­sure on our hyper­vi­sor ven­dors to try and make them open up their man­age­ment tools in such a way that this could be pos­si­ble some­day, the multi-hypervisor world is already here and it’s growing.

Note:
I wrote this post while on the plane return­ing from Tech Field Day #6 in Boston. Greg Ferro has replied to my orig­i­nal post with a post of his own vCen­ter Inte­gra­tion Mantra – vEv­ery­thing Is Not Wise where he pretty much says the same as I do in this post.

Tom Howarth also com­mented on the orig­i­nal post. In fact, I even voiced this opin­ion in the ses­sion we had with Embotics, when the Tech Field Day del­e­gates had a round­table dis­cus­sion after the presentations.

It all goes to show that you can in fact get blinded by the light.

Chris­t­ian Mohn