[openstack-dev] [nova] how does UEFI booting of VM manage per-instance copies of OVMF_VARS.fd ?
sgordon at redhat.com
Thu Sep 28 18:50:47 UTC 2017
----- Original Message -----
> From: "Jay Pipes" <jaypipes at gmail.com>
> To: openstack-dev at lists.openstack.org
> Sent: Thursday, September 28, 2017 12:53:16 PM
> Subject: Re: [openstack-dev] [nova] how does UEFI booting of VM manage per-instance copies of OVMF_VARS.fd ?
> On 09/27/2017 09:09 AM, Waines, Greg wrote:
> > Hey there ... a question about UEFI booting of VMs.
> > i.e.
> > glance image-create --file cloud-2730. qcow --disk-format qcow2
> > --container-format bare --property “hw-firmware-type=uefi” --name
> > clear-linux-image
> > in order to specify that you want to use UEFI (instead of BIOS) when
> > booting VMs with this image
> > i.e. /usr/share/OVMF/OVMF_CODE.fd
> > /usr/share/OVMF/OVMF_VARS.fd
> > and I believe you can boot into the UEFI Shell, i.e. to change UEFI
> > variables in NVRAM (OVMF_VARS.fd) by
> > booting VM with /usr/share/OVMF/UefiShell.iso in cd ...
> > e.g. to changes Secure Boot keys or something like that.
> > My QUESTION ...
> > ·how does NOVA manage a unique instance of OVMF_VARS.fd for each instance ?
> > oi believe OVMF_VARS.fd is suppose to just be used as a template, and
> > is supposed to be copied to make a unique instance for each VM that UEFI
> > boots
> > ohow does NOVA manage this ?
> > §e.g. is the unique instance of OVMF_VARS.fd created in
> > /etc/nova/instances/<UUID>/ ?
> > o... and does this get migrated to another compute if VM is migrated ?
> Hi Greg,
> I think the following part of the code essentially sums up what you're
> experiencing :
> LOG.warning("uefi support is without some kind of "
> "functional testing and therefore "
> "considered experimental.")
> From what I can tell, the bootloader is hardcoded to
> "/usr/share/OVMF/OVMF_CODE.fd" for x86_64:
> and I see no way to change it via a configuration variable...
> Yet another half-baked, completely untested "feature" added to Nova. :(
Pretty much, just enough to convince folks it could work without enough for it to actually...work. Kasyhap was looking at this recently and has this WIP specification up for further discussion of how to best clean this up:
It's not clear to me that this covers all of the above issues as yet. As noted the existing implementation will only work with a bootloader path that lines up perfectly with what is hardcoded, and even with the distro included ones that is not necessarily the case.
Principal Product Manager,
Red Hat OpenStack Platform
More information about the OpenStack-dev