Purpose of this post is simple and obvious... bring back development to thick client. THANKS!
I'd still like to hear an official response on how one manages a host directly when the host has become isolated, host web server is down, vcenter server is down, etc. using the web client. The web client's server component seems a lot more temperamental, in my experience, compared to whatever sits on the server listening for VI client connections, and that has lead to several instances of still being able to resolve issues with VI client that could not be resolved with web client.
Boo!
Please ditch the web client - it's garbage.
Having been in IT for 25 years - I'm afraid its already too late for VMware.
I was a Master CNE (Novell) back in the late 90's - we had nwadmin32, the Windows client that worked great (although the plugins were a nighmare). Novell tried to get all trendy and replace it with Java - total balls up. Around the same time Active Directory came out and Windows server was getting reliable - people started asking themselves why pay for Novell and Microsoft, when Microsoft does pretty much everything I need. Everyone abandoned Novell Netware for Windows.
A couple of years later I get into VMware - fantastic product. Roll forwards 10 years, "VMware" do a "NetWare" and replace the windows client with a useless web client. And yet again, at the same time when Hyper-v in 2012R2 form is actually a pretty reasonable product. And yet again my bosses are asking "why are we paying for VMware and Microsoft when Microsoft will do nearly everything we want?"
/agree. It's just too complex of a program to handle effectively and smoothly in a web client.
They really got messed up when they tried to meld two separate needs into one package. On one hand having vcenter server allows for some functionality and statistical reporting that ESXi never had plus the ability to manage multiple instances of ESXi from the same presentation space, and on the other they eliminated the ability to simply control ESXi without vcenter. Those two things should never have been put under the same roof. The ability to control ESXi should never have been made dependent upon vcenter being up and running. That introduces additional points of failure and makes having things down for maintenance far more difficult.
IMHO they really need to keep separate the command and control functions (i.e. what the C++ client does) completely separate from the vcenter functionality. If they intend to improve the client, then it should still be a completely stand alone program that will run on MAC, Windows, or Linux. Their original idea of having the client be able to connect to vcenter in order to manage multiple ESXi instances and to access the additional functionality like the statistical reporting, yet still be able to control an individual instance of ESXi without vcenter, was the best idea they had IMHO. It wasn't a good idea to get away from that and make the command and control function actually dependent upon vcenter.
ajani201110141 wrote:
Hi All,
This post contradicts itself dramatically.
It claims to be "listening to feedback", but no one ever has provided feedback suggesting that the web client should be "improved". It's garbage, to the point that it's hurting VMware entire portfolio.
It should be completely replaced, along with everyone involved in the decision making process that led to its implementation.
wojtowvm wrote:
CP7,
The key is to remember to set the VM hardware version to a lower version than 10 when creating the VM. (it is an easily overlooked setting on in the new vm dialogs on the web client)
Having not done that. You have a few options to try:
- start over (safest)
-or-
- Use the "standalone converter" to convert your existing VM to an earlier version. (pretty safe - especially since you will still have the original)
-or-
- Some people, including me, report success with the following (obviously not recommended for critical stuff but the fastest way):
- shut down the VM.
- remove the VM from inventory (careful do not delete)
- edit the .vmx file (via the host console, ssh, or by downloading via datastore browser, editing and uploading)
- Change virtualHW.version setting in the file to the earlier version.
- locate the vmx file in datastore browser, right click and add to inventory
- upon power on, if it asked you if you copied it or moved it, tell it you moved it
You should certainly back up your VM first in case things go bad. Testing this on a clone of your target vm is also a good idea.
Personally I think the inability to edit/manage version 10 format VMs in the c# client is on purpose to force people to the web interface. It probably would be very little work for them to modify it to support the new VM hardware version since it is very substantially similar from a configuration standpoint. (hence the ability to do the trick above)
In vSphere Web client you can set a default VM level per cluster (I think) for all newly created VMs. This prevents a lot of errors of VMs created with HW10 instead of 9.
Right on!
Our VMware SE asked us for feedback on the web client back in May, and said he forwarded it directly to the product manager. I figured I would jump into this thread and share what I shared with him. As a pre-cursor to this email, we didn't really use 5.1. We had PSO in for an installation engagement for 5.1 and VCD but it never took off. So, we're viewing this as a direct upgrade from 5.0 to 5.5. We installed the initial pieces in January and due to Symantec Netbackup issues are still struggling to migrate. We have about 200 VMs in 5.5 and the rest (800 or so) are still in 5.0. That said, here's what I wrote:
I’m trying not to mention things just because they are different. However, if the difference between the versions requires more work, I will point those items out. I will make the general statement that it is a very big change and the things that people are used to doing are in completely different places, but I view that more as a software upgrade issue rather than an issue with the web client itself. I’ll also say that I’ve been trying my best to accept the web client and I do 99% of the work I need to do there. It’s been a painful learning curve, but I’ve taken the time to learn where things are and to try and do everything within the web client.
Let’s start with the things that I do like about the web client, in no particular order:
Now the issues, again, in no particular order:
I'm sure there's more, but this is what I was able to come up with at the time.
i still never use it. I use the fat client and it is rare that i use the web client.
The UCS plugin for the web client crashes Infrastructure Navigator.. Have you noticed that? Not that the UCS plugin is something to write home about..
Just for kicks I tried yesterday to force myself to use the web client. All I wanted to do was kick off a simple scan of Update Manager to see if my hosts needed patches.
It said it was 'starting' the task and just sat there forever. Nothing ever happened. Looking in the fat client I saw that it made no attempts to scan the host for patches. In short it didn't work.
Then I tried to look at my vShield / Endpoint settings through the web client.....no where to be found.
Web client is garbage.
Let's simplify things.
1) Send out a survey request to all vmWare customers who have used both the fat and web clients. Give choices of whether to keep or abort it, sustain both, go web only. (with optional comments)
2) Post the results. This way we all know if we have been listened to.
That would be nice Nasshan, I pitched VMware to my current company back in the ESX 3.5 days, since then we have spent an ungodly amount of money for VMware. I would like to think my opinion is valuable to VMware but in reality I know better. I can tell you this I wouldn't pitch VMware anymore. If and when I move on in my career and they are looking to virtualize systems I would voice my suggestion for Hyper-V over VMware at this point. The on going cost of VMware for support is insanity not mention that vSphere seems to get more buggy/slow/cumbersome ect.. on every release. Remember the nightmare rollout of SSO with vCenter, how many updates to the updates did they put out before they got it half right!? THANK GOD we held off on upgrading vCenter after reading horror story after horror story on these forums. Eventually they got most of the upgrade woes resolved and that's when we finally upgraded.
Remember way back when no one would install Microsoft service packs as soon as they came out because everyone was afraid of it blowing up their machines? Then MS would release an updated SP that fixed the issues. Kinda how I feel about VMware's updates now. No first adopter here anymore. Now I sit back and watch the carnage unfold on the forums and wait to upgrade vSphere. Lets also not even get started on VMware's HORRID documentation that contradicts itself and points to other documents that can put you in an endless loop.
WessexFan wrote:
The UCS plugin for the web client crashes Infrastructure Navigator.. Have you noticed that? Not that the UCS plugin is something to write home about..
Yep, we ran into that. Ran it for a few weeks and uninstalled it. The UCS plugin kept unregistering itself as well, so I just dumped the entire thing.
Another issue I ran into this week was in setting up replication for SRM. There are some features only available in the web client. And others only available in the C# client. Personally, even with the slowness of the web client, I would be happy if all features were available in one place. The hybrid environment just means more programming time, more management time, and more frustrated customers.
Lets also not even get started on VMware's HORRID documentation that contradicts itself and points to other documents that can put you in an endless loop.
I agree the documentation needs some work as well. There is a lot of good documentation, but it's in the midst of a sea of outdated and/or superseded documentation, leading to lots of confusion. Add to that many or most KB articles don't specify which versions of ESX/ESXi/VMware do or do not apply. Sometimes I've followed procedures thinking, "I sure hope that step 7 is something that still exists in my environment and wasn't done away with in 5.0."
I concur with the criticism of the vSphere Web Client, here's another list of flaws that I don't think have been mentioned previously in this thread:
This is just a couple of things from the top of my head, I try to avoid it as much as I can... I have to use it with VSAN, which is another story in all..
I would also like to add that currently the custom SCSI LUN display names do not show up in the web client for the advance disk chart view. It takes us longer to figure out which SCSI LUNs are what without the custom labels. I hope this is added in the next release. We have to go back to the C# client because of this. Thanks.
What VMware needs to do to convert the vSphere Web Client haters
Does not reflect the latest statement about supporting C#-client for one more release (published just a few days before), but otherwise very nice summary...
Well, this is beginning to feel like U.S elections where we end up having to choose between awful and terrible, while the ones with the solutions are ignored.
So, if we find ourselves stranded with the web client..... is there any possibility that vmWare would allow 3rd party developers to provide fat alternatives?