You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
teach propolis-server to understand configurable boot order (#756)
while we accept a list of boot options here, note that Nexus intentionally has a
more reductive view, maintaining only a single boot_disk. this is heavily based
on what i've learned writing tests for how OVMF+guests behave with different
mixes of boot device orders and sources of boot configuration.
this conversation on RFD 470:
oxidecomputer/rfd#751 (comment)
gets at the crux of it - we don't have like a platform NVRAM device
for guests to persist EFI variables in, so boot configuration is persisted in
the EFI system partition (so, associated with a disk, not an instance). because
we're not going to go modify the EFI system partition in user disks to effect
boot order preferences, we're using the QEMU-style fw_cfg mechanism to indicate
boot order. this, in turn, means that guest settings are blown away and replaced
with what OVMF determines at boot time.
taken together, this isn't an ideal spot to be in if we were to support more
complex boot behavior logic, and it's probably not how we want to work
multi-device orderings into propolis-server. it also means that guest-managed
boot ordering just don't reliably persist if the instance is configured with a
specific boot device!
in the future with managed nonvolatile storage for guest firmware to persist
settings in, we'll be in a somewhat better position to extend boot logic, and so
this PR should leave us able to do so without much API hassle. that will
probably be more interesting on the control plane side, which is why i'm
permissive on the Propolis side, but restrictive on the Nexus side.
along the way, this change brings PHD device/backend names in line with
propolis-server.
0 commit comments