Missing Option to Modify Boot Entries/Order running OpenHCL on Hyper-V

[excelsi]

When i run a OpenHCL VM on Hpyer-V i have no Option to modify the Boot Entries/Order in Hpyer-V MMC/Powershell:

With Powershell the Set-VMFirmware Cmdlet with the Boot Option Values also dont modify anything on the Boot Order/Entries:

Would be nice to have a way to modify it. Thanks!

[jstarks]

That's an interesting point. When a VM is configured for OpenHCL, the firmware handling is entirely owned by OpenHCL, and Hyper-V only has limited paths to influence that. For example, Hyper-V can tell OpenHCL to enable secure boot, but it apparently cannot pre-populate the boot order.

I don't know if @mebersol or @daprilik have any ideas here.

[daprilik]

I can't comment from the Hyper-V side (will let someone else take point there), but I will note that OpenHCL expects to get information regarding PCAT boot order via the GET, as part of the initial Device Platform Settings payload:

https://github.com/microsoft/openvmm/blob/304657e/vm/devices/get/guest_emulation_transport/src/api.rs#L102

This could be a wiring issue on the Hyper-V side.

[jstarks]

This is UEFI, though, not PCAT.

[daprilik]

Whoops, yep, you're right.

Sorry about that - I was also looking at #161 this morning, and I guess some wires got crossed.

---

I believe this is expected behavior at this time.
We do not currently support configuring OpenHCL's boot order when running UEFI-based Generation 2 VMs.

Generation 1 (BIOS-based VMs) were easy to get working, since the data flows unidirectionally (Hyper-V sets the boot order, and OpenHCL passes it along to PCAT during VM init). I wired it up as a "drive by", while plumbing through other bits of Hyper-V configuration.

Generation 2 (UEFI-based VMs) are more complex, as boot order is determined by the non-volatile, guest visible BootOrder#### UEFI NVRAM variables, and there was more nuanced interplay between Hyper-V's configuration and the data stored inside the non-volatile store controlled by OpenHCL. Since boot order management wasn't relevant to Azure scenarios, we put this work on the backlog, and have yet to circle back to it.

I'll let @mebersol chip in with any additional context here.

[mebersol]

Previous comments are correct - the Hyper-V code that populates the UI pane showing boot order no longer has direct access to the NVRAM store that backs these boot order variables (it is owned by the paravisor). Additional Hyper-V work will be required to support this scenario; it is something we are aware of and tracking. One future possibility is for the paravisor to pass a boot order view to the host (which could be stored for UI display, etc.), as well as support for the host to offer the ability to change the boot order as well. That design is not yet closed.

Note that initial provisioning should be possible using the custom_uefi_json_data path, although this is not yet well-documented.