ESXi

When will be vSphere client compatible with Windows 7? or is there any way to connect to vSphere server or vCenter server???

http://communities.vmware.com/thread/211440

The thread posted is titled "vsphere client on Windows 7 rc". Windows 7 is well past RC stage at this point. It is not only been released to manufacturing, but has actually been released to corporate customers worldwide.

This is no longer an issue with the vSphere client not working with a pre-release product, but that the client does not work with a fully released, readily available version of Windows. An estimate of when they will be providing support would be nice.

Yes. This is wholly unacceptable. While I would say the blame rests on Microsoft for causing the issue, there is no excuse for this to still exist over 6 months after discovery. Fix the damn software. We pay a crap load of money for this stuff.

I'm in the same problem.

Is incomprensible how the client works well in windows Vista and now in Windows 7 (wich is supposed to be more compatible) doesn't work. I installed yesterday windows 7 in my computer and has found many things that worked in Vista and now fails. Bad from Microsoft too....

salu2

Well, specifically, the issue is with a the new revision of .NET we get with windows 7. It appears there is a linking issue in one of the DLLs. I would definitely say Microsoft dropped the ball here, but thats nothing new for .NET. On the other hand, Since this has yet to be patched, and other software seems to be fine... maybe vmware screwed up some how. Hard linked to an ordinal maybe?

That being said... EMC/VMWARE is a big company. Microsoft listens when they talk. This should have been addresses when it was discovered back in april!!

I do find it interesting that the only even somewhat recent application I have found that will not work in Windows 7 is the VI client. I was involved in the Tech Beta for Windows 7 and Microsoft was very insistent on asking for people to report any application or driver incompatibilities so that they could either fix the bug on their end or work with the vendor to get the code fixed. MS specifically did not want to go down the same path of Vista and have a product that launched with compatibility issues. I have to commend them for making this concerted effort. It resulted in amazingly compatible OS. Based on this experience I am amazed that VMware seems reluctant to fix their bug. Yes Microsoft changed .net, but lets face it .net is theirs to change, and the changes didn't seem to break anything else, so it points to bad code on the part of VMware.

I guess the thing that is so astonishing to me, is that the Win7 beta was out and readily available to anyone at the time, long before the flawed VI client was released. How could they have ignored the issue? The final version of Windows 7 has been out and readily available for over a month now. It may not have shipped to consumers yet, but lets face it, the bulk of ESX customers have an SA agreement and have Windows 7 in their hands. The most likely people to run Windows 7 on their desktops are the same customers VMware courts for ESX (early adopting techs) VMware needs to seriously get their act together and release a patch, this is getting absurd.

Half my job is assuring people that VMs are reliable and robust, I jokingly refer to myself as a VM evangilist. It's hard enough to "sell" the idea of VMs to reluctant old-school techs, but having blatant incompatibilities does not help me instill confidence in the product.

Running the vSphere Client on Windows 7

• Copy System.dll (%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\) from a non-Windows 7 system with Microsoft .NET 3.5 SP1 installed to the Windows 7 system.

• Place the file in C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib\.

• Edit the VpxClient.exe.config file (C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\). Add the following: <runtime> \\ <developmentMode developerInstallation="true"/> \\ </runtime>

• Add the DEVPATH variable via Control Panel → System → Advanced System Settings → Environment Variables to both the User Variables as well as the System Variables. DEVPATH=C:\Program Files (x86)\VMware\Infrastructure\Virtual \\ Infrastructure Client\Launcher\Lib

• Launch the vsphere client (may have to be admin).

This is NOT a fix, and I recommend that everyone avoid this solution. Do not mess with .net if you value your time. Manually staticly lnking in .NET dlls from mixedversion is a recipe for disaster. 3.0 was never designed to run under 7, and 7 was never designed to expect it.

The only possible enterprise deployable fix here is to get virtual center properly compiled.

In the mean time I'm running old xp virtual machines to handle management.

Well, if you base your application managment off of fear than you may want to listen to post, or you can put on your "Big boy" pants and go with logical, well tested work around which is the answer to the question ask.

