Skip to main content

identifying the ESX version in a VM: peeking through the blinds

An interesting issue popped up: how can a program or script in a VM determine the type and version of the hypervisor it is running on ? This is important if you want to install version-specific software, like the VMware Tools ("enlightened hardware drivers", as MS would say).
Knowing that you're running in a virtual machine is pretty easy: you can look at the hardware, on VMware you'll see "00:0f.0 VGA compatible controller: VMware Inc Abstract SVGA II Adapter" which makes it pretty clear, and lspci -v says "Subsystem: VMware Inc" for every PCI device. Easy as 1 2 3.

But which version of VMware ESX is it ? Not that easy, it seems. But we (hi Dag !) found a unique signature for each ESX version: looking at dmidecode, the output in the "BIOS Information" section lists a Release Date and an Address field. These seem to be unique for each ESX version. The mapping we could build was:
ESX 2.5 - BIOS Release Date: 04/21/2004 - Address 0xE8480 - Size 97152 bytes
ESX 3.0 - BIOS Release Date: 04/17/2006 - Address 0xE7C70 - Size 99216 bytes
ESX 3.5 - BIOS Release Date: 01/30/2008 - Address 0xE7910 - Size 100080 bytes
ESX 4(?) - BIOS Release Date: 08/15/2008 - Address 0xEA6C0 - Size 88384 bytes

Tested versions: ESX 2.5.2, 3.0.2, and 3.5u2. We received an anonymous tip about ESX 4 beta results. Thanks !
VMware Workstation 4.5 reports the same as ESX 2.5. VMware Server 1.0 reports the same as ESX 3.0. Workstation 6.5 reports the same as ESX 4(?). Workstation 6.0 and Server 2.0.0 report
WS 6.0 - BIOS Release Date: 12/06/2006 - Address 0xE78A0 - Size 100192 bytes
SRV 2.0.0 - BIOS Release Date: 7/29/2008 - Address 0xEA6C0
but we didn't find an ESX version that reported the same values. Refer to the VMware "mobility guide" document for other possible relationships between different VMware products.

P.S. 26/11 thanks to Michael for sending us information on VMware Server 2.0.0 ! Same address as WS 6.5 and ESX4(?), but different release date.
Labels:

Comments

Carlo said…
I have got an Openfiler VM running on an ESX 3.5 and it reports:

BIOS Information
Vendor: Phoenix Technologies LTD
Version: 6.00
Release Date: 03/19/2009
Address: 0xE66C0

This is not on your list. so I thought it might interests you.

Carlo
www.happysysadm.com
18/7/12 10:10
Post a Comment

Popular posts from this blog

Volkswagen UHV bluetooth touch adapter & its problems

My Volkswagen car has the "universal cellphone preparation" UHV built-in. This is the main part of a car kit, but requires an additional adapter for connecting to a cellphone. At first, I was using an adapter for my good old Nokia 6310, even after I changed to the Nokia E71. Connecting was easy: pair the phone with the "VW UHV" bluetooth entity, and done. This has the phone connected to the car kit at all times, so even non-call-related functions use the car audio system (e.g. voice recognition). But progress will have its way, no matter what happens. So in comes the "bluetooth touch adapter". Instead of a phone-specific adapter, this is a small touchscreen device that slots into the UHV dashboard mount. Connecting a phone is very different now: the Bluetooth Touch Adapter connects to the "VW UHV" device via bluetooth the phone connects to "Touch Adapter" device, also via bluetooth The device doesn't allow step 2 if step 1 didn'...
12 comments
Read more

Reset lost root password on vSphere ESXi 6.7

VMware's solution to a lost or forgotten root password for ESXi is simple: go to  https://kb.vmware.com/s/article/1317898?lang=en_US  and you'll find that "Reinstalling the ESXi host is the only supported way to reset a password on ESXi". If your host is still connected to vCenter, you may be able to use Host Profiles to reset the root password, or alternatively you can join ESXi in Active Directory via vCenter, and log in with a user in the "ESX Admins" AD group. If your host is no longer connected to vCenter, those options are closed. Can you avoid reinstallation? Fortunately, you can. You will need to reset and reboot your ESXi though. If you're ready for an unsupported deep dive into the bowels of ESXi, follow these steps: Create a bootable Linux USB-drive (or something else you can boot your server with). I used a CentOS 7 installation USB-drive that I could use to boot into rescue mode. Reset your ESXi and boot from the Linux medium. Ident...
Post a Comment
Read more

GEM WS2 MIDI System Exclusive structure and checksums

MIDI is the standard for communication between electronic music instruments like keyboards and synthesizers. And computers! While tinkering with an old floppy-less GEM WS2 keyboard, I wanted to figure out the structure of their System Exclusive memory dumps. SysEx is the vendor-specific (and non-standard) part of MIDI. Vendors can use it for real-time instructions (changing a sound parameter in real-time) and for non-real-time instructions (sending or loading a configuration, sample set, etc.). In the GEM WS2, there's two ways of saving the memory (voices, globals, styles and songs): in .ALL files on floppy, and via MIDI SysEx. The .ALL files are binary files, 60415 bytes long. The only recognizable parts are the ASCII encoded voice and global names. The SysEx dumps are 73691 bytes long. As always in MIDI, only command start (and end) bytes have MSB 1, and all data bytes have MSB 0. The data is spread out over 576 SysEx packets, preceded by one SysEx packet with header informat...
23 comments
Read more