By Mike Laverick, Author, Instructor and Blogger
VMware’s master plan is starting to bear fruit.
When VMware introduced Virtual Infrastructure 3 (VI3), the company started to allow third parties to introduce their own plug-ins to the client. Initially, what we saw were folks in the VMware community building their own plug-ins to extend the functionality of the VI3 Client.
Perhaps the most well known was Andrew Kutz’s plug-in that added a GUI front-end to Storage vMotion before VMware developed its own. VMware also got in on the act, using the plug-in architecture to add functionality to the base vCenter install with VMware Update Manager and VMware Site Recovery Manager.
Now VMware’s partners — especially the OEMs and the storage vendors — are getting in on the act. When VMware first unveiled this plug-in approach, it seemed clear to me that the company was trying to build a core management platform (vCenter), whilst allowing others to extend its functionality. It was my prediction that VMware wanted vCenter to become the main management tool from where most system administrators would do their work. If successful, vCenter might even usurp vendor-specific management tools — especially if you can do 90% of your daily administration tasks more efficiently with a plug-in.
Dell Management Plug-in for vCenter
The Dell Management Plug-in allows you to control the day-to-day management of Dell PowerEdge servers directly from vCenter. The plug-in adds a whole new series of Dell-focused alarms and alerts to the standard ones provided by VMware. And it enhances the standard monitoring of a physical host with views of the hardware, storage, warranty status and firmware.
Previously you might have used a special utility or management system from Dell to carry out firmware updates, but now these can be triggered directly from the vCenter plug-in. The Dell MPV also offers links to the Dell Remote Access Card (DRAC) interface and the OpenManage Server Administrator system, and it enables a way of deploying ESX hosts to brand-new hardware directly from inside vCenter.
Interestingly, rather than using PXE boot to transfer the install, the MPV communicates directly with DRAC on the Dell server. Even more useful are its abilities to configure the local RAID controller and join the installed ESX host to vCenter, with the option to apply a VMware host profile.
I think Dell’s approach gives a good steer on how all OEMs are going to focus on VMware as the primary management platform in the datacenter and integrate more closely with vCenter then they have ever dared to before. It’s recognition that VMware is the de facto hypervisor in the corporate space, and none of the vendors feel the need to swim against the prevailing tide.
VCenter plug-ins from storage vendors
On the storage side of the fence, all three of the big vendors — Dell, EMC and NetApp — have been busily developing new plug-ins, vying to be the one that most closely integrates with VMware. This competition will ultimately benefit all VMware admins, regardless of which storage vendor they happen to use. (I doubt very much whether the decision to go with one storage vendor over another rests so heavily on how well they integrate with VMware. Prices and existing relationships seem to have a greater an influence.)
I love what these storage vendors are doing. They are all offering very similar functionality with their plug-ins, and they are all capable of efficiently carving up storage from the disks that make up the array. Additionally, these storage plug-ins can also provision new virtual desktops and enhance the views of your storage within vCenter. They save you massive amounts of time and greatly simplify the process of providing new storage to your ESX hosts.
In fact, where once I prided myself on the ability to navigate around EMC Unisphere, NetApp System Builder and Dell EqualLogic Group Manager, I’m now seriously considering doing all main storage tasks via the vendors’ respective vCenter plug-ins. It’s so much quicker, and you’re less prone to make mistakes. (I don’t know about you, but really I’m more of server guy than a storage guy, so I don’t get to practice my storage skills as much as I should. So I will admit I’m the first to make errors in my administration at the storage layer. Anything that reduces my capacity to screw up on that front is heartily welcomed.)
VCenter plug-ins in the cloud
The other big deal about these storage plug-ins is their potential effect on cloud computing. Right now the “cloud administrator” has to work with the storage layer, slicing it up into various tiers and presenting it to the end user. This method is quite crude; it is very easy to provide more storage than is strictly necessary, and the creator-owner of the VMs in the cloud has little control over the placing of the virtual disks.
But imagine a situation where end users could create volumes/LUNs independently from a central storage pool, using vCenter plug-ins. If they create VMs for a project, they could create their own storage as they needed it. When they were done with their VMs, they would delete the VMs and their associated volumes/LUNs, handing that free space back to the storage pool.
Of course, this vision is rather grand. (The cloud has the tendency to make all those who consider it become starry-eyed.) But there are some obvious barriers. In the large corporate space, my customers who are VMware admins have said they love the idea of these storage plug-ins, but the sad reality at the moment is their storage teams wouldn’t let them use them; perhaps the storage teams fear that their importance to the whole of corporate IT would be diminished if VMware admins could provision their own storage.
Looking deeper into the issue, you recognize that that this self-provisioning model undermines years of careful, centralized storage management. The job of the storage guy is to make sure performance is great and that storage space is not wasted. If the storage team hands over the reins to the VMware admin, you could argue that not only would you have VM sprawl on your hands, but volume/LUN sprawl to boot. It seems we want two things that are in constant conflict with each other: We want self-service, demand-driven resource allocation, but we want to be control freaks, too. I’m wondering if there maybe more benefits if we learn to lose control.