VI Client 2.5 only supports 32bit OS?

[jprior]

Working through my ESX 3.5 / VC 2.5 upgrade, I download the new VI client onto my workstation (Vista x64 Enterprise) and receive a lovely error message that "This product be installed only on 32-bit operating systems."

Why was that broken? VI client previously worked fine on x64, now it doesn't? Anyone have any workarounds to get it to run on x64 yet?

[RParker]

Yeah, but it didn't prevent install on 64-bit. Now they specifically try to keep you from installing on 64-bit.

So it wasn't supported, but at LEAST it installed and worked...

[RParker]

> Personally I think the big issue is that it only runs on Windows.

I'd love to see the client run on Unix/Linux; if VC could at least use MySQL or some other non-Microsoft db, would be awesome (VC on Unix/Linux would be even better); ANY Macintosh support would be fantastic

Hear Hear!!

That's because it supports .NET. The Database part is a non-issue, they could easily use ANY database, they just wrote it to interface with SQL, but the database could be hosted anyplace.

It would be nice to have a Linux (or non-OS) version.. just java based would be lovely. Macintosh would be awesome. I agree, they need to quit being MS only development, and start toward open source.

[jprior]

Wait, you're gonna flame people asking for 64-bit support claiming that its a tiny minority, and then advocate an even smaller group by asking for Linux / Mac support? That seems to be a bit of a double standard.

Though a full java instance sounds interesting, did you mean like the recent Java 'OS-less' webserver?

[nathanbach]

Actually I do work for an Enterprise company and my guess is you've never seen the inside of a datacenter. 100% of the Fortune 500 run most or all of their infrasturcture with 64-bit OS on their servers. Ever heard of Tru64? It's been around since 1988 not to mention Solaris, HP-UX and on and on. I work with many of these types of companies and ALL of them run 64-bit Linux in some capacity as well as a ton of UNIX.

You're focusing on the client experience. VMware is an infrastructure product.

[mrudloff]

Even if ViC 2.0 wasn't supported on x64 - it worked at least .. 2.5 doesn't even let you install it which is bad practise ..

Vi is an Enterprise product .. no private person will ever use ESX (legally anyway), a company is more likely to use 64 Bit.

We HARDLY install 32 Bit OS' so now we had to install a 32 Bit server so we can remote desktop to it ...

This is just painful .. I have to connect to the Vi environment remotely when I am traveling ... since G3 isn't really highspeed, I had to install a virtual machine on my (64 Bit) laptop so I can use the vi client ..

Its so far pretty much the first "bad" thing I encountered with VM - but by far the most painful one ..

(oh and the webinterface is no option)

[jprior]

Yes, I am quite pleased that the most problematic part of running VI3 for the last 15 months has been this issue. Quite a nice change from some of the other vendors I've worked with, and certainly the VMware employee's participation in this thread has been better than most - instead of 'SOL, do it our way' there is a recognition that there is action they can take, and a plan to work towards it.

[mystereman]

I can tell you dont' work for an Enterprise class company, because that statement is so wrong, I don't even know where to begin.

Even if you were correct, how does working for an enterprise class company or not affect whether or not there is a need for a client that runs on 64 bit OS's? Enterprises are not the only ones using VI.

Companies use what works, not what people WANT.

Yes, and if you need more than 4GB of memory, 32 bit OS's don't WORK, regardless of what you WANT. There are many 64 bit OS's being used in enterprise environments, and not just servers either, but even if it was just servers consider that many admins do their work from servers.

Fact is, 64 bit is becoming very popular as memory requirements grow. For instance, many large companies have large drafting and CAD/CAM departments that need 64 bit OS's to access the 8, 16, or even 32 GB they need for their high end CAD/CAM systems. Microsoft makes a number of 32 bit apps now, not just Exchange and SQL. In some cases, they ONLY make 64 bit versions, suc as the Office 2007 Groove Server. There's also 64 bit Sharepoint and Office 2007 Forms server, Visual Studio 2008 has a 64 bit version, etc..

64 bit hardware is NOT buggy. Maybe some drivers are, but my experience has been that they're pretty solid.

The fact of the matter is, many admins run 64 bit systems. A solid reason is because they have VMWare Workstation or Server on their desktops with 8 or 16GB of memory so they can test various configurations and create images for their deployments. And, since we're talking about a piece of software that is primarily an admin tool, the number of 64 bit users are going to be much higher per capita than in general populace.

[david_hittner]

They are trying to get a new product out, why complicate the issue with 64-bit support for systems that probably don't even FULLY support it. I bet even your machine was installed BY YOU to install 64-bit OS... I will be willing to bet it didn't come that way.. You are EXACTLY the reason VM Ware is trying to steer you to stay on 32-bit until they can fix their issues.

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.

[Schorschi]

