As a dual-use Developer and Administrator, my company purchased a Dell Precision 490, dual Xeon, 8GB memory, with Windows XP x64 pre-installed specifically so that I could run VMware. I configure and preload VMs on my workstation, then deploy them to the appropriate VMware servers. Please don't speculate when you have no data.

There is only one reason to use a 64-bit workstation, and that is for large memory support.

What is being called into question is VMware's rational in removing support for the VI Client on 64-bit workstations. Their justification is that they want to ensure a high-quality product on the 64-bit platforms, and the previous VI Client had known issues on 64-bit platforms, so they removed and enforced support until they have time to get 64-bit right. This should not have been a significant issue, since they feel that there are very few 64-bit platforms running the VI Client. In opposition, the user community appears to believe that the per-capita use of 64-bit workstations for VMware administration is significantly higher than VMware claims, and that VMware should have not have removed the unofficial 64-bit support from the VI Client.

Speaking as a Developer, 64-bit OS support isn't real hard to put into your programs - you just need to be aware of the differences while coding. It really helps to make your developers use a 64-bit platform during development, where the 64-bit differences become real obvious when they try to run the program

Speaking as a Tester, 64-bit OS support is significantly harder, because you double your test time by adding the 64-bit platform to the test cases.

As a paying customer, I do find fault with VMware's logic. Imagine if the same scenario occured with a new release of Microsoft Exchange, which required a new Outlook, and the new Outlook wouldn't install on your 64-bit workstation, denying you access to corporate Email !

Once again, Kudos to VMware for agreeing to officially support the 64-bit environment in the next release, but a backhand slap for taking the unofficial support away in the meantime. If an interim patch is 'in the works' as Mr Kemp stated, the user community would appreciate hearing a projected release date.

"I thought this had died down, at least over the holidays! Everyone take a chill-pill." Love it... LOL

My point is, has been and will continue to be... VMware is constantly having to react and respond to issues, like this, that should never have gotten out of their QA process. I want VMware to improve their process internally so that we, the clients of their solutions do not have to deal with this type of thing again, and again. This is not to say that VMware does not do honest effort to get something fixed, reactively. VMware does not have a good record on avoiding problems that should not have gotten through the QA process internally. The entire ESX 3.0.0 release window, the weeks/months after its release was such a situation.

As for anti-Microsoft, their actions speak louder than words, or works for that matter. I will leave it to the majority to decide, or future history to define it.

Having an AXE to grid? No, I am 100% behind VMware and have been since ESX 1.5.2. But I expect better of them, they should learn from their mistakes and those that others in past have made, in reference to being better than what customers expect. If an organization beats expectations of quality, scalability, stability, and consistency, then profitability comes by default. Microsoft is only a threat based on quality, scalability, stability, and consistency. Look at Novell Netware, in many ways, it was a better solution Netware 3.x/4.x time frame, with the lead in LDAP, so how did Microsoft catch up? Moreover, any Microsoft coding hobbist that knows Windows Installer 3.1 via the Visual Studio IDE, would not have made this mistake. VMware did, and they should get some heat for it.

As for you last comment... "any other ISV" maybe... valid point. Not withstanding, I have higher expectations for VMware, and I should, they are the best for now and to stay the best, they should not make these types of obvious mistakes, and they have made some big ones in the last 2 years.

We, as a community of customers, have been toooo forgiving for toooo long and I think the comments others have made, beyond my views, support that perspective. If we, did not wish VMware success, we would not have taken the time and effort to provide the feedback we have in this very thread.

I just wanted to throw in my voice to this discussion.

I think that not releasing a working 64-bit VMware Infrastructure Client was a big snafu on VMware's part. How are you supposed to convince new customers that you can make a solid 64-bit environment when you can't even code a working 64-bit client? And what do you tell 64-bit OS users to appease them? "Sorry, we didn't think there were enough of you so we didn't bother." Come on, that's about as professional as telling your customers to take a "chill-pill."

While there may not be a majority of 64-bit users out there at the moment, there are a lot. For every one of us that voices are complaint on this community there are probably a hundred brooding VMware users angry that they can't use VIC 2.5 on their shiny new Vista laptop or desktop. And when we finally are told how to work around the issue we are told to follow processes that involve installing the Windows SDK and Visual Studio, or to create a 32-bit virtual OS and run it from there. It is, quite honestly, unacceptable for a company of VMware's size and market position.

Do you realize that Hyper-V is breathing down your necks? What do you think people will do if something like this occurs when Hyper-V R2 comes out with every feature of VMware Infrastructure?

I could go on, but I think that covers enough of what I want to say. VMware does make some fantastic products, but I have been very displeased with the lackluster 64-bit application support (besides this, VMware Server 2.0 Beta comes immediately to mind).

Andre, thanks for the update!

Doesn’t help if you are running 64 bit Windows on your Citrix servers!