90 days. Unlimited cores. Zero commitment | The VMware Exit built for service
Learn More
Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Windows UEFI VM Fails to Boot After Image Migration Due to Secure Boot Mismatch

Problem

A Windows UEFI VM image exported from one Private Cloud Director environment and imported into another (for example - image captured from an active VM in QA and uploaded to Prod) fails to boot. The VM console displays OVMF (UEFI firmware) denying access to the boot disk with Access Denied errors, followed by No bootable option or device was found.

In some cases, if image metadata is not preserved during the migration, the VM falls back to legacy BIOS (SeaBIOS) and displays No bootable device instead.

Environment

  • Private Cloud Director Virtualization - v2025.10 and Higher

  • Self-Hosted Private Cloud Director Virtualization - v2025.10 and Higher

  • Component: Image Library Service

Cause

The source VM was configured with UEFI boot and Secure Boot enabled (os_secure_boot=required). When the image was captured and uploaded to the destination environment, the os_secure_boot=required property was carried over.

Secure Boot works by verifying that the bootloader on disk is signed by a certificate trusted by the UEFI firmware (OVMF) running on the hypervisor. The OVMF Secure Boot certificate database (db, KEK, PK) on the destination hypervisors may differ from the source environment. When the bootloader signature cannot be validated against the destination certificate database, OVMF denies access to the boot disk and blocks the EFI shell, resulting in a non-bootable VM.

Diagnostics

1

Verify image properties

Check the image metadata in the destination environment for Secure Boot and firmware configuration.

OpenStack CLI
$ openstack image show <IMAGE_ID> --fit
Sample Output
+------------------+------------------------------------------------------+
| Field            | Value                                                |
+------------------+------------------------------------------------------+
| properties       | hw_firmware_type='uefi',                             |
|                  | hw_machine_type='q35',                               |
|                  | hw_disk_bus='scsi',                                  |
|                  | hw_scsi_model='virtio-scsi',                         |
|                  | os_secure_boot='required'                            |
+------------------+------------------------------------------------------+

Confirm the following in the properties field:

  • hw_firmware_type — must be uefi

  • os_secure_boot — if set to required, this is the cause of the boot failure

  • hw_machine_type — must be q35 for UEFI

  • hw_disk_bus — typically scsi with hw_scsi_model=virtio-scsi

2

Verify boot volume metadata

If the VM boots from a volume, confirm that the volume also carries the correct image metadata. Missing metadata causes the VM to default to BIOS boot.

OpenStack CLI
$ openstack volume show <VOLUME_ID>
Sample Output
+------------------------+----------------------------------------------+
| Field                  | Value                                        |
+------------------------+----------------------------------------------+
| volume_image_metadata  | {hw_firmware_type: uefi,                     |
|                        |  hw_machine_type: q35,                       |
|                        |  os_secure_boot: required}                   |
+------------------------+----------------------------------------------+

If hw_firmware_type is absent from volume_image_metadata, the VM will boot via BIOS (SeaBIOS) instead of UEFI. If os_secure_boot=required is present, the Secure Boot mismatch applies to the volume as well.

3

Compare source and destination image properties

If access to the source environment is available, compare image properties between both environments to identify any metadata discrepancies.

OpenStack CLI

# Source environment
$ openstack image show <SOURCE_IMAGE_ID> --fit

# Destination environment
$ openstack image show <DEST_IMAGE_ID> --fit

Verify that all hw_* properties match between environments. Pay particular attention to os_secure_boot.

If all checks above match, proceed to Resolution.

Resolution

Disable Secure Boot on the destination image and create a new boot volume that inherits the updated metadata.

1

Disable Secure Boot on the image

2

Create a new boot volume from the updated image

Existing volumes retain the old metadata. Create a new volume from the updated image to inherit the corrected properties.

The existing boot volume is not updated retroactively. A new volume must be created.

3

Launch a new VM and verify boot

Create a new VM from the updated volume or image and confirm the VM boots successfully past the UEFI firmware stage without Access Denied or No bootable device errors.

Validation

1

Confirm updated image properties

Verify that os_secure_boot is disabled (or absent) and that all hw_* properties are correct.

2

Confirm the new boot volume inherited correct metadata

Confirm that volume_image_metadata contains hw_firmware_type=uefi and does not contain os_secure_boot=required.

3

Verify VM boots successfully

Open the VM console and confirm Windows boots past the UEFI firmware stage without Access Denied or No bootable device errors.

A successful boot shows the Windows login screen or desktop without any OVMF error output.

PreviousVM Migration and Booting issue due to Disk Format MismatchNextGPU Host Convergence Failure Due to Invalid mdev_config Format

Last updated