This post is also available in: Italian
In a previous post I’ve described the limits of the (legacy) vSphere Client, especially in the 5.5 version. But also the (new) vSphere Web Client has some limits, also in the 5.5 version.
First to all is VMware vSphere Web Client really a multi-platform solution? It could be, but the Flash framework (and the VM console plugin) imply some possible portability issues.
Because Linux platforms are no longer supported by Adobe Flash, vSphere Web Client is not supported on the Linux OS. Third party browsers that add support for Adobe Flash on the Linux desktop OS might continue to function.
On the other side, the 5.5 version introduce (see what’s new document) a full client support for Mac OS X is now available in the vSphere Web Client.
Other limits remains almost the same of the previous 5.1 version and are well described in this VMware post. Basically several plugin are still legacy and not re-resigned for the new interface. VUM is one of them, although some informations are now available also in the Web interface, but the scan & remediation process could still be done only with the old interface.
Anyway this transaction phase will hopefully close with the vSphere 6.x release where only the Web interface will exist.
But I hope that some aspects will be fixed before the “unified” version:
- off-line mode: actually the Web Client 5.5 works really well (compared with the 5.1 version) on WAN, but the download process of the Flash part is still boring. Some way to have and keep an offline version will appreciated
- console plugin: why don’t use a HTML5 version or something really portable. Blast protocol existing, but of course it has some limitations (no USB or device redirection that are mandatory for a vSphere VM Console)
- size and panes: you still need a big monitor or big resolution in order to use the vSphere Web Client… some improved in order to use is also on medium video could be done (not all is resizeble and not on the size that you want)
- Flash: really is the only way? HTML5 could not be used in a similar way? This may increase the portability