(Page 2 of 3)
VMware's client hypervisor: What's the big deal?
There will be commentators who will pooh-pooh all these enhancements, and some observers have linked the delays associated with View 4.5 to perceived delays in VMware's client hypervisor -- even though they are quite separate development projects within VMware.
I raised this speculation over the status of the VMware client hypervisor on the Office of the CTO VMware blog. Here's an excerpt of what Scott Davis, product manager of VMware's desktop team, said:
Type 1 client hypervisors are interesting technologies which we continue to experiment with in our labs. However, they don't on their own provide the device choice, integrated management or composite desktop opex [operating expenditure] benefits our customers seek. -- Read Davis' full response.
Although VMware is continuing to develop and test the client hypervisor in its labs, the company isn't convinced that there is market demand for it. Personally, I'm skeptical about the brouhaha surrounding both local mode and the client hypervisor. I just don't see what the big deal is -- I don't have hundreds of customers bemoaning the absence of a VMware client hypervisor or who are even remotely inspired by the local mode concept.
Any virtual desktop running on the local machine will need a physical machine with the right amount of RAM and CPU to make it viable. So, if a virtual desktop with Windows 7 has 4 GB of RAM and 2vCPUs, then it will run fine on eight-way hosts with 72 GB of RAM. However, on a laptop with just 2 GB of RAM, it simply won't run.
The heart of a virtual desktop infrastructure (VDI) is getting the desktop off the local client device and into a centralized, highly secure and high-bandwidth environment.
But since there are so many ways to stay connected on the road, why is local execution a big deal? Well, for example, I'm writing this article on my MacBook Pro from a London Heathrow departure lounge. The Wi-Fi is a rip-off so I'm writing this offline, and I will post it when I arrive in San Francisco. So while narrow, there is definitely a need for local applications.
The development of ThinApp
The integration between View and ThinApp is another major development from VMware.
ThinApp has lacked any real deployment process -- unless your idea of deployment is using .MSI and Microsoft Group Policy Object software policies to push out applications. View 4.5 supports a publishing process in which ThinApps are uploaded to a centralized repository of applications and allocated to the right desktops.
But this deployment process is limited solely to ThinApp and View. What if you need to push out a ThinApp to a conventional desktop PC?
ThinApp's claim to fame is that all applications are self-contained .EXEs that execute in their own runtime. There is no agent or client-side software to install and maintain. While powerfully attractive, this method has its downsides. The lack of an agent limits ThinApps to deployment processes known to the guest operating system, namely Microsoft Windows. Of course, some users will balk at having to install an agent-based receiver to their desktops in the same way they hesitate to install backup agents to their VMs.
The self-contained ThinApp is ultraportable and ultracompatible, but it lacks some of the management capabilities of agent-based systems like Microsoft's App-V. Certain advanced settings and options in ThinApp remain in Windows 3-style .INI files. This could be improved by giving ThinApp administrators something more than a text editor and a build script -- something along the lines of a real project management tool that would hold all ThinApps in a single view, and expose these advanced settings to a graphical user interface environment. With an optional agent, VMware could then allow the ThinApp administrator to push out applications on an Active Directory-user or group membership basis that would be independent of View.
ThinApp underwent many changes. It now supports virtualizing Internet Explorer 6 on Windows 7 and Windows Server 2008 R2. This is something that Microsoft App-V doesn't support.
Furthermore, VMware also introduced ThinDirect, a feature that allows for the redirect of specified URLs to a local browser. So when a user clicks a hyperlink, the right Web browser opens relative to the page. In addition, AppLink has been enhanced to allow interoperability between ThinApp 4.6 and older versions. And finally, ThinApp Convertor allows for the bulk conversion of multiple .MSI files into ThinApps ready for use by VMs.
ABOUT THE AUTHOR:
Mike Laverick is a professional instructor with 15 years of experience in technologies such as Novell, Windows and Citrix. He has also been involved with the VMware community since 2003. Laverick is a VMware forum moderator and member of the London VMware User Group Steering Committee. In addition to teaching, Laverick is the owner and author of the virtualization website and blog RTFM Education, where he publishes free guides and utilities aimed at VMware ESX/VirtualCenter users. In 2009, Laverick received the VMware vExpert award and helped found the Irish and Scottish user groups. Laverick has had books published on VMware Virtual Infrastructure 3, VMware vSphere4 and VMware Site Recovery Manager.