VMware ESXi and vSphere Cluster Management

Configure Virtual Machine Options in VMware vSphere

Learn how to open and configure VM Options in the vSphere Client, including guest OS, VMware Tools, boot, power, logging, swap, console, NPIV, and disk settings.

VM Options are virtual-machine-level settings that control behavior, identity, startup, guest integration, logging, storage policies, and specialized features. They are configured separately from virtual hardware such as CPUs, memory, disks, network adapters, and virtual controllers.

This lesson explains how to open the Edit Settings workflow and use the VM Options tab in vCenter Server, the vSphere Client, or a supported ESXi Host Client. Labels and available controls vary by vSphere release, VM hardware compatibility level, guest operating system, datastore capabilities, and your permissions.

Prerequisites and change planning

You need access to vCenter Server or directly to an ESXi host through the appropriate vSphere client. Your assigned role must include privileges to modify virtual machine configuration. A setting can also be unavailable because the VM is running, the hardware compatibility level is too old, or the guest OS does not support the requested feature.

Before changing boot firmware, Secure Boot, VMware Tools behavior, swap placement, logging, or advanced settings:

• Confirm that a usable backup exists and that recovery procedures are known.
• Review snapshots and decide whether they should be consolidated or retained.
• Schedule a maintenance window when a power-off, reboot, or host maintenance operation may be required.
• Check application requirements, startup dependencies, time-synchronization policy, and storage capacity.
• Record the current values so that rollback is possible.

Open VM Options

1. Select the target virtual machine in the inventory.
2. Open Edit Settings. Depending on the client, this may be available from the VM context menu, Actions menu, or summary page.
3. In the settings dialog, select the VM Options tab or section.
4. Expand the relevant category and review the current values before editing.
5. Apply or save the changes, then verify that the new values persisted.

Inventory → Virtual machine → Edit Settings → VM Options → Review → Apply/Save

The Edit Settings workflow can also contain virtual hardware settings. Changes to CPU, memory, disks, network adapters, and controllers belong to the hardware portion of the workflow; they are not the same as VM Options.

Common option categories

Virtual machine identity and naming

The inventory display name identifies the VM in vCenter and client views. In General Options, you can update this name to follow a standard such as prod-app-01 or finance-db-a.

Changing the inventory name does not automatically rename the datastore directory, the .vmx virtual machine configuration file, virtual disks, log files, or snapshot files. This separation is expected:

• Inventory name: the label administrators see in vSphere.
• Datastore files: the files that implement the VM and may retain their original names.

Consistent inventory names improve operations, automation, backup selection, monitoring, and troubleshooting. If datastore-level names must also change, plan a separate, controlled storage operation. Review registrations, snapshots, backup jobs, automation references, replication, and maintenance procedures first. A file or folder rename should never be treated as a simple cosmetic change.

Guest operating system settings

The configured guest OS family and version describe the operating system installed inside the VM. This metadata influences default virtual hardware behavior, VMware Tools assumptions, compatibility checks, and guest customization features.

Select the guest type that matches the installed operating system. Do not select an unrelated guest type merely because it exposes a desired option. A mismatch can produce unsuitable defaults or unsupported behavior. Change it only as part of a planned migration, upgrade, or correction, and verify the guest OS and VM hardware compatibility afterward.

VMware Remote Console settings

VMware Remote Console (VMRC) is a native console client used to interact with a VM's display, keyboard, and mouse. Browser-based console access is a separate experience provided by the vSphere Client or Host Client. The exact console controls exposed in VM Options depend on the client and vSphere release.

Where supported, review controls for console access and consider whether clipboard sharing, device redirection, keyboard behavior, or related interactive features are appropriate. These features can improve administration but may also transfer data between an administrator workstation and the guest. Apply least-privilege access, restrict console permissions, and disable unnecessary redirection in sensitive environments.

VMware Tools options

VMware Tools is guest software that supplies optimized drivers and integration features between the guest operating system and ESXi. It supports guest information reporting, clean shutdown and restart, time synchronization, improved device handling, and other management operations.

Upgrade policy

Choose an automatic VMware Tools upgrade policy only when it fits the organization's testing and change-control process. Automatic upgrades can be useful for consistently maintained workloads, but they may restart services, alter drivers, or introduce a version that has not been tested with a critical application. Manual upgrades are often preferable for regulated, highly available, or tightly controlled application servers.

Time synchronization

VMware Tools time synchronization can adjust guest time using the virtualization platform. It must not conflict with another authoritative source such as guest NTP, Active Directory or domain time, a Linux time service, or an application-specific time service.

Choose one coherent time strategy. For example, a domain member may use domain time, while an independent Linux server may use its configured NTP service. Verify host time as well as guest configuration before enabling or disabling Tools synchronization.

