This document provides introductory information on the VMware virtual platform's support for EFI (or UEFI) firmware inside a virtual machine. It may help you to decide whether or not to use EFI firmware when preparing to create a new virtual machine.
EFI (Extensible Firmware Interface) is a specification for a new generation of system firmware. An implementation of EFI, stored in ROM or Flash RAM, provides the first instructions used by the CPU to initialize hardware and pass control to an operating system or bootloader. It is intended as an extensible successor to the PC BIOS, which has been extended and enhanced in a relatively unstructured way since its introduction. The EFI specification is portable, and implementations may be capable of running on platforms other than PCs.
Originally called Extensible Firmware Interface (EFI), the more recent specification is known as Unified Extensible Firmware Interface (UEFI), and the two names are used interchangeably. (I tend to use the name "EFI" for anything that was produced or defined before the name change, and "UEFI" for anything since the name change.)
For more information, see the Wikipedia page for Unified Extensible Firmware Interface and the website for the UEFI forum.
The following VMware products officially support running virtual machines with virtual EFI firmware:
Other products or versions may contain the ability to run EFI firmware, without it being a tested or officially supported configuration.
No. The host's firmware is totally independent of the virtual machine's firmware, so BIOS hosts can run EFI virtual machines, and EFI hosts can run BIOS virtual machines. (Note that virtual machines using physical disks, including Fusion's Boot Camp virtual machines, must use the firmware type that corresponds to the installed OS and the disk's partition scheme, which typically means that it must match the host's firmware.)
It's difficult to tell. The Linux kernel has supported EFI for a long time, but it's up to each distribution to enable it and provide all the rest of the needed support.
Let's start by going through some of the more common distributions:
As you can see, it's all over the place. This list is definitely not exhaustive, so distributions not on this list might still support EFI... The best way to find out is to try it and see. (If you want an exhaustive list, feel free to volunteer to try them all. :smileysilly:)
Some of the older implementations in the above list are a bit rough around the edges and might behave in unexpected ways.
Successful installation of Linux guests under EFI generally depends on the distributor providing certain minimum requirements for an EFI-aware OS:
Availability of these components is somewhat unpredictable, and they are sometimes delivered with defects which affect their ability to operate correctly.
Failure modes might include guest hangs or crashes before or during installation, failures to find or launch the installer, failures of the installer itself, failure to find the installed OS at the reboot at the end of installation, and – rarely – runtime issues or crashes in the installed OS.
You will need to configure the virtual machine to use BIOS.
Many physical EFI systems include a Compatibility Support Module (CSM) to enable them to load operating systems which are not EFI-aware. The CSM provides a BIOS-compatible interface that runs in conjunction with EFI, making the system behave just like with regular BIOS and allowing older OSes to run normally. A platform with a CSM is often referred to as a UEFI Class 2 platform.
The use of CSM is generally discouraged, and they are expected to be phased out from physical EFI systems in the near future.
The VMware virtual platform does not support the use of a Compatibility Support Module, which means that OSes that are not EFI-aware may only be booted by configuring the virtual machine to use BIOS. When a virtual machine is configured to use virtual EFI firmware, it is a "pure UEFI" platform lacking a CSM, often referred to as a UEFI Class 3 platform. (There is the need for a small amount of compatibility code to boot earlier versions of Windows atop our virtual EFI firmware, however it is not a full Compatibility Support Module.)
A consequence of this is that you cannot use virtual EFI firmware to perform USB boot of legacy guests.
Required virtual hardware:
Some virtual hardware is unsupported by EFI itself:
All other virtual hardware (e.g. storage controllers, network controllers, USB1/2/3 controllers, display adapters, processors & memory) may be used within EFI.
Verify that interoperating products/solutions are compatible with EFI. Of note for vSphere users: VMware Fault Tolerance (FT) is not presently compatible with EFI firmware.
You must make this choice before installing the OS.
On VMware Workstation, go into VM > Settings > Options > Advanced, and check Boot with EFI instead of BIOS.
On VMware Fusion, EFI firmware is automatically selected for Mac OS guests. You do not need to do anything.
On ESXi using the vSphere Web Client, go into Edit Settings > VM Options > Boot Options, and choose under the Firmware section.
On ESXi using the vSphere Client, go into Edit Settings > Options > Boot Options, and choose under the Firmware section.
On any of our products with EFI support, you can also manually edit the virtual machine's configuration file to add the line
firmware = "efi"
to configure a virtual machine for EFI. The above user-interfaces do exactly that for you. You can use this method if you want to play around with EFI in configurations that we don't officially support (such as Linux on EFI in Fusion 7), but of course things might very well break.
Don't do that.
During installation, the guest OS must decide whether to prepare the virtual disk with a partition scheme and bootloader suitable for BIOS or for EFI. Changing the firmware between BIOS and EFI after installation will generally render the virtual machine unbootable. Change the firmware back to its earlier configuration in order to restore the ability to boot the OS.
You may need to temporarily change between BIOS and EFI if you want to use a partitioning tool, rescue disk, or similar tool which requires firmware different from the installed OS. If you do this, again, change the firmware back to its earlier configuration when you're done, so as to restore the ability to boot the installed OS.
Be careful if you do that. The VMware virtual platform chooses the EFI architecture (IA32 or X64) according to the guest OS type, and the OS will generally work with and install only one bootloader architecture – either IA32 or X64 – according to the firmware architecture in use during installation. If you attempt to boot an OS using the incorrect firmware architecture, it will almost certainly fail to boot. If you installed Ubuntu 64-bit with the guest OS type accidentally set to "Other Linux 3.x kernel 64-bit", it won't be a problem to change it to "Ubuntu 64-bit". If you change it to "Ubuntu" (32 bit), the OS will be unbootable until you switch it back to a 64 bit guest OS type. If you tried to install Ubuntu 64-bit with the guest OS type set to "Ubuntu" or "Other Linux 3.x kernel" (both 32 bit), the OS installer would have failed to boot in the first place... and you can switch the guest OS type to "Ubuntu 64-bit" and then boot the virtual machine into the installer.
UEFI Secure Boot is supported since vSphere 6.5 (for both the ESXi physical hosts and Virtual Machines).
The UEFI specification allows quite a bit of latitude for vendors to extend the firmware, as well as to implement (or omit) certain optional parts of the UEFI specification. Sometimes, OS vendors end up unintentionally depending on characteristics of their development and test systems that are not part of the UEFI specification, thus limiting the compatibility of their OS.
The most common case of this we've seen has been OS vendors placing the EFI bootloader for the installation medium onto an ISO9660 or UDF filesystem instead of an El Torito partition. The UEFI specification does not require the ability to read an ISO9660 or UDF filesystem, although some hardware and virtual platform vendors include drivers for those filesystems anyway. Any OSes which depend on the presence of an ISO9660 or UDF driver will be severely restricting the platforms on which they can run, and such OSes will not run in a VMware virtual machine.
The next most common case we've seen has been OS vendors accidentally depending on legacy BIOS (or CSM) interfaces when booted on EFI firmware. Such OSes will generally install successfully on some systems with a CSM or even on systems with an EFI emulation layer atop BIOS, but will fail on UEFI Class 3 platforms with no compatibility layer such as the VMware virtual EFI firmware.
It could also simply be a defect in either the VMware virtual EFI firmware or a platform-specific defect in the OS itself... there's no shortage of ways in which to fail. If in doubt, start a new discussion thread in the appropriate forum for your product or file a support request, as appropriate.
It might be that the OS does not support EFI, that its EFI support is defective, or it could be that there is a defect in the VMware virtual EFI firmware. Some of the discussion above might help you figure out which is the case.
If in doubt, start a new discussion thread in the appropriate forum for your product or file a support request, as appropriate.