vSphere requires a 32 bit DSN

[RParker]

When you get around to installing vSphere, if on a 64-bit Windows host in x86 compatibility mode, a 32-bit DSN is required for the database connection.

If a DSN has been set up through Start > Administrative Tools > Data Sources (ODBC) the vSphere installer won’t be able to use this DSN.

The 64-bit ODBC Administrator tool can be invoked from Control Panel to manage user DSNs and system DSNs that are used by 64-bit processes, but for 32-bit datasources, the 32-bit ODBC Administrator tool is used for Windows on Windows 64 (WOW64) processes.

To set up a 32-bit DSN launch the 32-bit version of the Data Source Administrator. It is located at: %systemdrive%\Windows\SysWoW64\Odbcad32.exe

OK, now that we have that covered, my only question is WHY?!?!?!? 64-bit vCenter, 64-bit OS, 64-bit SQL Database, ESX is now 64-bit.. so why the 32-bit limitation.

We take two smalls steps forward to take one GIANT leap back.. And I have to ask, what is VM Ware doing? Why oh why can't this be MORE thorough. This is mind boggling at the hoops to make this work, it's truly backwards.

[stvkpln]

Uhm, I hate to break it to you... but, vCenter itself is NOT a native 64-bit application. Go look at the process list, vpxd is clearly running in 32-bit mode. That's been fairly consistent with how it's ran since beta 1 of 4.0. It kind of makes sense, actually.. Not everybody is ready to, or wants to go x64 for VM's unless there's a reason to do so, so being able to install on either a 32 or 64-bit O/S is kind of handy, don't you think? Frankly, I really don't think it's a step back to have to create a 32-bit DSN.... Just requires a little bit of RTFM. Can you elaborate on what isn't thorough enough? The documentation clearly tells you what to do. Is your point of frustration that vCenter is not yet a completely native x64 application?

I don't work for VMware, just a curious bystander scratching my head in confusion as to the real problem here?

[RAMESA]

vCenter Server/Client is not 64bit it is still 32bit. That is the reason why you need 32bit dsn for connection. So current vCenter Server is compatible with both 32bit and 64bit server and documentation is very clear. Is there anything unclear or confusing about documentation?

[Geoflex]

I have the same question as Parker.

What is the reason for using a 32 bit DSN. If the OS and Database are 64 bit, then why using 32 bit DSN? Is that means, Vcenter is not a true 64 bit application but made it such a way that it can be installed on a 64 Bit OS?

Are there any perfromance gain by having this? I'm looking for a clear answer to the reason for using 32 bit DSN.

Thanks

DC

[RParker]

Uhm, I hate to break it to you... but, vCenter itself is NOT a native 64-bit application

Well that's obvious NOW. But vM World 2008 painted a VERY different picture. They said that EVERY Thing would be NATIVE 64-bit, maybe they couldn't do it, but I was under the impression this OLD stuff was behind us, aparently not.

Go look at the process list, vpxd is clearly running in 32-bit mode. That's been fairly consistent with how it's ran since beta 1 of 4.0.

That's wonderful for YOU beta testers, it's NEW to me AND all new users, but thanks for pointing that out. I will take it under advisement.

Not everybody is ready to, or wants to go x64 for VM's unless there's a reason to do so, so being able to install on either a 32 or 64-bit O/S is kind of handy, don't you think?

Handy? I think maybe as a kludge for VM Ware to get around the whole '64-bit' Readiness thing. And I hate to break the NEWS to YOU but 64-bit is MORE than ready, since 2004. Maybe even before. We are MORE than ready, hence Vista, XP 64-bit, Windows 2003 64-bit... want me to keep going? It's been around long enough for the System Admin community, and you are in the minority.

Maybe not everyone is ready for 64-bit, but vSphere won't be installed by EVERY body it's installed by TECHs. WE TECHS want 64-bit. Ask any tech, I will bet you that the MAJORITY of techs use 64-bit on their desktop, and I would be willing to bet that pretty much ALL but a VERY few machines are 32-bit ONLY. Maybe VM Ware isn't ready, but don't give me this song and dance about how the 'user community' isn't ready, because that is complete HOGWASH.

Apple is coming out with 64-bit OS (completely) do you read trade journals? They talk about Vista 2 years ago.. being 64-bit, and 'when are the 64-bit apps coming out?'. How long does it take? VM Ware isn't ready, but that DOESN'T preclude that the REST of TECH world that uses server are NOT ready for 64-bit because we have been waiting for AT LEAST 5 years... Intel is getting agitated as well.... Developers are the problem, not people in this case.

