VMware published a blog “Goodbye vSphere Client for Windows (C#) – Hello HTML5” with two announcements: 1. There won’t be the traditional C# based vSphere Client for the next version of vSphere (no one knows the version yet but it’s safe to call it the next version.). 2. The vSphere HTML5 Web Client Fling will be supported soon (no exact timetable is given). My guess is that it will make into next release of vSphere if not earlier.
Last week I released a tiny tool called DoubleCloud Client, which eases the usage of vSphere Web Client. I didn’t have time to add another hack which can bypass the session timeout of vSphere Web Client.
By default, vSphere Web Client times out after 30 minutes of inactivity according to VMware Doc. After timing out, you got to re-login and click back to the page you left out. It’s good for the security, but also not convenient. If you use it on your own desktop and have set up screen saver with password protection, you don’t really need this security feature.
In my previous article, I talked about why Web is not a good choice as the primary GUI for vSphere. I also mentioned that I was working on Ua small app to enhance the user experience of vSphere Web Client.
Today I am happy to announce a small application I developed recently using latest Visual Studio 2012 Express which is free from Microsoft. Although known with my work on Java in the community, I am pretty open to any programming languages and tools that are best to get work done. This time it happens to be C# and .NET.
I recently started to use the new Flex based vSphere Web Client while working on the open source vijava to support vSphere 5.1. Overall I like the look and feel, and particularly the extensibility story around the new architecture. However, I am not impressed by the performance – I saw way more “loading…” and clock cursor than I expected. Technically, I don’t think that is the direction VMware wants to bet on as the primary user interface for its flagship product vSphere.
If you think vSphere Client exposes everything, you are wrong. The vSphere APIs actually expose more features than the vSphere Client, which is a great product. This is one reason why system administrators should learn vSphere APIs.
While writing my book, for example, I noticed that vSphere APIs actually allow you to change guest OS screen size with a simple call setScreenResolution(int width, int height).
Given the time pressure, I didn’t summarize these API only features at that time. To be honest,
Normally on the login dialog box, you enter a hostname or IP address. By default, the vSphere Client use HTTPS to communicate with the server. That means you cannot easily see what’s passed back and forth on the wire. As shown in the Onyx video, Carter showed how to use HTTP instead of the default HTTPS with the following in the IP Address / Name field:
So the vSphere Client does support HTTP. In Onyx case, it points to localhost on which the Onyx is installed. You can actually point to a real vCenter or ESX/ESXi server directly – just change the localhost to the IP address of the server and the port to the default port 80 or remove the port part.
Before connecting the server, you need to change the server a bit for it to support HTTP.