Konstantin Emelyanov - Fotolia

Get started Bring yourself up to speed with our introductory content.

What VMware needs to do to convert the vSphere Web Client haters

Security and speed issues dog the vSphere Web Client, but will VMware listen to its users?

VMware's ESXi 6.0 is almost upon us. The VMworld 2014 launch will most likely see the controversial vSphere Web Client become mandatory. Unless the 6.0 vSphere Web Client comes with a lot of changes, the cool reception it has received from administrators so far could indicate that VMware won't have an easy go of forcing this change on its user base.

Introducing a single point of failure?

Having the Web client as the only means of administration introduces issues in managing the infrastructure if the vCenter Server is down. The Web client is served from the vCenter Server. If the traditional Windows client will no longer connect to future instances, how do we manage them?

There are two possibilities. The first is that for this very specific use case the traditional Windows client will still work. VMware can disable the Windows client from working with vCenter servers while leaving it able to handle basic host-level maintenance. This would represent only a minor deviation of current policy and -- while irritating to those who don't want to use the Web client to manage vCenter servers -- is logical.

The second possibility is that VMware will embed a Web client -- and thus a beefier Web server -- into each ESXi host, which is something that I would be adamantly against. The whole point of ESXi is its minimal attack surface, because it runs almost no services natively.

There is a rudimentary Web server installed as part of the ESXi host image today, but all it does is present a webpage with links to download the client. I'm not OK with it having the kind of complexity required to handle the full-fat Web client. The more complex that Web server is, the easier it will be to use it to compromise the ESXi host.

Most browsers are insecure

Today's Web browsers are terrible at security. They have layer upon layer of irritating "features" added to steer end users away from getting pwned by the first infected banner advertisement they stumble upon.

Some of this security comes in the form of Band-Aids put in by the browser maker. Others are plug-ins that the end user or systems administrator push down. In either case, unless you tear out all the security from your browsers, expect a User Account Control (UAC)-like experience, designed to frustrate and annoy. Not the mildly less irritating Windows 7 version of UAC, but the full-bore Vista version.

The Web client also requires the Adobe Flash plug-in. This plug-in competes with Java as the biggest malware vector of modern times. It is a security nightmare and absolutely should not be allowed on enterprise PCs. Despite this, you can't use the Web client if you don't have it installed.

In addition to Flash, if you want to use features like remote console or Windows session authentication -- and you do -- then client integration plug-ins must be installed and allowed. Considering that these are likely to be installed only by systems administrators, it could be argued that they don't pose a huge security threat.

VMware Client Integration Plug-inMost administrators will have to install the VMware Client Integration Plug-in for remote console or Windows session authentication.

Of course, sysadmins typically run with user accounts that have access to privileged areas of the corporate network, and the integration plug-ins aren't open source, so we have no idea how secure they are. Which means making doubly sure these plug-ins are authorized in the browser to work only with the vCenter Server, no other sites. It's little more than a nuisance, but the whole concept of Yet Another Browser Plug-in just makes me itchy.

What's more, the integration plug-ins aren't fully baked. One example is that logging in with Windows session authentication can and does error out randomly, complaining about "identity source," but a second attempt to log in works. Similar hit-and-miss issues seem to exist with connecting to the console. The old Windows client "just works" in the same environments, without error.

More living space required

The Web client user interface is cluttered; there's more chrome in it than in that Windows UI. Even if we're just talking "a few pixels here and there" spread out over all the individual UI elements, this adds up. The most common display resolution for PCs today is 1366x768, and I feel the current iteration of the Web client borders on unusable at this resolution.

Cluttered vSphere Web Client UIThe vSphere Web Client interface is untidy compared to the Windows client.

This is a real issue. The times I am most likely to be frustrated by a balky UI are those times I am under the most pressure to get something fixed. Being under pressure to get something fixed usually means I've been interrupted on a vacation, at a conference or while I'm sleeping. In all these situations, the first device I grab will be my notebook: a Lenovo x230 with a 1366x768 screen.

The Web client also has gone the Microsoft route of nesting things One More Level Down. Where I might have 12 or more tabs on the Windows client, I only have four on my Web client. Getting to the rest of the controls requires finding the right tab and going either into a sub-tab, or a tab with a frameset-style screen split.

Windows client tabsThe Windows client provides more tabs, providing a more organized layout.

The use of tabs versus framesets is inconsistent throughout the UI. Worse, the use of these frameset-style items on an already chrome-heavy UI makes the space issues even more pronounced. Getting more space is hard, because the left and right sidebars can be shrunk only so much, and finding the click targets for that is a lot harder in the Web client UI than it is in the Windows one.

Shrinking the vSphere Web ClientThe sidebars on the vSphere Web Client can be shrunk only a certain amount and this makes it more difficult to use than the Windows client.

The need for speed

I've saved the No. 1 complaint for last, and that is simply "speed." The Web client is slow. Painfully, frustratingly, hair-pullingly slow. Some of this is due to the browser and some of it is a factor of what you run vCenter Server on, but it boils down to this: Flash inside a browser is slow.

Some people aren't bothered by clicking on something and waiting a few seconds for the UI to do something simple like "iterate a list of virtual machines attached to this server." After about 10 minutes of using a UI that unresponsive, I go stark, raving mad.