Frankly, I really don't think it's a step back to have to create a 32-bit DSN

Spoken like someone that doesn't understand ODBC... Windows 2008 takes care of this, it's backwards compatible, that's my ENTIRE point. VM Ware didn't take this into account, and like you said their APP isn't 64-bit. Well that's lovely. Now that I know this, I guess we will wait for VCenter 2012.. maybe by THEN it will be 64-bit, and give everyone else a chance in Virtualization to catch up, pass, and take over VM Ware, that's fantastic!

Just requires a little bit of RTFM

I READ TFM. Thanks. I even googled it for good measure. The point isn't that I did NOT help myself, I even made a post in case it would help someone else. The point is WHY!?!?!? 64-bit should be ready. What is taking so long. (Before you answer I work for a development company, I already know the answer). I am being rhetorical.

The documentation clearly tells you what to do

Thanks! my second grade teacher will be glad to know my comprehensive skills didn't go to waste! Thanks for pointing me to something I have already done, since clearly I already set VCenter up.

Is your point of frustration that vCenter is not yet a completely native x64 application?

Frustration? haha.. you misunderstand my dear boy. No not frustrated at all, another poster on this same forum even agrees.. What is the point to come out with something new if it's NOT going to be well... NEW! I am not frustrated, I could care less. I think it's backwards that VM Ware wants to 'lead' the VM game, but they are still using tapes when everyone else is on much newer technology. It works, it's done. I am glad its working....

I don't work for VMware, just a curious bystander scratching my head in confusion as to the real problem here?

You are a guy that drives your little car, and you don't care that you listen to a radio broadcast signal when there is sattelite technology and CD's and iPhones with Sirius.. you don't care as long as you can hear the oldies station, right? No problem, until you wake up one day and realize that the world has past you by....

There is no problem, where do I say there is a problem? I asked a simple question, why no 64-bit? VM World had us thinking that VM Ware was FINALLY going to lead the new millennium, I see now they aren't ready.

[RParker]

vCenter Server/Client is not 64bit it is still 32bit.

Yeah, and why is that?

So current vCenter Server is compatible with both 32bit and 64bit server and documentation is very clear. Is there anything unclear or confusing about documentation?

