search

microsoft / openvmm

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

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

Open excelsi opened 2 days ago

excelsi commented 2 days 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 day 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 day 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 day ago

This is UEFI, though, not PCAT.

daprilik commented 1 day 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.