Guest operations

Tools can allow vSphere to request a guest shutdown or restart instead of immediately cutting virtual power. A guest shutdown gives the operating system and applications an opportunity to close cleanly. Before relying on guest operations, verify that Tools is installed, running, compatible with the guest, and reporting a healthy status.

Power management and power behavior

Power options determine how vSphere handles VM power operations and, where configured, what happens after a host restart or VM power recovery. Available controls can include startup or recovery behavior, suspend, power off, reset, and guest shutdown actions.

• Guest shutdown: asks the operating system to shut down through VMware Tools.
• Power off: removes virtual power without giving the guest a normal shutdown opportunity.
• Reset: is similar to pressing a physical reset button and can cause data loss.
• Suspend: saves VM execution state so it can resume later; it is not the same as shutting down the guest.

Coordinate automatic power behavior with application dependencies. A database, identity service, storage service, and application tier may need a specific startup order. Document whether host recovery should power on a VM automatically, and test the result rather than assuming that all dependencies recover at the same time.

Boot options

BIOS and EFI/UEFI

BIOS is legacy virtual firmware. EFI/UEFI is modern firmware that supports features such as Secure Boot. The firmware mode must match how the guest operating system and its bootloader were installed.

Changing firmware mode can make an existing installation unbootable. Confirm guest OS support, bootloader requirements, partition layout, VM hardware compatibility, and backup recovery before changing it. A firmware change commonly requires the VM to be powered off and then power-cycled.

Secure Boot and startup controls

Secure Boot validates trusted boot components. Enable it only when the guest OS, bootloader, drivers, and virtual hardware support it. Other boot controls may include a startup delay, forcing firmware setup on the next boot, boot order controls, and booting from network or removable media where the client and hardware version expose those options.

Logging, debugging, and statistics

VM log files record VMX and device events and can help troubleshoot boot, device, power, and runtime problems. Logging controls may include enabling logs, retention or rotation behavior, and diagnostic detail. Exact controls vary by version.

Verbose debugging and detailed statistics should normally be enabled only under an approved troubleshooting procedure. High-volume logs consume datastore space and can add operational noise. Define a duration, monitor datastore capacity, collect the required evidence, and disable elevated diagnostics when the investigation ends. Do not leave temporary debugging enabled indefinitely.

VM swap file location

The VM swap file is created by ESXi to back virtual machine memory under memory-management conditions. Its location can affect datastore capacity, performance, availability, and migration behavior.

Depending on the environment, placement choices can include:

• The VM's datastore directory.
• A host-defined swap location.
• A datastore selected by policy or by the applicable vSphere interface.

Evaluate free capacity, latency, redundancy, datastore accessibility, host consistency, and vMotion or recovery behavior before selecting a location. A destination that is unavailable to a host can prevent the VM from powering on or migrating. Changing placement may require powering off the VM or reinitializing its swap file.

Fibre Channel NPIV

NPIV, or N-Port ID Virtualization, allows a virtual machine to present virtual Fibre Channel identities to the SAN. A VM receives virtual WWPNs (World Wide Port Names), which the Fibre Channel fabric and storage array can use for zoning, LUN masking, and access control.

NPIV is specialized Fibre Channel functionality. It is not a replacement for virtual disks and is relevant only when the VM accesses a compatible Fibre Channel SAN directly through the required virtual or physical storage path.

Prerequisites

Generate or assign virtual WWPNs according to organizational policy. Coordinate the identities with SAN zoning and storage-array masking before expecting guest access. Record the WWPNs for backup, recovery, migration, and hardware replacement planning. NPIV-enabled VMs require special attention during migration: the destination host, fabric, zoning, and storage policy must provide equivalent support.

Thin-provisioned disk inflation

A thin-provisioned disk initially consumes datastore space based largely on blocks written by the guest rather than its full configured capacity. Inflating the disk preallocates the remaining capacity, increasing datastore consumption to approximately the configured disk size, subject to filesystem and format overhead.

Inflation is a virtual disk storage operation, not an ordinary VM Option in every interface version. Use the available vSphere disk-management workflow rather than assuming it appears in VM Options.

Why inflate a disk?

• Reduce the risk that future writes fail because datastore space is exhausted.
• Meet a storage policy requiring fully allocated virtual disks.
• Make datastore capacity consumption predictable for a capacity-sensitive workload.

Before starting, calculate the unallocated portion, verify sufficient datastore free space, account for snapshot growth and operational overhead, and schedule the operation during a suitable maintenance period. Inflation can consume significant storage and affect performance while it runs.