Nothing is unclear, not confused, angry, upset or even miffed, curious (and ranting) how OTHER products (we won't name the Hyper-V, Zen, Solaris...oops... I mean competitors..) have 64-bit, even before ESX 4.0 came out.. clearly THEY see the future.

[RParker]

Are there any perfromance gain by having this? I'm looking for a clear answer to the reason for using 32 bit DSN.

And that's my point.... I think those other 2 must own stock in VM Ware.....

[tcutts]

vCenter Server/Client is not 64bit it is still 32bit.

Yeah, and why is that?

Possibly because it doesn't really matter. Making an application 64-bit makes it use more memory (because all the pointers, and many other datatypes, in its data structures double in size). If you don't need >2GB of RAM for your application -- and vCenter isn't anywhere close to that big -- then there really is no need to make the application 64-bit. You'd gain nothing, and probably lose some performance. OK, so 64-bit end-to-end might be "neater" but that's about it.

Tim

[RParker]

Possibly because it doesn't really matter. Making an application 64-bit makes it use more memory (because all the pointers, and many other datatypes, in its data structures double in size).

It doesn't matter? Hmm.. you haven't used 64-bit Apps for very long have you? Anyone can see they are MORE robust and work better than 32-bit. Look at vSphere, it WAS 32bit before now, NOW the performance is much better, coincidence that it just HAPPENED to be when they converted to 64-bit? I think not.

And why do companies that HAVE 64-bit products make it a POINT that they offer '64-bit support'? Yeah it doesn't matter? Only for people that don't pay attention to new technology.

and vCenter isn't anywhere close to that big -- then there really is no need to make the application 64-bit. You'd gain nothing, and probably lose some performance. OK, so 64-bit end-to-end might be "neater" but that's about it.

Are you reading the fluff or technical manuals? That's not it at all.. 64-bit isn't the next buzz word it's the FUTURE for existing technology. AND my point is if they made the rest of the products 64-bit why did they leave these out? Forget about the ideal way to provide more software and better features, it should ALL be compiled on 64-bit so we don't have to flip flop or use something else (like a 32-bit DSN on a 64-bit OS) ESPECIALLY when 64-bit DSN is backwards compatible....

Yeah you can defend 32-bit all you want, for the people that KNOW the true difference, there is more to it than just doubling the number.

[tcutts · Accepted solution]

Possibly because it doesn't really matter. Making an application 64-bit makes it use more memory (because all the pointers, and many other datatypes, in its data structures double in size).

It doesn't matter? Hmm.. you haven't used 64-bit Apps for very long have you?

No, not long. Only 10 years (IRIX 6.4 on SGI Origin servers, and Digital UNIX on Alphas). You've assumed, with no knowledge of who I am, or what I do for a living, that somehow I'm an ignoramus who doesn't know my arse from my elbow. Well, I've got news for you. I run one of the world's largest supercomputers for a living, it's been 64-bit since we started, because we've need applications to use more that 4GB of RAM (we had a system with 256GB of RAM back in 2001). In other words: I do know what I'm talking about.

Anyone can see they are MORE robust and work better than 32-bit. Look at vSphere, it WAS 32bit before now, NOW the performance is much better, coincidence that it just HAPPENED to be when they converted to 64-bit? I think not.

They've had time to fix bugs. Moving from 32 to 64 bit is completely irrelevant to that. It's just as possible to write good stable code in 32-bit as in 64-bit.

And why do companies that HAVE 64-bit products make it a POINT that they offer '64-bit support'? Yeah it doesn't matter? Only for people that don't pay attention to new technology.

It's called "marketing". Lots of gullible punters will think "64 is bigger than 32, so 64-bit must be better, right?" without actually thinking about what it really means. The result: lots of software sales, and big fat commission bonuses.

and vCenter isn't anywhere close to that big -- then there really is no need to make the application 64-bit. You'd gain nothing, and probably lose some performance. OK, so 64-bit end-to-end might be "neater" but that's about it.

Are you reading the fluff or technical manuals?

Technical manuals, and 15 years' experience as a sysadmin and programmer in high performance scientific computing.

That's not it at all.. 64-bit isn't the next buzz word it's the FUTURE for existing technology.

Agreed. Where did I say it was a buzzword? Where did I say it shouldn't be adopted? Where did I say the technology itself isn't important? I didn't. All I said was that for this particular application, the move to 64-bit is not important.

AND my point is if they made the rest of the products 64-bit why did they leave these out?

For precisely the reason that I said, which you seem to have ignored. This client is a small application. It doesn't have to handle large amounts of data. 64-bit x86_64 operating systems can run 32-bit code natively, with no performance hit. Therefore, it is quite understandable that VMware made converting this application to 64-bit a low priority. By contrast, converting the server components to 64-bit was much more important, because they do handle larger amounts of memory; ESXi itself, for example, has to be able to handle physical servers with very large amounts of RAM, and that's something which cannot be done efficiently with a 32-bit OS. So obviously they did the server components first, and left the client to last because making it 64-bit won't enable any new functionality or features.

Forget about the ideal way to provide more software and better features, it should ALL be compiled on 64-bit so we don't have to flip flop or use something else (like a 32-bit DSN on a 64-bit OS) ESPECIALLY when 64-bit DSN is backwards compatible....

Yeah you can defend 32-bit all you want, for the people that KNOW the true difference, there is more to it than just doubling the number.

No there isn't. The move from 32-bit does nothing to increase stability. If I write an application for a 32-bit system, and then recompile it for 64-bit, any bugs it had as a 32-bit program will still be there in the 64-bit program. There may even be more, due to invalid assumptions about the size of certain data structures. I'd like you to describe for me exactly what you think there is "more to it" than (1) doubling the number of bits in some integer types and (2) doubling the number of bits in pointers, so that they can address flat memory spaces larger than 4GB. Enlighten those of us who went through the 32->64-bit transition 10 years ago and clearly missed something. Please. The Linux community might like to know, too, since apart from these two things, there's no difference between a 32-bit version of Linux and a 64-bit version. The same source code is used to build both versions. The same is probably true of Windows 7, although of course I don't have access to the source code to check. I certainly used to compile my Windows programs for both 16- and 32-bit Windows versions from the same source code, back in the day that that was necessary.

In the high performance computing stuff that I run, we actually moved some applications back from 64-bit to 32-bit, because the extra memory required for the 64-bit versions made them slower (more RAM required leads to greater frequency of CPU cache misses leads to poorer performance). The difference can be quite significant, because cache is about an order of magnitude faster in latency terms than main memory, so if an application which manages to run almost entirely within cache then grows large than the cache, the performance hit can be enormous. Not that any of that is relevant to something like the vSphere client, because it isn't a CPU-bound application.

This isn't the same as the 16-bit to 32-bit transition of the 80's. In that transition, stability was improved, but that wasn't because of the increase in the bits. It was because of additional memory protection features available in the 32-bit modes of 386 and later processors, compared to the 8086 and 80286, and Linux, OS/2 and Windows NT all took advantage of that.

Regards,

Tim

[RParker]

You've assumed, with no knowledge of who I am, or what I do for a living, that somehow I'm an ignoramus who doesn't know my arse from my elbow

"Possibly because it doesn't really matter. Making an application 64-bit makes it use more memory (because all the pointers, and many other datatypes, in its data structures double in size)."

Gee it could possibly be that comment especially the part about -- data structures double in size --. You don''t ACT like you know much about 64-bit you reduced the technology down the equivalent of "What does this button do? Nothing, don't worry about it" instead of a more intelligible answer. Garbage in, garbage out. If you would have replied with more technical saavy perhaps I would have given you more credit.

I run one of the world's largest supercomputers for a living

Ah, well give yourself a pat on the back for me, because that means ABSOLUTELY nothing. I drive a BIG mercedes! WOW lucky you! Too bad you didn't DESIGN it, you drive one but that means ZIP about how they work.

In other words: I do know what I'm talking about.

Well so far no evidence to support it. So I am guessing you think ALL 64-bit systems work the same way huh? Intel would like to talk to you and your 'SUPER' computer.

to write good stable code in 32-bit as in 64-bit.

Well you acknowledge that the registers are bigger in 64-bit, but now you say you can do the same thing. Interesting, because 64-bit goes WAY beyond simply memory construct.

It's called "marketing". Lots of gullible punters will think "64 is bigger than 32, so 64-bit must be better, right?"

Marketing. Ah, ok so vSphere and the fact that's is more responsive just has to do with the fact it was designed better than previous versions, but no relevance to 64-bit, is that what you are telling me? So companies that taut 64-bit and it's capabilities and the fact that Intel and AMD have PROVEN 64-bit technology is better, that's ALL marketing? And you THINK you are a tech? I think you are standing too close to that power supply! I think you got a few things rattling around, because marketing is in support of the technology, the best marketing in the world can't make things WORK better.... The proof is in the pudding, you don't work for the largest pudding manufacturer as well do you?

Technical manuals, and 15 years' experience as a sysadmin and programmer in high performance scientific computing.

My you like to marvel at your own achievements don't you? 15 years, 100 years, and yet 64-bit is ALL marketing! Amazing.. Well you did say EXPERIENCE and not KNOWLEDGE, so that may have something to do with it.

I'd like you to describe for me exactly what you think there is "more to it" than (1) doubling the number of bits in some integer types and (2) doubling the number of bits in pointers

Would love to: I am sure you can find it on your 'SUPER' computer, even a Cray (or whatever it is you flip the on / off switch for) can do that.

n the high performance computing stuff that I run, we actually moved some applications back from 64-bit to 32-bit, because the extra memory required for the 64-bit versions made them slower (more RAM required leads to greater frequency of CPU cache misses leads to poorer performance).

Poor coding does not supplant hardware efficiency. It could be a number of factors that did that, or maybe SOME one doesn't know how to program 64-bit.And I work for a software development company, I have an entire programming team that works on 64-bit, so I think we KNOW what makes 64-bit tick and the results it has on software. So you think it's hype, but Microsoft, Linux, VM Ware and a host of other companies ALL know the difference and it's not just written on some brightly colored brochure.

And what started this entire thread, was relevant to VM Ware, not get into a dissertation on 32-bit vs 64-bit. I leave that to wikipedia. What it's important is my FIRST question, which you completely dodged, and only chose to point out 64-bit means nothing. Why does VM Ware have only PART of the code on 64-bit and still some on 32-bit, when clearly they could have simply done the rest.

We can dispense with the whole 64-bit has no benefit theory (an argument which you will lose because you can simply google 64-bit App benefits and see for yourself). My ONLY question was directed at VM Ware and why we have to do something backwards and downgrade to make it work on 64-bit, when clearly it is supported now.

Doesn't matter if VM Ware or you think that 2GB of memory is not enough to warrant a move to 64-bit or NOT. THAT is irrelevant. 32-bit or 64-bit, pick ONE! That's my point.

[tcutts]

At no time did I say 64-bit is hype. All I said is that for small

applications it isn't necessary. Surely you can't disagree with that?

And whether you disagree with me or not, the tone of your response was

quite unnecessary.

On 14 Aug 2009, at 19:30, RParker <communities-emailer@vmware.com

[Troy_Clavell]