I tried that fix and it seemed unreliable and flaky. The workaround is nothing more than just a workaround. It is not a real solution to a real problem. Running the VI client off of a VM or using RDP to another Windows machine is every bit as viable of a workaround and is actually supported and not in the least bit risky. That to is merely a workaround not a solution. Either MS needs to fix the backward compatibility issue that only exhibits itself in the VI client (something I am guessing isn't going to happen, since we all know MS was keenly aware of the issue with the VI client long before RTM and chose not to change it), or VMware is going to release an updated version of the VI client. The question still warrants a "Why so long?"

This is not a "logical, well tested workaround" and not something I would do in a production environment.

Anyone who wears "big boy" pants is not going to use an unsupported workaround for managing their production environment. I think it is unacceptable VMware has not addressed this, but until then, older versions of Windows will need to suffice.

If you want to play with this stuff at home that is fine, but that is not an appropriate fix in my opinion.

If you wish to do it, that's your choice, but I disagree with your statement that he is basing his reluctance to use that workaround (if you call it that) out of fear. I'd say he's the one wearing "big boy pants" by being conservative about this.

Anyway, VMware needs to fix this like yesterday.

I must agree that that is a very poor workaround. One of the steps involves making a modification to system-wide environmental variables. That's not something I'm willing to do to band-aid an issue with a single application.

Why is VMWare not showing any effort to resolve this problem? The buzz in the streets is that Windows 7 is going to have a very high deployment rate. Pretending it doesn't exist is not an option.

VMware -- when can we expect the vSphere client to be fully compatible with Windows 7? The RTM version of Windows 7 has been available to Enterprise for MONTHS and it's even available to consumers now.

Vmware is shambolic. VDR is complete donkey sh_t and you can't even get a Windows 7 client out when you would have had access to the RC versions and RTM many months ago.

I have to RDP into a vista box just to do my damn work.

I think we're being a little hard on VMware here... ESX isn't really their bread and butter and it doesn't make sense that they rush to meet the needs of their early adopting customers. We must understand that they have much more pressing priorities.

We should all be glad VMware Fusion 3 will be released tomorrow with Windows 7 support. This is truly where their prized R&D dollars should go. Not to fill the needs of a bunch of their keen early adopting customers.

Does anyone else find it funny that the only place VMware acknowledges Windows 7 is in the VMware Workstation or VMware Fusion space?

Uhm...what are you smoking? Give me a break! Get out of the ESX forums and go back to the fusion forums then.

I could see not having Windows 7 support during RC or before the official consumer launch date....but they should certainly have it by now. Honestly, they had well over a year to test this and make it work if you go through betas, etc. Why do you think Microsoft releases tech previews, betas, RCs, etc? It's for this very reason...so other companies can be prepared for when the product officially launches, their software will work with it. Most good companies have their software up-to-date BEFORE official launch dates. VMware has failed here.

VMware got where it is today by being lightyears ahead of the competition. They face some massive competition now...and if they want to keep their lead they need to stay ahead of the curve. This is not ahead of the curve...it's slow and reactive.

P.S. Fusion is VMware's bread and butter, not vSphere?!

"Uhm...what are you smoking? Give me a break! Get out of the ESX forums and go back to the fusion forums then." "P.S. Fusion is VMware's bread and butter, not vSphere?!"

Ever heard of sarcasm? Shit man it wasn't exactly subltle.

Maybe I should have used some <sarcasm> tags...

I fully agree with you obsidian009. It is absolutely absurd that this discussion even exists. VMware has really dropped the ball on this.

Combined with this issue and my EMC CX300 SAN not being on the HCL I'm really beginning to sour to VMware. It feels like VMware is turning there back on their core customer base when they need us the most. It feels like they released vSphere is May and have been partying ever since.

lol, sorry...sarcasm doesn't always translate over that well in chat, forums,etc when you don't know the person. I really thought you were off your rocker :smileyhappy: Glad to hear you're not!

VMware -- what's the word on this?!

Ok, I really thought you were severely misinformed :smileyhappy: I was wondering what you were even doing in the ESX forum :smileygrin:

I feel better, it wasn't just me that missed the sarcasm and thought you were crazy :smileyhappy:

I'm glad to see other people upset by this as well. They've had months and months to fix this problem but haven't. As mentioned before, this could have been tested during the beta phases, the RC phases, after it went RTM, or even between then and now. They've had months.

The glacial speed at which this is being looked at concerns me about what else might be going on within VMware.

VMware please respond.

I put in a support request about this issue earlier today and I was assured that they are working steadily towards releasing a fix. I was not given a time-frame, but I was told to keep an eye on the KB article that describes the issue ().

I realize this isn't a whole lot of new information, but I do feel better knowing that they consider it an important matter.

I have to agree with the sentiments here. At first I was just angry that VMware had not updated their client so that I could use it with the flashy new operating system. But, as this was just the first in the long line of product disappointments since the vSphere release, it's made me a bit concerned.

Can't they just release a ThinApp'd version of the client that doesn't have to be installed, and contains its own .NET libraries?

My guess is that the problem is so minor that figuring out a way to provide a free thinapp license for it would take more time then fixing the bug. It seems that lately VMware is concentrating more of their time and efforts into sending me SPAM than improving or fixing their products that we pay dearly for.

VMware, There was a reason that people paid a higher price for your product than the competitor's. Your product was reliable, worked, and offered better support. Now that you are showing that you really don't prioritize fixing the product for paying customers you can cross off the support and works off the list. I am already finding it hard to justify to the finance guys why you are worth paying more for, don't make it even harder!

The problem is that ThinApp does not work on Windows 7 right now.

This is getting ridiculous. Since the vSphere 4 release I have had not one, not two but three issues of critical severity like this one (this is actually the most moderate of the three). I don't understand what is causing VMWare to change for the worse like this, but it's truly astonishing and very frustrating.

VMWare products are ridiculously expensive. Problems like this add insult to injury.

That I still have to use the vSphere client from inside remote desktop even after Windows 7 GA (and with very annoying performance problems) is borderline unforgiveable.

We run a Microsoft shop and my team has been pushing me to evaluate HyperV. I think I have just reached the point where I am willing to do so.

-Joe

I'm very wary of Hyper-V. Virtual infrastructure is not a place I'd like to get locked into a specific vendor with. Don't forget that there are quite a few hypervisors out there at the moment. I recently spoke to someone who switched from VMWare to VirtualIron and has been very happy with the transition. Xenserver is also an option. I've been waiting on Sun's XVM server for some time now, but it looks like vaporware at this point.

Why is Microsoft HyperV vendor lock-in any different from VMWare vendor lock-in?

It's not, but I trust VMWare more than I do Microsoft when it comes to that sort of activity. I've been burned by in the past with Microsoft software and I've yet to have many bad experiences yet with VMWare.

Actually, I have far more trust in Microsoft releasing compatibility updates within 6 months of a problem becoming apparent. As lousy and unresponsive as Microsoft is, I could never imagine them being as lazy and/or incompetent as VMware has been in this regards. I too am being pressured into investigating Hyper-V, and I am running out of arguments, especially when VMware pulls crap like this.

Exactly. I have never had a critical issue like any of the three VMWare issues that I mentioned previously that Microsoft did not scramble to fix or develop a workaround for. I have simply never faced a Microsoft problem that had no solution (excluding problems that could be classified as feature improvements).

Microsoft may be the evil empire but they run their empire pretty well, certainly better than VMWare.

I understand your point about other Hypervisors, but the biggest difference is that for many ESX customers the switch to Hyper-V is free in regards to licensing. We are a Microsoft shop and literally could switch to Hyper-V without any additional licensing fees whatsoever. So yeah, it may not be the best solution, and it may have its shortcomings, but it is literally infinitely cheaper than ESX in regards to licensing and support. Paying many thousands of dollars for support agreements gets frustrating if you aren't getting the support you expect for the price. With Hyper-V lower cost of licensing = lower expectations.

Our company chose to buy the BMW of virtualization packages so to speak, now we are getting the runaround I would expect from the Hyundai dealer. Next time I might as well switch to a Hyundai and save some cash.

Sparrow wouldn't you get sick of the whine from that Hyundai? :smileygrin: We have been an ESX shot since the good old GSX days. While there have been some errors along the way and the growing pains that go with it, for the most part these have been few and far between.

That said, having the VMware tech's tell you that Windows 7 isn't supportted and the work around is to install a VM of XP on the laptop I use for work really seems crazy to me. I'll just continue to RDP to my VCenter hosts until a correction is made. I hope it happens before January :_|

Mike

Oh I agree, but better to have a whiny Hyundai, than a BMW that takes 6 months in the shop for something as simple as an oil change (not saying BMW service takes this long, saying that VMware does). I have been running ESX for many years now, I have been hired on to two companies specifically to implement a virtualization environment. I have chosen ESX every time due to unquestionable technical superiority. I attended the "Hyper-V" launch last year and was not dissuaded even though it is essentially free. However, this incredibly lame response from VMware has indeed made me question their technological prowess. If they can't manage to get their management client to run on Windows 7 within 8 months of it being brought to their attention, well that is just plain idiotic. The amount I budget towards VMware support is not insignificant, and quite honestly, I expect better support than this. VMware has dropped the ball on this one, not only that, but they seem to refuse to pick it up. Every time I need to get into vSphere I curse a little, disgusted at VMware's lack of follow-through. It just so happens that this is several times a day for me. So what was once a minor annoyance, has built in to a full on aggravation. Instead of being able to use my multi-monitor setup for managing our VM deployment, I am stuck in a RDP window. I could revert back to XP or Vista, but I am not going to, because I am not going to stay behind technologically just because VMware is unable to be flexible to change.

I 2nd that...

Windows 7 is now out to the public. When will we see vSphere Client fixed to work properly with it? This is a wholly unacceptable situation.

I simply want a statement from VMware acknowledging that they're working on it, along with a time frame as to when we might expect it.

Looks like this was finally resolved with vSphere 4.0 Update 1

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1011329

The resolution is to Install XP? This is a resolution? Oh, wait, or you can bypass .NET framework? FIX IT!

Like the last user said. It is fixed with vSphere 4.0 U1. I run Windows 7 x64 and have no issues connecting to a vCenter 4.0u1 server without any work arounds.

• Kyle

OK, but I'm not running Update 1 on my ESXi servers. I cannot find a location to download the client files for Update 1 from in the Download center, because it is bundled with the installation, correct? So, how do i upgrade a client to Update 1 without bothering with the mess ESXi 4 Update 1 creates on my production hosts?

If you download the vCenter (not ESXi, even though it might still have it) 4.0 U1 disk the installer is there for you to pull off. I forget the exact location but there is a "vmware-viclient.exe"

• Kyle

OK... seems messy. You'd think that due to the Windows 7 compatibility, VMware would make a separate download available to specifically address this concern, as it's been almost a year. To resolve this issue for users running ESXi 4 w/o Update 1 in a nutshell:

1. Download a 350 MB file, extract the files, search for the client.exe file, distribute it to users running Windows 7.

2. Run it without .NET support.

3. Run it on Windows XP.

Messy, but true, right?

If that is your outlook on this situation, so be it. This is starting to fall under the catagory of "why doesn't my unsupported driver work, VMware should add it so 10 people can use this 5 yr old server", granted the origional problem was a bigger problem than that. The whole .NET / Run in XP was a workaround until update 1 was released, but the point now is a fix was released. If you don't have a vCenter server, and running free ESXi then there are things like this you'll run into, the price of being free. If you have a vCenter server, upgrading your vCenter server to Update 1 is a pretty painless process which can be done during the day and then you don't have to distribute, they can just upgrade from the vCenter server.

I really don't see how downloading a CD and pulling off a 141MB file and distributing it on a Net Share/USB/CD is really that big of a deal until you upgrade your servers to U1. I'm not here to debate VMware's patch releases, their work-arounds, or how we think they should run their company, my origional post was to state that - Using the VIclient from 4.0U1 runs fine on Windows 7, end of story.

• Kyle

ESXi 4.0 is 5 years old? Really? If a software package needs to be updated to be compatible with a new OS, distribute as such, separately. It's a no brainer, tried and true for 20+ years. I guarantee there are dozens of SysAdmins like myself who are asking 'How can I allow my VM Admins access to ESXi with my new Windows 7 machines easily?', search the chasm and find the same answer: Use XP, forego .NET, or install Update 1. Oh, or patch .NET and rewrite the shortcuts to the console on a dozen workstations. It's clear the easiest answer is 'Download the Updated Client Installer here'.

I appreciate your loyalty to your vendor. Most companies like to make things easier for their users, though. I did take them 6+ months to fix it in the first place, right? Say what you like, but you're not correct.