Bottomline, VMware screwed up. They are so anti-Microsoft, it impacts their thinking. If you do not believe this, talk to the development teams for VC, VMotion, iSCSI, and ESX, and also Workstation. I have, multiple times with each group, I can tell to the individual in meetings I have had that our feedback is listened to, but rarely acted upon, nor does VMware really want any customer input, their actions speak volumes on this point. With the exception of the Workstation team, the under current of anti Microsoft pro anything else is so strong you can almost see it creating the rose-color tint that the eye-glasses of the same name have. The response to customers, asking for better integration to Microsoft environment is in a word horrible.

Look at the perl based VI toolkit, for esxcfg-* and vicfg-* commands, none of these commands are in the VI windows powershell based tool kit? What the hell is VMware thinking? That Windows Admins will lern perl? Our Windows security group is screaming about Tomcat, and lack of ESX AD integration that is an open-source based, now we have to tell them we need another scripting language to support 3i, and perl of all things? Using Tomcat not allow IIS, not integrating VC with AD as an integrated application, etc., etc. We have been asking VMware to stop this crap attitude for years, yes, years. Specific to my experience since late 2002!

To be honest, I hope the next version of SCVMM (Microsoft System Center Virtual Machine Manager) kicks VirtualCenter in the teeth. The only thing at this point that is going to get VMware to respond effectively is to lose money, at a significant level. Unless Microsoft completely screws up, again, cough, no Microsoft-VMotion? VMware is pushing us to look at Microsoft again, and every other virtualization solution out there, frankly we are really getting tired of this junk coding and QA so weak it is a joke VMware keeps pushing on us.

[admin]

All,

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

I'm please to annouce the "fix" is underway. The chap I talked to said he should have it done by Wednesday - before he went on holiday - but he is swamped trying to finish up his priorities. I'll ping him again and see where we are, but it is coming.

On another note, VMware does NOT have an anti-ms position. Frankly, the entire community would be better off if they embraced virtualization rather than hinder it. Gone are the days of dominate OS players - the trend is to run as much as possible regardless of the platform. The whole idea of v-management is moving in that direction as well. Finally VMware wll updoubtedly have competition, which is good for everybody - keeps us humble in my view. But it seems some people may have an axe to grind no matter what we do, so we just try to do the best we can.

I do know one thing, any other ISV probably wouldn't have even tried - so you can take or committment to this issue as genuine.

Regards,

Andre Kemp

Sr. Product Marketing Manager APAC

--

Pardon the brevity, sent from my handheld

[halr9000]

Look at the perl based VI toolkit, for esxcfg-* and vicfg-* commands, none of these commands are in the VI windows powershell based tool kit?

If you've talked to the VMware devs so much, you would know that this functionality is forthcoming. Don't forget--VMware is one of the very first 3rd party companies to provide a PowerShell interface. That's pretty pro-Microsoft.

[Schorschi]

"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.

[tfrache]

Hi,

on my lab, I removed the condition which disable installation of the VIClient on Vista 64 (using Installshield 2008). The product can now be installed on vista but I cannot test myself because the SSL/VPN we use does not work on Vista 64 and I cannot try to connect to our ESX farm! I'll update the thread next monday (or before If a guy of my team can test himself this week-end).

Actually, I don't understand why the installation is blocked on Vista 64 has the product can be run on this operating system (see the picture I attached). However, I really don't know what it will happend if you able to connect to your ESX (maybe you'll get a blue screen or something like that). So If you want to test it by yourself, be carefull !

Thierry

[Jammrock]

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).

[admin]

All,

Here is the update on this issue. Look for 64-bit client support in Update 1 of our ESX\VC products, which will occur this quarter. A full true 64-bit client will occur later this year.

Andre Kemp

Sr. Product Marketing Manager - APAC

[Schorschi]

Andre, thanks for the update!

[TheRealJason]

Andre,

Can we expect a patch to be released even sooner? I've got a brand new Dell Precision on my desk, running Vista 64-bit, and would love to be able to run the client from it.

[jprior]

All,

Here is the update on this issue. Look for 64-bit client support in Update 1 of our ESX\VC products, which will occur this quarter. A full true 64-bit client will occur later this year.

Andre Kemp

Sr. Product Marketing Manager - APAC

Thanks for the update, though I am disappointed you didn't follow up on the previously mentioned 'Wednesday' ... to be fair you didn't mention a date :smileylaugh:

By 'Full true 64-bit client' you mean a .NET 2.0 x64 compiled application? .NET 3.0/3.5?

:_| Curse our luck this is a leap year, we now have to wait an extra day to the end of the quarter! :smileylaugh:

[Phudodragon]

Like other techs, I was a bit annoyed that VMware didn't provide us with a 64 bit client. However, they did provide me with the "opportunity" to come up with a temporary workaround. To get around the "64 Bit" issue I installed Virtual Center Client 2.5 on a tools server in our Citrix environment. I now run the client from my desktop using a Citrix published application.

Hopefully, this little work around can help someone.

Phudodragon

[TheRealJason]

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