The creation wizard looks harmless, but three of its choices - compatibility, firmware and disk provisioning - follow the VM for its whole life. Here is what each one really does, which defaults to trust, and which to change on purpose.
Most ESXi guides tell you to click Next and accept every default. For an Ubuntu VM that mostly works - but 'mostly' hides three decisions you should make with your eyes open. Firmware is effectively permanent, disk provisioning decides how your datastore fills up, and compatibility decides where this VM can live in the future. This page explains all three, plus the smaller settings people break by experimenting.
Every VM carries a virtual hardware version - think of it as the model year of its virtual motherboard. A newer version supports more vCPUs, more RAM and newer virtual devices; an older version can run on older ESXi hosts.
The honest rule: accept the default your ESXi offers. Lower compatibility buys you nothing on the same host - it only matters in one situation: you plan to move this VM to an older ESXi host later, in which case create it at that host's level from the start, because raising is easy and lowering is not a supported casual operation. The OVF move guide in this series shows where this bites in practice.
Firmware is how the virtual machine starts before Ubuntu loads. EFI is the modern standard: Ubuntu installs happily on it, it is required for Secure Boot, and it is needed if the boot disk must pass 2 TB. BIOS (legacy) still works and occasionally suits very old installers or cloning oddities.
Why treat it as permanent? Ubuntu's installer writes its boot loader for the firmware it booted under. Flip the setting later and the VM typically boots to nothing - the disk is fine, the boot path is wrong. Technicians can rebuild a boot loader with rescue media, but that is a repair project, not a settings change. Decide at creation: EFI unless you have a specific legacy reason.
While you are there: if you enable Secure Boot under EFI, use a signed Ubuntu release - Ubuntu's images are signed for exactly this, so it normally just works.
The virtual disk is a file on the datastore, and provisioning decides how that file claims space:
Honest verdict: on today's storage, thin versus thick is a space-management decision, not a speed decision. Choose thin and monitor, or thick when the VM is critical and the space is genuinely spare.
CD/DVD drive: harmless, but remember it exists - a VM that "boots the installer again" is usually still connected to its ISO. Disconnect it after install.
CPU and memory hot plug: ESXi can offer hot-add for both, but the guest and workload must cooperate, and memory hot-add has platform quirks. Leave these off until you have a real reason; adding resources to a powered-off VM takes one minute anyway.
Reservations and limits: a reservation guarantees resources, a limit caps them. Both default to "none", and a forgotten limit is a classic cause of a mysteriously slow VM. Unless you are deliberately protecting one VM from its neighbours, leave them alone.
Boot options - boot delay and failed-boot retry: a short boot delay makes entering the virtual BIOS/EFI setup and picking boot devices less frantic on the console. A small kindness, worth setting once.
For VMs you inherited rather than created, check in this order:
That audit prevents the three classic surprises: the unbootable VM after a firmware flip, the paused VM on a full datastore, and the slow VM strangled by its own limit.
The full process on a live ESXi host - creating the virtual machine, installing Ubuntu and fixing the common problems, exactly as they appear on screen.
Watch Full VideoTreat the firmware choice as fixed. Ubuntu installs its boot loader for the firmware in use, so switching the setting afterwards normally leaves the VM unable to boot - the data is intact, but the start-up path is wrong. Rebuilding the boot loader from rescue media is possible for an experienced technician, but planning EFI at creation is the honest, painless route.
On modern SSD-backed datastores, no - the difference for typical office and lab workloads is small enough to be lost in measurement noise. Thick provisioning's real benefit is certainty: the space is reserved, so the VM can never be surprised by a full datastore. Thin provisioning's benefit is efficiency, paid for with one duty - watching free space.
Your ESXi host's default. It gives the VM the newest virtual hardware your host supports. Lower it only when you already know this VM must move to an older ESXi host - matching that host's level at creation avoids a painful conversion later.