search

microsoft / openvmm

Home of OpenVMM and OpenHCL.
http://openvmm.dev/
MIT License
1.57k stars 84 forks source link

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

Open excelsi opened 1 month ago

excelsi commented 1 month ago

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

Image

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

Image

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

jstarks commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

This is UEFI, though, not PCAT.

daprilik commented 1 month ago

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 commented 1 month ago

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.