The old Windows client is imperceptible. Click and the info is there. Expanding a tree just completes in a time frame so short that a human can't tell there was a delay.

Every action -- no matter how minor -- creates some delay in the Web client. Chrome is the fastest, followed by Firefox; however, both browsers are still unacceptably slow. What's ultimately the damning element of this is that Internet Explorer is the most common enterprise browser. In many environments, browsers that aren't Internet Explorer are outright banned. That means the slowest possible browser is the most common. For added fun, it's also the least secure of the big three!

It's not all bad

For all my griping, it isn't all doom and gloom. There are a few features of the Web client that some might find useful. The most notable is that some actions in the Windows client could cause the "white screen of death" as the client sat there and processed some unusually large command -- sometimes for minutes or hours.

To continue working, you'd have to open another copy of the Windows client, and you couldn't close the apparently frozen one, because it was actually still doing useful stuff in the background. The new Web client queues these tasks up in the background, allowing them to complete while you continue about your day. A great feature.

Additionally, for those inclined towards high customization of their environments, some of my much-complained-about chrome in the Web client is the ability to drag around, shrink or close elements of the Web client's UI. In the Windows client, you can't minimize subelements of the UI: You get what you get and don't have much room to customize it for only the information you care about.

The Web client also opens VMware administration to non-Windows platforms, something that is increasingly important as alternative desktop operating systems are adopted by companies around the world. Apple's OSX is one such platform that has seen huge adoption, especially in the United States, and having a unified UI that works across multiple platforms makes perfect sense.

How to improve the Web client

In all, VMware's Web client is a mixed bag. If you talk to Microsoft's UI designers, they'll defend the Metro UI to the death. They'll explain in detail how Windows 8 is absolutely brilliant and it's the end users who are at fault for "just not getting it."

To a large extent, I feel that this is exactly how VMware is treating the Web client. They have decided what is to be. You will accept it and you will like it.

Windows 8 could be beaten into shape with moderate effort. Despite this, it tanked and it took the entire PC industry with it. More than anything, it was Microsoft's customer-hostile attitude that led to the failure of Windows 8. I fear that if VMware doesn't handle end-user resistance to the Web client properly, the same thing could happen to VMware's ESXi 6.0.

VMware has two choices. It can send forth its army of bloggers, sales engineers and other staff to belittle and berate those who don't like the Web client, earning enmity and hostility from the very individuals they rely on to purchase their software.

Alternately, VMware can launch an intense -- and probably expensive -- program of user feedback in which all users, no matter how small, are given the chance to vent their spleen. This means making users aware that they have a voice; actually acting on the complaints leveled by users; and being absolutely vicious about cracking down on employees who belittle user complaints on social media and at sales meetings, VMUGs and so forth.

VMware has made it perfectly clear that the Web client is the future. Given its many limitations and irritations, enforcing that future without earning resentment will require corporate humility, compassion and understanding that I have yet to see demonstrated. Is VMware up to the challenge? Only time will tell.

Dig Deeper on VMware basics

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What are your feelings on the vSphere Web Client?
You hit great points in your post, articulating some of the most salient pros & cons of both the Web Client and Windows Client. Two additional items--feature parity and non-vCenter host management--need more coverage.
WIth feature parity, it's clear that "all new features will be managed in the Web Client"--and the practice is observable in 5.0->5.1->5.5--yet 100% of old and new features are still not available in the Web Client (and based on things I've seen, that won't be changing any time soon). You end up with at least two required tools to get all the work done. Even beyond the high level features that are in the Windows Client but absent from the Web Client (Update Manager & multi-hypervisor management are quick examples), even "identical" features lack functionality or usability in the Web Client. You point out some UI issues with respect to screen usage and workflow, but I'm also thinking of even granular functionality: the comparative differences between the two guest console functions is incredible. Even the vCloud Director remote console is superior to the Web Client console; given both products' browser-centric nature, you'd think they'd share the same code. For missing new features, you nominally use the Web Client for VSAN configuration & some management & monitoring, but only the rvc (Ruby vSphere Console) has ability to expose the VSAN Observer and other important diagnostic tools for that featureset.
On the non-vCenter host front, it's loosely publicized that Workstation (and a future version of Fusion) can manage individual VMs on a standalone host--not to mention vm-10 guests on a vCenter managed host--but that's an added cost. A licensed standalone host can also be managed using API-leveraging tools like PowerCLI, but that's again a Windows-centric toolset. Finally, VMware could--instead of beefing-up the host-based webserver--create a sort of "containerized" web server (eg Tomcat server) that you must launch on your local administrative workstation for a browser on the local or even another admin station to use to manage a stand-alone host. As long as that webserver has enough of the host-specific functionality, it would get the job done. It would be a mistake, but it would work.
For customers who are interested in providing feedback on the web client (we are interesting in hearing it!) please get in touch directly with the product team to provide feedback, details of how to do this are available here -> https://communities.vmware.com/message/2387221#2387221 and also consider getting involved in the current vSphere beta program -> https://communities.vmware.com/community/vmtn/vsphere-beta
Conversation at Reddit: http://www.reddit.com/r/vmware/comments/2btd71/what_vmware_needs_to_do_to_convert_the_vsphere/
This is by far the best and probably most viewed post about the vSphere web client: https://communities.vmware.com/thread/477686?start=0&tstart=0

IT was already been viewed over 110k times with over 450 responses.