Menu
▾
▴
#100 Wrong "Guest OS" information in vSphere client displayed
The guest is configured as "Other 2.6x Linux (64-bit)", attached screenshot (vmware-tools_stopped.png).
# uname -a
Linux wwwproxy 2.6.38.5 #2 SMP Wed May 4 12:33:49 CEST 2011 x86_64 Six-Core AMD Opteron(tm) Processor 2425 HE AuthenticAMD GNU/Linux
After starting open-vm-tools-2011.04.25-402641 the information in vCenter changes to "Other (32-bit)", attached screenshot (vmware-tools_started.png) which is obviously wrong.
VMware vSphere vCenter Client/Server is Version 4.1.0 Build 345043.
vmware-tools_stopped.png
vmware-tools_started.png
I'm seeing this on Fedora 9 as well with open-vm-tools-2011.06.27-437995. Anything I can provide to assist? vSphere 4.1.0 Build 260247
Tools will generally use the output of "lsb_release -sd" to figure out the OS information. Fedora 9 should have that; what's the output of that command in your VM?
If lsb_release is not available, then that's probably the cause.
lsb_release -sd returns: "Fedora release 9 (Sulphur)"
I can see where that would get me Other (32-bit).
Could you give me some idea of what tools are looking for in the response to indicate 64 bit? If I have to, I'll make this return what's necessary, since it's not used by our appliance for any other purpose.
Also, would there be any side-effects to just allowing this to happen? The vmx file is still set to Other (64 bit).
In general, the OS would be reported as "Other (32-bit)" if the code completely failed to recognize that output. The interesting bit is that we do have a check for Fedora in the code, and it should recognize that output. I'll need to try it out to see what's going on.
As for what if affects, there are a couple of vCenter features that will look at that value and decide whether they'll run against the VM or not. But I think those features do not support Fedora anyway, so you should be safe. In your case it's probably just a cosmetic thing.
I just tried with Fedora 8 (which has a very similar output of "lsb_release -sd") and the code seems to detect Fedora correctly. I'll close this as an issue with the vCenter / VI client code (they may be missing the mapping to show Fedora correctly), but I shouldn't worry much because this is mostly a cosmetic issue.
So what's the deal on Gentoo or (m)any other "Other" Linux distributions?
# lsb_release -sd
"Gentoo Base System release 2.0.3"
Issue on the open virtual machine tools side, or time to open a vmware bug?
I tried hardcoding lsb_release to return "Fedora release 8 (Werewolf)" and my image is still 32 bit. I've been looking at the code where lsb_release is called and it would seem that uname is also involved. Although command line uname appears to return very similar information as what I found online for FC 8. I sure don't see any issues with it.
Gentoo and many "Other" distros will probably show as their original configured OS. There's no point in adding every single distro out there to our UI, when only a few of them require tweaks at the hypervisor level. (I'd argue that the current list is already too long, but that's a separate discusssion.)
As for the Fedora problem; unless you add some log statements to GuestInfoGather() in services/plugins/guestInfo/guestInfoServer.c (after the call to Hostinfo_GetOSName()), there's not much I can figure out from logs or anything else, because we don't log the raw data anywhere. "osName" and "osNameFull" are the strings provided to the UI to identify the OS.
I'll close this as "won't fix" because (i) we consider this a bug in our UI and we have a bug tracking that internally, and (ii) there's not enough information to root cause the underlying issue in the bug.