Hi, during automatic deployment (non-interactive install), I want to install the correct version of the tools in a VM. I have installations that are used on physical machines as well as ESX 2.5 and ESX 3.0 hosts, and in the future ESX 3.5 as well. Problem is I want to install the correct version of the VMware tools (wrong version gives errors in the VM logs).
So I'm looking for a mechanism that lets me determine the version of the ESX host a VM is running on. Just the difference between 2.5, 3.0; 3.5 would be a good start, exact version even better.
I've looked at dmidecode, biosdecode, lspci in Linux VMs but nothing definitive yet.
Any takers ?
have you seen http://rvtools.deveij.com/ it may be helpful
I found this, don't know if it will help you out or not.... I found it here http://communities.vmware.com/docs/DOC-4210
Q: How can I determine the version of VMware tools my VMs are using?
A: Toolversion property under the config property of virtual machine object having this information. To get this information we can use the below script.
connect-viserver -Server
get-vm VMName | % { get-view $_.ID } | select Name, @{ Name="ToolsVersion"; Expression={$_.config.tools.toolsVersion}}
Hello,
A VM will not directly know the version of ESX upon which it is running. However you can get this information using various tools as described above.
Best regards,
Edward L. Haletky
VMware Communities User Moderator
====
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.
CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354
As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization
troy, I need the version of the ESX in order to install the correct version of the tools. So at that point (unattended OS install), I'm not running the VMware tools at all. So getting the version of the tools is irrelevant here. Thanks for your reaction, but it doesn't help me unfortunately.
Hello,
You will need to make an outside query to get this to work.
Best regards,
Edward L. Haletky
VMware Communities User Moderator
====
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.
CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354
As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization
It's just that I'm not looking for the version of the running tools. I'm looking for the version of the ESX before the tools get installed.
I've found a workaround here, using dmidecode. The BIOS Release date and address are unique per major ESX version, so I can use them to know the version from inside the VM any time, even without the tools.
I wanted to avoid that, if possible. Have a look at what we found:
http://virtwo.blogspot.com/2008/10/identifying-esx-version-in-vm-peeking.html
For security reason the guest shouldn't know on which host its running on. But you can use a SNMP query from somewhere (could be guest) to get the version of at least any ESX host.
From what I've found, it is perfectly possible to know on which (major) version of ESX you're running. So even though it's not clearly visible, it's not well hidden either. I doubt there are real security worries at play.
an external query would be the easiest solution, but in an environment with strict separation between management, production, DMZ (multiple), and deployment networks, that's not feasible.
Hello,
From a security perspective, this is basically a form of information leakage. However, like all 'hardware' style systems upgrades imply virtualization. Yet now with this information a specific attack could be attempted that would otherwise be generic.....
Best regards,
Edward L. Haletky
VMware Communities User Moderator
====
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.
CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354
As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization
Pretty slim information leakage, particularly if access to the interface is properly restricted, one would be hard pressed to argue that the risk outweighs the benefits.