Inflating a virtual disk is not the same as expanding a guest partition or filesystem. The guest sees no additional capacity merely because unused thin-disk blocks were preallocated. Conversely, deleting guest files later does not automatically reclaim datastore space created by inflation; reclamation requires separate guest, virtual-disk, and datastore procedures.

Practical configuration examples

Rename a VM without renaming datastore files

1. Open the VM's Edit Settings workflow and select VM Options.
2. Change the General Options display name to the approved standard.
3. Save and confirm the new name in inventory.
4. Browse the datastore and confirm that the existing VM directory and files retain their original names.
5. Only plan a separate datastore-level rename if an operational requirement justifies its risks.

Prepare a supported Linux VM for Secure Boot

1. Confirm the guest OS, bootloader, VM hardware compatibility, and installed drivers support EFI/UEFI and Secure Boot.
2. Back up the VM and record the current BIOS setting.
3. Power off the VM if required, switch to EFI/UEFI, and enable Secure Boot only when supported.
4. Power-cycle the VM and verify the guest bootloader, VMware Tools, and application services.
5. If boot fails, use the approved rollback path and restore the prior firmware configuration.

Manage VMware Tools on an application server

1. Review whether VMware Tools is installed, running, and reporting a current status.
2. Choose manual or automatic upgrade behavior based on testing and change control.
3. Select one authoritative time source and avoid competing Tools, NTP, domain, or application time controls.
4. During a maintenance window, test a guest shutdown request and confirm an orderly application stop.

Place a VM swap file on suitable storage

1. Compare candidate datastores for free capacity, latency, availability, and migration access.
2. Select the applicable swap-file placement policy.
3. Perform the required shutdown or restart and allow ESXi to create or reinitialize the swap file.
4. Confirm that the destination datastore has adequate capacity and that the VM operates normally.

Inflate a thin disk

1. Determine the configured disk size and current allocated capacity.
2. Confirm that the datastore can absorb the unallocated capacity plus snapshot and operational overhead.
3. Use the vSphere disk-management workflow to inflate the disk.
4. Monitor datastore usage and operation status.
5. Verify that the virtual disk remains healthy; expand the guest partition separately only if additional guest-visible capacity is required.

Configure NPIV for SAN access

1. Confirm end-to-end support from the ESXi host HBA, SAN switch, storage array, and guest OS.
2. Generate or assign virtual WWPNs according to policy.
3. Give the WWPNs to the SAN team for zoning and storage masking.
4. Power on or rescan only after the fabric and array configuration is complete.
5. Validate guest visibility, multipathing, and access, then document the identities.

Troubleshooting

The desired VM Option is missing or disabled

Check your permissions and role assignments, the VM hardware compatibility level, the vSphere version, the current power state, and guest OS support. Some controls become available only after the VM is powered off. Confirm that the host and datastore provide the required capability.

The VM name changed but datastore files did not

This is normally expected. Inventory renaming and datastore file renaming are separate operations. Treat a storage-level rename as a planned change and review registrations, backups, automation, snapshots, and replication first.

The guest fails to boot after EFI or Secure Boot changes

The OS may have been installed for BIOS mode, the bootloader may be unsigned or unsupported, or the guest and virtual hardware may be incompatible. Revert to the prior firmware setting if necessary, confirm vendor support, and test changes on a nonproduction clone whenever possible.

Guest time drifts after enabling Tools synchronization

Look for competing time sources, incorrect host time, domain configuration, or guest NTP settings. Select one authoritative source and validate the complete time path rather than enabling multiple mechanisms.

Thin-disk inflation fails or fills the datastore

Likely causes include insufficient free space, concurrent snapshot growth, or an incorrect capacity estimate. Stop the operation if capacity becomes unsafe, add or free storage, account for snapshots, and monitor utilization during the retry.

NPIV does not provide guest SAN access

Check HBA, switch, array, and guest support. Confirm that the assigned WWPNs exactly match SAN zoning and LUN masking records. Coordinate with the SAN team and verify guest Fibre Channel adapters and multipathing configuration.

Validation and change management

1. Reopen Edit Settings and verify that the saved VM Options values match the change record.
2. Test guest boot, console access, and VMware Tools status.
3. For power or Tools changes, test guest shutdown and restart behavior.
4. For firmware changes, complete a power cycle and verify the bootloader and applications.
5. For swap or disk changes, verify datastore capacity, storage behavior, and migration requirements.
6. For NPIV, validate SAN visibility, zoning, masking, and multipathing.
7. Document the old and new values, operator, time, reason, test results, and whether a reboot, power cycle, or host maintenance activity was required.
8. Record rollback steps for firmware, Secure Boot, automatic Tools upgrades, logging, swap placement, and storage operations.

For the related workflow, see Edit VM Options.