Skip to main content

Which vSphere version is my VM running on?

Several years ago, I created a list of ESXi versions with matching VM BIOS identifiers. The list is now complete up to vSphere 7.
Your Linux runs on a VMware VM, but on which ESXi version? Even without access to the host nor vCenter, you can see for yourself: run "dmidecode" and look at lines 10, 11 and 12. The BIOS release date, the address and the runtime size are unique for each ESXi version. Starting from 7.0 U3, no address and size is reported, and the "Phoenix Technologies LTD" name changed to "VMware, Inc.". Look up your result in the following table:
ESXi version  BIOS release date  Address  Size
ESX 2.504/21/20040xE848097152 bytes
ESX 3.004/17/20060xE7C7099216 bytes
ESX 3.501/30/20080xE7910100080 bytes
ESX 408/15/20080xEA6C088384 bytes
ESX 4U109/22/20090xEA55088752 bytes
ESX 4.110/13/20090xEA2E089376 bytes
ESXi 501/07/20110xE72C0101696 bytes
ESXi 5.106/22/20120xEA0C089920 bytes
ESXi 5.507/30/20130xEA05090032 bytes
ESXi 609/30/20140xE9A4091584 bytes
ESXi 6.504/05/20160xEA58088704 bytes
ESXi 6.707/03/20180xEA52088800 bytes
ESXi 6.7 U212/12/20180xEA49088944 bytes
ESXi 7.012/09/20190xEA48088960 bytes
ESXi 7.0 U325/06/2021VMW71.00V.18227214.B64.2106252220
NB These DMI properties are set at boot time. Even if your VM gets live-migrated to a host running a different vSphere version, your VM will keep the values it got from the host it booted on. What you see is the vSphere version of the host your VM booted on. It is the VM power-on that matters, so a guest OS reboot will not regenerate the DMI properties. A guest OS shut down on the other hand will also power off the VM, and the next power-on will regenerate the DMI properties.

Comments

Gary Strickland said…
Hi Bert,
Nick from Deep Signal Studios suggested I get in touch with you. I have a LOT of sequences created with a GEM Bachmann WS2 workstation (that I no longer have) that I would really like to convert to MIDI. The files are in the GEM ALL format. Nick suggested i "beg" you to possibly build an app that will convery ws2 .all to .mid.
ANy help would be greatly appreciated!
Thank you so much for your time,
Gary Strickland
28/8/20 18:04
Bert de Bruijn said…
Hi Gary,
Nick must have found or remembered my blog post from 2014: http://virtwo.blogspot.com/2014/07/gem-ws2-midi-system-exclusive-structure.html . I discuss the process of converting the floppy .ALL format to the WS2 MIDI dump format. This was and is useful to people who have a WS2 without a working floppy drive. I later published my code on https://github.com/bertdb/gem-ws2-floppy-to-midi-dump/ so others can use it too. Unfortunately, the data structure of the 60KB memory dumps was never fully documented by GEM/Bachmann, nor successfully reverse-engineered by hobbyists, apart from the header information that contains the filename. A complete understanding of how voice, global, style and sequencer data were stored in memory would be necessary to convert the sequencer data to generic MIDI files. With a WS2 and a lot of free time, one could experiment with binary comparisons of dumps where e.g. only one voice parameter changed. This would reveal where that parameter is stored. However, for the sequencer data this is much, much more complex. It is impossible to generate two recordings with exactly one difference (note number, or velocity, or timing). Personally, I don't have a WS2 anymore either, so further experimentation is not going to happen on my side.
The only feasible way of converting .ALL to MIDI is: buying a second hand WS1/2/400 or WS2 MIDI workstation, loading the file, and playing it back, attached to a MIDI sequencer that can save the recording as .MID.

Kind regards,
Bert de Bruijn.
29/8/20 11:54
Bert de Bruijn said…
Gary, I forgot to mention that there are synth/keyboard enthousiasts on the internet who should have a WS2 or a WS2 midi workstation. You could try your luck with them. One example would be https://twitter.com/deepsonic/ (based in Switzerland). They're not advertising this kind of conversion as a service, but you can always try.

Bert.
29/8/20 14:01
pirx said…
Is there a more current list with the VM BIOS versions? I searched but did not find anything. Some software vendors base their license of this and we just noticed that it is not VMware Tools / vHW that changes this. And that is only pops up months after an ESXi version update + powercycle of VM....
2/2/23 14:45
Bert de Bruijn said…
@pirx I added information for vSphere 7.0 U3. The BIOS vendor name changed from Phoenix to VMware, and dmidecode doesn't show an address nor a runtime size anymore. I've included the BIOS version string that I get. I'm not aware of any official VMware publication that gives out this information.
2/2/23 15:13
pirx said…
Thanks a lot! It would have been interesting to see which ESXi version had BIOS date 11/12/2020. This is was some VMs still show in their registry.
2/2/23 16:17
Bert de Bruijn said…
My guess is a 7.0u1 or u2.
2/2/23 16:20
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