A few weeks ago I wrote about Horizon Suite and about how Horizon Mirage comes with a license to use VMware Fusion Pro to address BYOC situations. In that article I lamented the fact that Fusion Pro was a Mac solution. Someone from VMware reached out to us and mentioned that VMware Player also comes with Fusion Pro, and because of that is licensed for commercial use, which it wasn't before. (Tell that to the companies using it!) What we didn't get out of that, though, is that it also comes with added functionality.
Fusion Pro is interesting because it adds management capabilities to Fusion that make it more enterprise-ready. There's no central management console, but it does expand the feature set to include the ability to create and run restricted VMs, limit access to USB devices, and create custom networks. Restricted VMs are ones that are pre-configured with settings that cannot be altered by end users, like drag and drop transfers between the host and guest.
VMware Player's inclusion with Fusion Pro seems somewhat insignificant at first, but it actually has the ability to run the same restricted VMs as Fusion Pro. Ultimately that means that VMware Mirage can be used to support not only Mac, but Windows and Linux BYOC scenarios. (Although, I dare you to find me a Linux BYOC scenario from a normal user...) This is the message VMware was trying to get across that we missed, and it seems like a fair solution that makes use of the products currently available.
Prior to this revelation (which most people probably already knew since it came out around VMworld), I kept thinking about the possibility of a Workstation Pro. While the additional functionality of VMware Player scratches my BYOC-for-Mirage itch, I'm still left thinking about the possibilities. Fusion Pro adds some nice features, but it really only brings it closer to the functionality that's also in Workstation (which also supports restricted VMs). What would be cool is centralized management across the board.
In a BYOC environment, IT accepts the fact that they cannot control the host. They can, however, control the VM and, to some extent, the hypervisor. Today that control is exhibited by deploying the aforementioned restricted VMs, leaving the hypervisor alone. What I'd like to see across the board is a management system that not only controls what a VM can and cannot do from a central location, but also the hypervisor itself since it is the BYOC enabler. It's like PC management, but in this case the hardware is virtual. If IT has the ability to maintain the VM settings, hypervisor configuration, and the restricted OS inside, then that makes for a better-managed BYOC situation.
Think of it a bit like MDM or MAM on mobile devices. With those technologies, IT can deploy apps and configuration settings to devices that they don't own, while ensuring certain settings are in place to strike a good balance between management and end user flexibility. I'm not suggesting that the hypervisor have any management hooks into the host OS, just that the hypervisor can keep an eye on what's happening and react according to IT policies. For instance, if a virus is detected on the host, disable access to the VM until it's fixed. Or, new network or hardware settings could be centrally created and delivered. Plus, IT would have the ability to grant access to VMs, or to revoke that access when a user leaves the company or loses the laptop.
This isn't new thinking of course. It's the client hypervisor mindset that a few companies are already on board with. Citrix has XenClient, Mokafive has, well, Mokafive, and Virtual Bridges has VERDE LEAF. At one time VMware was on that path, trying to create a Type-1 client hypervisor from the ground up (remember CVP?). Now those lines have blurred, and we don't really care so much whether a client hypervisor is Type-1 or Type-2. I'm not saying that it's something that should be used enterprise-wide, but if supporting BYOC is the goal, VMware already has the technologies in place to deliver the entire stack—they just have to be tied together. Mirage is the first step in that, and bringing it down a level to the hypervisor could be Step 2.