Today we have two important announcements. First, the C# client (AKA Desktop Client/thick client/vSphere Client for Windows) will not be available for the next version of vSphere. Current versions of vSphere (6.0, 5.5) will not be affected, as those will follow the standard support period. You’ve heard this from us in the past, but we’ve been waiting for a sufficient replacement before finally moving forward. Second, we want to talk about the recent vSphere HTML5 Web Client Fling, user adoption, and VMware’s focus on bringing a great user experience. Like the Embedded Host Client Fling (which made it into vSphere in 6.0U2), we plan on bringing this product into a supported release soon.
We’ll be referring to the new client as the vSphere Client, as it better describes the product, and isn’t a ten syllable mouthful (vSphere HTML5 Web Client).
Looking to the Future
VMware has been working towards the transition to HTML5 with the Platform Services Controller UI, vCenter Server Appliance Management UI, and the Host Client. All three of these were very well received and have become the official interfaces for their respective components. The last (and biggest) one to tackle was the management interface for vCenter Server.
vSphere Web Client has always been intended to be the replacement for the Desktop client, and many of our users have tried to embrace this during the vSphere 5.5 and vSphere 6.0 periods, spending their time working within the Web Client even with the Desktop client available.
While there were certainly issues with the 5.5 and 6.0 Web Client, many users that committed to the experience came to enjoy many of the new features and usability improvements. We also continued to listen to our customers, making further efforts to improve the Web Client experience have been made across 5.5U3, 6.0U1 and 6.0U2, including VUM (vSphere Update Manager) in 6.0U1 Web Client. We have made the Desktop client available during this period, which was much longer than originally planned. But now that time is ending.
Additionally, due to the shift in backend services going from vSphere 6.0 to the next version, updating the Desktop client would have required a huge investment. This may have been okay in a vacuum, but the required resources would have severely impacted the progress of the new vSphere Client, only to end up with four clients for users to juggle. We decided to focus on bringing the new vSphere Client (HTML5 based) up to speed as fast as possible, simultaneously offering a great user experience and getting off of Flash.
The new vSphere Client (HTML5)
(Try it here: https://labs.vmware.com/flings/vsphere-html5-web-client)
This decision is about VMware trying to provide the best user experience: a fast, reliable, scalable modern interface that allows you to get your work done is our primary goal. The new vSphere Client is the best way to achieve that goal. Many have already tried out the Fling (https://labs.vmware.com/flings/vsphere-html5-web-client), with approximately 40% of survey respondents deploying it into Production and using it daily to manage their critical environments. With this Fling, we’ll keep the user experience mostly the same as the Web Client, which we’ve improved, based on your feedback. We also plan on making additional improvements to make it easier for C# users to transition.
One benefit of the Fling delivery model is very fast turnaround. We’ve been able to release a new version of the Fling every week, with new features, bug fixes, and performance improvements. More importantly, we’ve been able to quickly incorporate user feedback into the product. Sometimes this means simple bug fixes, sometimes this means changing our priorities to better address user needs. While this pace and model of delivery may not be used for the fully supported releases, due to testing time required, we likely will continue to use the Fling releases to stay on track with users. A fundamental part of this high touch engagement model is users staying as up-to-date as possible, and most of our Fling users are doing just that, so thank you!
Plugins
We also recognize how important plugins are, and the transition from Web Client to vSphere Client will take second and third-party plugins into account. We’ve already started engaging with plugin developers of all sorts to get them moving to the HTML bridge, which will allow the creation of a single plugin that is forward and backward compatible with both the vSphere Client and the Web Client, creating a smooth transition path. If you require more information on plugin migration, please contact us. One great source of information is this site which contains a lot of future looking information about vCenter. This site will be updated as more information becomes available, so keep an eye on it: http://www.vmware.com/products/vcenter-server/future-overview/overview.html
We do expect the plugin transition to take some time, and this means that we expect to ship the Flex based Web Client and the HTML5 based vSphere Client side by side for some uncertain period. Everyone is very eager to have the new vSphere Client as the only client, but we want to respect the porting development time our partners require.
Seeking your Feedback
Hopefully these announcements come as a shock to no one – they are simply a reiteration of the message VMware has given for years. We are continually working to make vSphere Client a fast, reliable, and scalable product that provides a great overall experience. If you have any comments, please post them below. We’d like to hear feedback from all points of view, as we look to the future instead of the past.
Dennis Lu
Product Manager, vSphere Clients






Eric Singer
I’m going to throw my .02 and I’m sure it matches many customers out there. I’m glad you have a web client, but I hate that you’re forcing it down our throats. Client / Server interfaces just run better. Ask most people who have an exchange environment if they’d rather use the full outlook client or OWA and you’ll overwhelmingly find that using the full client is preferred. This is even after countless improvements to the web interface. For you guys, I find this no different. Even if the html5 interface is fast, it will never be as fast / snappy as a new c# client could have been. I get that you probably have an increasing number of folks using Mac’s and maybe even Linux for client access, so web makes a lot of sense to make it easy to offer a single interface. However, I see no good reason why we can’t have a full featured, REALLY fast c# client and a web client. I’d bet every windows admin would still rather use a c# client for their day to day administration over the web client.
collick
i am agree with you !
Eric Singer
I’m going to throw my .02 and I’m sure it matches many customers out there. I’m glad you have a web client, but I hate that you’re forcing it down our throats. Client / Server interfaces just run better. Ask most people who have an exchange environment if they’d rather use the full outlook client or OWA and you’ll overwhelmingly find that using the full client is preferred. This is even after countless improvements to the web interface. For you guys, I find this no different. Even if the html5 interface is fast, it will never be as fast / snappy as a new c# client could have been. I get that you probably have an increasing number of folks using Mac’s and maybe even Linux for client access, so web makes a lot of sense to make it easy to offer a single interface. However, I see no good reason why we can’t have a full featured, REALLY fast c# client and a web client. I’d bet every windows admin would still rather use a c# client for their day to day administration over the web client.
John Nicholson
Eric,
if you want a local thick client for basic VM administration Workstation/Fusion still do this (I use Fusion to connect to my vCloud Director stuff and it works great.
Eric Singer
Really appreciate the tip, but I don’t own fusion :-/ And honestly its the principle behind it all. VMware says they’re listening to the customer, but from everything I see on Reddit and other forums, people prefer the c# client (still).
Ryan Roland
Eric, the reason I believe most people prefer the C# client (from my own experience to hearing others’ opinions) is that you can never completely trust the web client. By that I mean that the information displayed in the web client is always suspect. I never know if what I’m looking at is actually accurate or is just a cached reflection of information from several minutes ago. From powering on/off VMs and waiting 4-5 min before the interface shows the status change, to seeing paths go dead in the C# client, but the web client continues to show them as active, etc. Having to hit the giant on-screen refresh button every few minutes to ensure I’m looking at up-to-date information is completely unacceptable to most people.
Functionality aside, ridiculous flash requirement aside, different organization aside, that single reason is enough for me to want to continue to use the C# client.
RR
TJ Zimmerman
Respectfully sir, I disagree with you. I see why some might prefer the fat client. However, after using the C#, HTML5, Flash, and Fusion clients, I can certainly say that the HTML5 client is the fastest, sleekest, and overall best tool to get the job done.
Unfortunately throughout the beta phase it has been lacking in some integral features. But, as we all are sure to know, these will be delivered in the final release. Making the HTML5 client the best option for interfacing with ESXi servers.
Dennis Lu
Thank you for your feedback. The unfortunate reality is that it’s not possible do have both products fully featured. The C# client has some fundamental tradeoffs within its design that prevent it from achieving the speed and scale goals for vSphere. Also, since nothing occurs in a vacuum, any work done on one product detracts from another.
These announcements today show our intention to focus all our resources on making the new vSphere Client the best of both worlds: fast AND scalable.
Thedude
Is it possible to have a “classic” option for the html5 client, to look like the c# client? That would stop alot of b*tching I think 🙂
Dennis Lu
We are looking at different schemes, but have to get our base one set a little better first. Second most requested has been “Dark theme” for being easier on the eyes at night (or in the dark).
C# theme has been thrown around too, so we’ll keep it in mind. It really shouldn’t be that hard for us to build, the theme switcher stuff is the harder part.
The bigger part is getting in a ‘tight’ theme, for those that really want as much data on screen at once (ie. most inventory in the tree showing simultaneously). We’re working on that too, but as with all things, no promises of when.
P. Cruiser
+1 for a “tight” web UI. Not everyone has 4K screens yet.
AK
+1 on ‘tight’ theme. If I really take a step back on why we have ‘avoided’ the Web Client, there are 2 main reasons.. Speed (Which it appears is starting to get addressed in the HTML5 client) and amount of data on the screen.
I think honestly, FEATURE-Wise, the Flash web client is there. (and I assume the HTML5 one will get those features). The main struggle is when the $h!t hits the fan, the most important thing you need to be able to do is see as much as possible at once. Especially when it comes to Tasks/Events and Alarms. even if in the webUI, it could pop open a full screen Events or Tasks view for the node you are viewing, that could help. Need some really good filtering options as well. Would be nice to almost separate out tasks/events into a proper viewer (e.g. Windows Event Viewer).
AK
Joe Newmaster
We’re just having a hard time seeing the benefit without knowing the goals. For example, if this helped you create a system with distributed management accessible with a virtual IP I would certainly understand the push.
Adam Eckerle
Hi Joe, the goals are really simple. The C# client is Windows-only and our user base is increasingly running in non-Windows environments. Plus, to do better at being interoperable across our portfolio and get to a consistent UX across that portfolio we need to go to a web-based model.
Also, having to upgrade the C# client on each client machine when there is a vCenter Server update is also not manageable. Not to mention plug-ins…
Does that help or do you still have questions?
Joe Newmaster
Thanks for the information. It is much appreciated.
Brian Burdorf
I couldn’t agree more Eric I’ve ran into issues where my webclient won’t load but thick client worked. I also don’t like that only advanced features are able to be managed via webclient like vGPU and Vsan that we use a lot.
Dave
I hope the developers recognise the move in the market to tablet devices.
Hopefully the new client will be fully supported/usable on Apple devices such as the iPad pro.
(The current html5 fling isn’t great on the iPad. (Also trying to open a console fails)
Dennis Lu
We have tested it ad-hoc as you say, and we intend on keeping an eye on this. Most of the functionality works, but we may do some styling changes to achieve better touch usability (you may see this already in some of the bigger buttons), but we could make them even bigger.
We did notice the console issue but haven’t root caused.
If you have specific pieces of feedback about the iPad experience, please submit them through the Feedback tool (smiley face) and include “IPAD:” at the beginning of your feedback, that will help us organize.
Gregory
Great work guys! We’ve all been foaming at the mouth for this improved web client for a while and I’ve personally been following the Fling for a few months. eck79 mentioned on /r/vmware that the fling ‘may’ work on vSphere 5.5u3b, is there any more official word on that? I’d like to try it out myself
Dennis Lu
Hi Gregory,
Sorry for taking so long to reply, busy day.
It’s highly unlikely that we’ll be able to get it to work on any version of vSphere 5.5. Web Client is designed to work with 2 versions (the one it’s released with, and one version back for upgrade transitioning), and vSphere Client will likely follow the same model. The truth is that the backend APIs change so much from one version of vCenter to the next that even carrying 2 is quite a bit of development time, and even more testing.
But, we’re trying to listen to customers on the entirety of vSphere Client. If we hear enough demand for 5.5 support, we’d look deeper into it. That’s not a call to bombard me with requests on this page, but if you start a thread on the Fling feedback page and get everyone to post to it that certainly would be a sign.
Ross
Please respect the customer base and not go through with this (yet).
I’ve broken my thoughts into 6 ‘reasons’ why such a decision needs to be postponed until VMware are 100% ready with a usable replacement.
1) Availability: VMware have no genuine replacement for the C# client at the moment, the statements in this blog post are all for a proposed replacement HTML5 client that does not exist in full nor has it gone through at least one iteration of a production version.
2) Feature parity: The host client is still not a valid replacement for the C# client when setting up the first few nodes of a new environment. It’s still not anywhere near feature parity nor for ease of use. It tends to freeze up and ‘go on holiday’ between clicks of the interface.
3) Consistency: The host client and proposed HTML5 client do not have the same ‘look & feel’ as each other. The C# client is consistent for 1 host or 1000 hosts.
4) Functionality: The web client has been pretty much universally criticised as a poor replacement and most vSphere admins are forced to use it only when needing some advanced setting such as LACP on a dvSwitch. With such negative feedback it is hard to understand why VMware is still forcing this issue. We are its primary users, we don’t need some glossy Web 2.0 type interface to get on with our daily jobs. When it comes to 2am in the morning and something has gone pear-shaped, you’re not caring about the wonderful compatibility across browsers when the basic premise is to get a system back up and running as fast as possible.
5) Pace: It says a lot when many of the VMware professionals tell me that during their VCAP exams they use the C# client as much as possible or otherwise they’d run out of time. These are the people VMware rank as ‘Advanced Professionals’ so perhaps that might give a little food for thought.
6) Complexity: More as an aside, I recently carried out a vCenter 4.0 minor patch upgrade on a legacy system. The simplicity of the upgrade and ease of use was actually at direct odds of the monster vCenter has become over the last few years. I wonder if you were to sit back and think about what has happened to the vCenter architecture has it really been for the better? It’s definitely become far more complex a beast but for what gain?
My bottom line on this is if you make a HTML5 client that has the exact same layout and feel as the c# client then you might get us to try it.
I would further respectfully suggest you deliberately break and take down a full vSphere environment and then run a bake off of C# vs HTML5 webclient. You’ll know pretty quickly if the new webclient is fit for purpose! When it is then put up a video online showing it out performing the old C# client and you’ll have us all eating our words!
Sorry for the rant…
Nick
Well said, Ross. I echo your thoughts on this.
I loathe using the current web console for any task. Let’s get the HTML5 client up to par first, run side-by-side for at least one major version and then we can talk about not supporting C# anymore. VMware – you have got to listen to your advanced admins here. I personally don’t know of anyone who actually likes the current web console.
Griffin
Your points 4-6 are fairly meaningless. They all address the current web interface and not the proposed HTML 5 redesign. Outside of occasional slowness in the *current* flash interface, I can do things much more intuitively inside of the web interface as opposed to the fat client.
krento
occasional slowness in the *current* flash interface??? What alternate reality are you writing from and how do I get there?
Ballmer
I call BS on the ” clients prefer the html5 clients” Hardcore users still prefer C# client. This is vRAM licensing all over again.
Adam Eckerle
Can you explain how this relates to vRAM? I’m genuinely interested the comparison.
Comment
The time VMware got greedy and thought charging people for vRAM would be a good idea… and then VMware removed it. But in this instance VMware is really stubborn and not listening to their customers and forcing the loyal customers to use this crappy solution instead of continuing to develop the thick client.
Adam Eckerle
We have been working with many customers on both our direction and the clients themselves. While change is always difficult, we have many customers who are both excited about this change and have been integral in the development process.
If you’ve used the HTML5 vSphere Web Client Fling then I would be interested in your candid feedback. If you haven’t tried it yet, what are you waiting for? 😉
Guy Schellens
Great job, guys, HTML5 is the way to go. We should abandon Flash as soon as possible.
I hope it will be available for every supported environment (5.5, 5.1 …)
Dennis Lu
Unfortunately this is pretty unlikely. My reply above regarding “support on 5.5u3b” contains a longer explanation, but short version is: 5.5 quite unlikely, 5.1 effectively zero.
But the more we hear from customers about it, the better the chance we’ll look into 5.5 support on the Fling.
Andrew
Great post Ross, much of what you said embodies many of the concerns that myself and other administrators I know have had with the web clients.
WebClient will never be faster than a custom C# application. It may be easier to make changes and updates, but saying it will be faster is just fanciful dreaming. I’ll make another point about the use of WebClients, the platform they run on aren’t solely used for the management of VMware (you have those 20 other reddit tabs to the right as well).
The move to HTML5 might be by choice, but they would be force to do so anyway. Flash and Java are being removed from the browser space, Chrome flat out wont support it in the coming future. Which means the whole thing your building will be dependent on browser support.
Which brings us to another point about changes in the browser environment. Moving to the browser is all fine.. until an organization decides not to upgrade or buy any more support from VMware and a browser update breaks your ability to manage your systems (this is a huge problem for hardware appliances that used Java). Of course you could get an update from VMWare .. if only you still had contract support. Today if someone wanted to they could still be running ESX 3.0 using the C# client to manage it. They paid for it, they can still use it. With the WebClient.. yeah that wont be the case. Once the browser no longer supports your version of ESX or vsphere .. you better hope you have an old browser install somewhere or really good at the CLI.
No matter of protesting will change the fact that VMware will move forward in this direction (C# is old school and Web is the way of the future) , they have too much invested to do otherwise.
Responses to statements
“Everyone is very eager to have the new vSphere Client” – I want it about much as I want Microsoft Bob.
“This may have been okay in a vacuum, but the required resources would have severely impacted the progress of the new vSphere Client, only to end up with four clients for users to juggle” — Statements like these are intended to convince us that it would be a burden on the users to have so many choices.
Dave
Love the vSphere (HTML5) Client in its current fling form. Only request is please don’t bog it down. Can’t wait to see the NSX integration.
Dennis Lu
We are working very hard to keep the performance at par with current experience, and improving it. The message we’ll continually use is that the Agile development and release process is there so you can also help keep us accountable. If it’s slow in your environment, let us know immediately so that we can work on it.
Sprawl
What you’ve basically said is “we haven’t listened to our clients” and continued down this path. I will continue to use 5.5 until EOL and migrate to another product. Hyper-V has really come along the last few years, and integrated with Windows licenses, almost makes it the immediate just plain easier.
Steve
Goodbye vSphere, hello Hyper-V…
Any web client is awful, just take a look at your current vCloud AIR interface. Anyone that wants to do any work in vSpere uses the fat client, fact…
Simon
I echo a lot of the comments about the web client, I have tried to like it, I have forced myself to not install the C# client but I still don’t like the web client and forcing the removal of the old and much loved C# client is a mistake in my opinion.
I was talking to a couple of people with regards to VCAP DCA testing this week and all they were telling me was launch the C# client and start the exam, I mentioned the web client and they looked at me as if I had pooped the bed, “real admins” don’t use the web client they said.
I agree with Ross’s comments about running the new HTML 5 client along side the C# client for one major release, iron out all of the bugs and show the customer that it’s a worthy replacement for the C# client, don’t force peoples hands to use what is essentially a beta product because that’s going to alienate your customer base faster than you can say Hyper-V Rocks.
I admire the leaps that VMware make with technology and understand the effort in maintaining two mainstream clients is difficult but listen to your client base, with every iteration of vSphere you have tried to move further away from the C# client and with every release the customer base has asked for that client to stay, why do you think that is?
We as technology users get technology, we don’t shun it but we also know that when we have something good we want to continue to use it, the C# client may well be old, restricted to Windows users but it’s rock solid, it’s reliable and not beholden to anything except the Windows OS, we aren’t relying on Chrome, Mozilla or Microsoft to maintain the functionality of the browser to ensure it still works (I remember days where using particular versions of FF meant certain functionality would be broken in one of the web clients, be that VCD or vSphere Webclient). It’s not something I have experienced with the C# client in any of the iterations I have used (I have used it since 3.x).
In fact I have posted a poll on twitter asking the question on whether people would prefer the C# or HTML 5 client – https://twitter.com/EV_Simon/status/733195182364102657
Simon
So current voting appears to be in favour of the HTML 5 client, if you’re a C# client go make your voices heard at the twitter poll – https://twitter.com/EV_Simon/status/733195182364102657
32 votes so far and it’s 31% / 69% in favour of the HTML 5 client so far.
Sergy Fin
Flash WebClient Layout is terrible bad, please mimic C# layout/theme / layout. Most admins I know use the C# client because because everything is much faster and better organized to do. If HTML5 client is fast and has C# layout would be great.
The inventory thing is terrible also in WebClient vs C#, we want to see all inventory not just a reduced version and having to always search by VM name to find a VM.
Dennis Lu
We are working on both of these points. One of them has been mentioned above, regarding working on different styling/design settings, including spacing between objects in the inventory tree.
The second just started with release of Fling v1.6, where the tab structure has been changed to more closely mimic the C# client. If you get a chance to try out the Fling let us know what you think of this change.
Aram Avetisyan
Hey VMware,
I understand, keeping several clients up-to-date takes a lot of time and resources, and you would prefer to spend those on single solution, but, if you are going to discontinue C# client and through it away, isn’t it better to to publish it as open source and allow The Community to maintain it?
Based on the comments I see here, I would assume a lot of people would be ready to spend their personal time on maintaining it and keeping it alive.
That would give customers an option.
Anyway, based on your strategy, i would expect a lot of 3rd party vSphere clients being developed soon, like that thing Super vCenter or something similar.
Regards,
@how2vm
Dennis Lu
We’ve discussed this and will continue to look at it, but I believe a few issues make it very hard:
1) Splitting parts of code that can be shared OSS vs not
2) Use of Private APIs that we don’t want to expose
Hunter
Does this blog really say 40% of people are deploying an experimental fling, which is not supported into production? Why would that have any relevance to the new vsphere web client, and it’s functionality? Are we really promoting people to use an unsupported fling in production?
Hoobaju
Dennis, you and VMware miss some fundamental concepts.
First it is possible to have multiple fully featured products when you actually keep PROGRAMMERS employed (i.e. stop firing so many) in lieu of SALES people. This speaks to the “benefit” as you called it of being able to release new versions of your product each week. Let’s think about this for just a second…With less programmers, yet with more sales folk pitching functions to get you more customers, your current programmers will continue to push out code with terrible bugs. Look at some of the recent issues you have had with other related products like, oh I don’t know the early versions of 6 and the boondoggles in 5.5u3 (vSphere products).
Second. High rate updates will actually make you less enticing to gov’t entities as their code review is so slow and must be done for each major revision. Release high volumes of updates and you will be dropped simply because they can’t afford to use you, while more stable offerings (think anyone else that listens to customers) will become their bread and butter.
Third. Since when does a 40% adoption rate and approval rate equal listening to customers. It seems there is a bigger 60% that thinks your path is terrible and all the comments here should shine a little light on that. The sad part is the so called supporters posting here aren’t posting support but WORKAROUNDS. Your product is so bad that the supporters have to advise workarounds. Even Apple isn’t that out of touch.
Fourth. Who can call a business plan intelligent that specifically cuts out a product that is used and viable on 90% of all computing systems (see Windows adoption rate)? The difference between VMware and Microsoft is simple. When MSFT forced Win 8 on the masses and they did a foolish thing like take out the Start Menu what happened? They put it back. You take away the beloved thick client, all the while customers are saying, “don’t take it away, your other solutions suck”. What do you do? You double down the gambit…wow…good plan.
Just like when you had to cave on the editing VMs with HW version 10+ in the thick client in 5.5, expect a problem and have a team ready to resurrect the client. You may lose more important business over something like this than you gain. Keep in mind who sends the requests, the recommendations, etc. to the CIOs…the workers. VMware is no longer the only or best game in town. You want to be best again, go for stable and reliable, not so much emphasis on shiny new colors and branding. More programmers and less people thinking up new works that start with a “v” to replace words already being used across the world. That is an Apple fail that the world laughs at yet you seem to think is a good idea.
krento
“Additionally, due to the shift in backend services going from vSphere 6.0 to the next version, updating the Desktop client would have required a huge investment. This may have been okay in a vacuum, but the required resources would have severely impacted the progress of the new vSphere Client,”
Solution to this would be to reduce executive pay by 2% and use that money to hire a team of developers dedicated to updating and maintaining the C# client.
Need a web client for your increasing number of non-windows admins? How many of these non-windows “admins” actually need a full featured client? If my environment were any indication of the norm, the non-windows admins are users that only need basic VM level administration abilities. Our day-to-day vSphere admins are all windows users. Build a basic functionality web client for delegating basic admin tasks, but keep the full featured C# client for the heavy day-to-day admins.
Herwono W Wijaya
Yeahh… finally, and i hope, vcloud also using html5 in the future.
Feed BAck
6.0.u2 with Firefox
Add iSCSI storage adapter. There’s no option to add at all.
Menus pop up and cannot be dismissed/eliminated without closing and reopening Firefox.
Datastore browser file transfer is slow and hangs 4 times out of ten. Transfer a large VMDK, guaranteed fail.
These are the ones that jump right out at you. There are probably a ton of other similar items. My point is, don’t be so quick to dump the fat client. The HTML5 interface, while nice, has a long way to go still.
Dennis Lu
Can you tell me what version of Firefox you’re on?
Does this happen on Chrome too?
Comment
This is the rubbish you’d never come across with the C#/Thick Client… “the what browser version are you using, does it work fine on X browser?”
Jimmy
+1 for the fat client. The web client takes forever to get stuff done. Click and wait. Long pauses. Click the refresh arrow and it just sits and doesn’t do anything, or hangs browser completely.
Maybe HTML 5 will be better than flash … it will certainly be more secure.
Samson
We still running Vsphere 5.1 (because our HP EVA has no support for 5.5 or newer). A new Netapp is currently in pre-production.
Anyway, we don’t like that web client at all:
– We had to disable IE’s protected mode to get the C# plugin (!) working (this is a no go).
– Many tasks are a “click orgy”, compared to the native client.
– Update Manager is not available (Ok, this is “fixed” in 6.0U1)
We don’t understand, why VMWare force us to use this web stuff.
Please follow customer requests.
Dennis Lu
Existing releases of vSphere are unaffected by this announcement, so if you upgrade to 6.0 you’ll still be able to use C#
Improvements have also been made to Web Client in terms of performance and usability up to 6.0 as well, which is worth trying and forming your own opinion.
Jim
I’ll immediately grasp your rss as I can’t to find your email
subscription hyperlink or newsletter service.
Do you’ve any? Please allow me know in order that I may just subscribe.
Thanks.
Dennis Lu
The RSS probably won’t help much, we post maybe monthly.
Here is the link for our Fling mailing list: http://goo.gl/forms/H7c6Itrwvk
I didn’t put it into this post because of keeping the topic focused.
Andreas
That link leads to “vSphere #h5client Fling Upgrade Survey”, and not a mailing list subscription 🙁
Dennis Lu
OOPS!
I made a mistake. Both links exist in the Fling v1.2 post, and I copied the wrong one: https://blogs.vmware.com/vsphere/2016/04/vsphere-html5-web-client-fling-v1-2-h5client-moving-away-from-client-integration-plugin-cip.html
Here is the right link for the email announcements mailing list: http://goo.gl/forms/IqGJ5twYHf
Darren DeHaven
It would be great if the HTML5 client was released before the standard eol of 5.1 in a few months.
Dennis Lu
The new vSphere Client (based on HTML5) currently is only available in Fling form and works only with vSphere 6. There are some above posts with more detail, but it’s very unlikely that it will ever work with 5.1, or 5.5.
Ken
Dennis,
Frankly this sucks. I hate web only management clients. Regardless of the “standard” of HTML5, each browser seems to act on it slightly differently. That gives each browser, on each OS, a different feel, and often things don’t work across different browsers. I do understand wanting to consolidate development into a single line, but again, this sucks. I personally run vSphere 6 and only use the web client if I absolutely have to. I live in the desktop client and if I have to start doing everything in PowerShell I may do that rather than the web client. Maybe I’m old fashioned but that’s my opinion.
Ken
Dennis Lu
This was definitely true back in the day, and one of the major reasons we originally choose to use Flash!
Now with HTML5 standards published, widely used, and widely implemented by browser vendors, this is much less of a problem. We do test on multiple browsers, and are keeping an eye on any variations in both functionality and appearance.
Any user that does notice a problem, we encourage them to report them using the Feedback tool, and provide all the details they can (for example, if it’s an issue only in browser X but not Y).
Xst
Oh c’mon VMware, why you do this. It’s only you benefit! It’s crazy to work with those stup.. webclient !!
Think it’s time to think about a change to Hyper-V
Ginginho
>we’re trying to listen to customers on the entirety of vSphere Client. If we hear enough demand for 5.5 support, we’d look deeper into it.
But you are not the slightest bit interested in the overwhelming demand to retain the C# client??? I never thought I’d see someone out-Microsoft Microsoft in their pig-headed determination to force such an unpopular change on their customers. It really does beggar belief!
Can I ask what percentage of your customer base you think want to retain the C# client? I’m assuming that you’ve done some research into this and the result must have insignificant.
Dennis Lu
Unfortunately this decision is not made in a vacuum. Any investment into C# detracts from the investment into the new HTML5 based vSphere Client.
One user above posted this twitter poll, which as of this moment has 90 votes, 75% for HTML5: https://twitter.com/EV_Simon/status/733195182364102657
Craig Lindsay
Does VMware not have enough resources to work on 2 clients? Let me answer, they do, but are choosing not to. I find this unacceptable. My company pays nearly 100K a year for support and I know I am not alone. I have been vocal about disliking the flash client but my feedback is regular met with we placating but “too bad” type responses. While the HTML5 client will be a welcome change to the flash/virus client that is currently out, I would still prefer the C# client. Dropping development for it simply means we as a company drop VMware support because this is a sign of a larger VMware problem of NOT LISTENING TO YOUR CLIENTS.
Samson
You made product decisions based on such twitter polls?
Send a poll to all your customers with an active software subscription. I think, you get a very different result.
Ginginho
Dennis: please assure me that you’ve not read as much credence into some guy’s Twitter poll as it seems!?! Has VMware has undertaken any research into their customer’s preferred management client?
Onedee Tentee
Apparently he does, otherwise he wouldn’t have referenced it. Damn shame what happened to real polls of the user base.
Dennis Lu
This poll was launched by a user several hours after the article was posted. Without violating the laws of temporal dynamics, we would not have been able to include this information into the decision itself.
We have put a lot of time and research with customers into this decision. Showing the Twitter poll was simply an expedient way to show you some information that was not sourced by us, avoiding as much perceived bias as possible. We have tons of positive response, including from many of the Pingbacks on this page, other articles, and other sources of public information.
Onedee Tentee
@Dennis Lu: This is in response to your reply below, which somehow has ‘Reply’ disabled.
I’m aware of people that use the HTML client and are ambivalent to it, and some who prefer it, but not for ease of use. Since it’s not a controlled poll, it’s meaningless. As suggested above, try a poll of your constituents and see what the response is. You haven’t mentioned that as part of the “… a lot of time and research with customers into this decision”. I believe it’s purely a cost decision, since maintaining 2 clients is expensive.
You’ll win me over of you can create an HTML client that allows all the control with the keyboard that the C# client does. Otherwise you’re making our jobs harder, not easier. If we ever meet in person I can regale you with the story of Major Utiliy LDAP root vs computer Mouse.
Dennis Lu
I think the commenting system only supports so many levels of nesting, so it doesn’t allow replies to comments that are nested too far down (I wasn’t able to reply to your new comment either).
We’re very interested in hearing what you’d like to see in the new HTML5 based vSphere Client. When you say ‘all the control with the keyboard that the C# client does’, can you be more specific?
This might be a request better made on the Fling comments, if you’re willing: https://labs.vmware.com/flings/vsphere-html5-web-client#comments
Mac
No no no!! Don’t stop development of the fat client. We didn’t work with the actual web client and we’ll never do this in the future. The question is do we have migrate to Hyper-V or XenServer when VMware ignore that? Yes, we will.
Web client is slow, confusing… just weird and creepy… Stopping developing C#-Client is stopping costumer relationship.
Brian Simon
You would really move to xenserver from vmware because of this news? I am going to assume your just venting here because that is silly.
Sunil
C# client is best. Web client needs more improvements. Please don’t discontinue the C client.
NoSupport4Freedom
What is the “Support Period”?
I have requested the Thick Client be fixed for over a year now to no avail. I have documented tickets from Jun2015 to address this supported issue. Millions of Taxpayer dollars are tied to this support contract.
Concerning KB2143566.
Has VMware blatantly refused to provide support to not only 60% of its customer base, but also 100% of Taxpaying Americans?
Craig Lindsay
Vmware has failed again. They stopped adding (in reality removed) functionality from the C+ client in recent versions while the html/flash disaster client was, to be generous, an alpha quality product at best. They are now repeating the same formula proving they can learn nothing from the past by providing yet another incomplete solution.
The way this should have been done would be to have overlapping fully functional clients and transition customers to their new direction over time, not 2 or 3 simultaneously crippled choices.
Comment
I think this team should all get fired and VMware should re-hire programmers to work on the C# client.
Michael Baranski
HTML5 may be a standard but the way browsers interpret pages is not always the same. So you may be standardizing on a common platform for development but end user experience per organization will still differ due to browser usage at customer sites. The C# client may have been Windows only but it always worked because it just needed the libraries to make it function. It also worked great on a Windows machine hosted by Horizon View. This news coupled with vCloud Suite 7 Ent losing SRM and your support not impressing and causing us several issues lately makes it really hard to stay loyal.
Steve Jin
I think it’s a good idea that VMware supports the HTML5 Fling as part of product.
At the same time, I think it’s too early/rushy to discontinue the C# Client, which I think is still the best MAIN GUI for vSphere thus should be kept and updated continuously. In fact, the C# Client and the HTML5 Client complement each other well even though there are duplicated development efforts from VMware.
A little surprised that VMware didn’t announce to discontinue the Flash Client which is the real trouble maker.
I wrote a blog with more analysis and reasoning:
http://www.doublecloud.org/2016/05/too-early-to-say-goodbye-vmware-vsphere-client/
Will
This is the best blog post I have read in long time. Not because of the news but the comments. I am so glad there are others out there feeling the same pain as myself. I have worked with VMware since ESX 3.5 days and the C# client has always been my friend. I have tried every single “web client” since the original 5.0 release (and promptly uninstalling that one) and been upset with each version. It is now only while running vSphere 6.0 i find myself running both C# and the flash based web client through force. C# for all day to day work and the flash client where I have no choice (SRM or storage and compute vMotions at the same time). The thought of the C# client being removed makes me keen to progress with our CIO’s wish for me to evaluate Hyper-V.
I have even advised old work associates to remain on 5.5 with the original linked mode (removed from C# in 6.0 and migrated to “enhanced” flash only linked mode) and to also remain on SRM 5.5.1 and not move to 5.8 to save them the pain of flash.
VMware please listen to your customers! PLEASE! HTML5 is a great idea but having an up to date C# client to run with it would make a lot of people happy. I am sure these comments will make no difference other than making other admins who read it realise I feel the same pain as them!
A very frustrated customer in London
🙂
Moby
Can one connect directly to an ESX host with the new web client? If not, what can one use to connect directly to an ESX host to troubleshoot, short of the stripped down CLI or powercli?
Is the VMware web sdk still going to be supported? or will that also be replaced?
Dennis Lu
The Embedded Host Client is the tool for managing individual ESX Hosts. It started out as a Fling (https://labs.vmware.com/flings/esxi-embedded-host-client) and made its way into 6.0U2.
We will be creating a new version of the vSphere Web Client SDK, currently a work in progress. We are committed to supporting plugins that have been written using the “HTML Bridge” functionality introduced in the Web Client SDK, and this will likely form the basis of the SDK.
Any partner that is interested in developing a forward compatible plugin should build using the HTML Bridge.
Onedee Tentee
Awesome. We’ll get to click MORE AND MORE AND MORE instead of actually doing the technical work for which we were hired. I just love the Microsoft model of this and how all the other lemming companies are following suit. Hello, carpal tunnel! Thank you so much.
This is a load of hooey: “The C# client has some fundamental tradeoffs within its design that prevent it from achieving the speed and scale goals for vSphere. ”
Your webUI sucks so badly and it’s all over the web how most Admins don’t want it. but why listen to the customer when some exec at VMwhere has decided to make this their next accomplishment?
I noticed that usability and intuitiveness it missing from this: “These announcements today show our intention to focus all our resources on making the new vSphere Client the best of both worlds: fast AND scalable”
Comments
Will all of the ‘unmount datastore’ safety checks that apparently are only done in the vSphere client today make their way to this HTML5 client?
Apparently even today the web client still only does 2 of the safety checks. Even today in the 6.0 web client!
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2004605
Or is the plan we will have to accept the fewer safety checks going forward?
Dennis Lu
This is a very interesting quirk! I will check with the team and see if there was a rationale behind lowering the number of safety checks. It’s possible it’s coming from our storage brethren.
If you can offer more details, are you having problems with the lower number of checks? Is this causing an issue in your environment?
Comments
I am not aware of a specific need for them, but in my environment we need to be as conservative as possible during changes. It’s possible the checks are considered superfluous at this point, just wanted to bring it up in case it fell through the cracks.
If you attempt to unmount a datastore in the C# client, it lists these 5 check boxes:
1) No virtual machine resides on the datastore.
2) The datastore is not part of a Datastore Cluster.
3) The datastore is not managed by storage DRS.
4) Storage I/O control is disabled for this datastore.
5) The datastore is not used for vSphere HA heartbeat.
When you attempt to unmount from the web client, it only shows that it is checking for #1 and #5.
I tried in the latest HTML5 client and the datastore unmount option doesn’t appear to be implemented yet.
Dennis Lu
Thanks for the details, always helpful for us to make sure we’re on the same page. We’ll check on this.
Sarah
Right now I only use C# and am skeptical.
Mark
Have you tried using the HTML5 fling yet? I felt the same way, but after trying the fling I’m more hopeful.
Sarah
Thanks!
Peter
Like many others, I prefer the C# client as well. The web client is slower and provides a less interactive user experience. You have many people saying the same thing, yet the response from VMware is the same kind of patronizing spin you would expect from a big vendor that no longer listens to its customers.
Let’s look at what we have for management interfaces:
1. A formerly effective, well-performing, but now feature-incomplete and deprecated UI.
2. A poorly-received flash-based web client based on legacy technology that major browser vendors have all but abandoned support for.
3. A feature-incomplete less than beta version new web UI that uses the so-called latest and greatest technology. “Trust us, it will be great!”. Have we heard this before?
Is this really acceptable from the industry leader?
Beau Parbhu
Well Said Peter. Cannot agree more.
Will
Has anyone else experienced this with migrations when you have over 10 port groups. The work around provided says it all: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2140943
Mike
Dennis,
VMware can try to spin it as much as they want, but the fact is that every VMware admin I speak with agree with Ross and Simon above. I have been to VM World where the presenter asked who preferred the C# client and 295 of 300 admins raised their hand. I’ve told every one of my VMware account reps about this for the last few years, so they know. It’s obvious at this point that VMware management does not care what we think and I find it incredible that they would no longer support one of the best apps they have ever created. Like another user above, send an email to all admins that have verified subscriptions and ask them if they desire full featured support for the C# client. This should have been done three years ago and all this mess could have been avoided.