settingsLogin | Registersettings

[openstack-dev] [nova] how does UEFI booting of VM manage per-instance copies of OVMF_VARS.fd ?

0 votes

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/OVMFCODE.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 ?

o i 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

o how does NOVA manage this ?

§ e.g. is the unique instance of OVMF_VARS.fd created in
/etc/nova/instances// ?

o ... and does this get migrated to another compute if VM is migrated ?

Greg.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Sep 28, 2017 in openstack-dev by Waines,_Greg (2,700 points)   1 4 9

4 Responses

0 votes

Any info on this ?

I did launch a VM with UEFI booting and did not see any copy of OVMFVARS.fd proactively copied into /etc/nova/instances// .
Maybe Nova only does that on a change to OVMF
VARS.fd ???
( haven’t figured out how to do that )

anyways any info or pointers would be appreciated,
thanks,
Greg.

From: Greg Waines Greg.Waines@windriver.com
Reply-To: "openstack-dev@lists.openstack.org" openstack-dev@lists.openstack.org
Date: Wednesday, September 27, 2017 at 9:09 AM
To: "openstack-dev@lists.openstack.org" openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova] how does UEFI booting of VM manage per-instance copies of OVMF_VARS.fd ?

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/OVMFCODE.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 ?

o i 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

o how does NOVA manage this ?

§ e.g. is the unique instance of OVMF_VARS.fd created in
/etc/nova/instances// ?

o ... and does this get migrated to another compute if VM is migrated ?

Greg.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 28, 2017 by Waines,_Greg (2,700 points)   1 4 9
0 votes

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// ?

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 [1]:

LOG.warning("uefi support is without some kind of "
"functional testing and therefore "
"considered experimental.")

[1]
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4530-L4532

From what I can tell, the bootloader is hardcoded to
"/usr/share/OVMF/OVMFCODE.fd" for x8664:

https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L130

https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4534-L4535

and I see no way to change it via a configuration variable...

Yet another half-baked, completely untested "feature" added to Nova. :(

-jay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 28, 2017 by Jay_Pipes (59,760 points)   3 10 13
0 votes

----- Original Message -----
From: "Jay Pipes" jaypipes@gmail.com
To: openstack-dev@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// ?

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 [1]:

LOG.warning("uefi support is without some kind of "
"functional testing and therefore "
"considered experimental.")

[1]
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4530-L4532

From what I can tell, the bootloader is hardcoded to
"/usr/share/OVMF/OVMFCODE.fd" for x8664:

https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L130

https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4534-L4535

and I see no way to change it via a configuration variable...

Yet another half-baked, completely untested "feature" added to Nova. :(

-jay

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:

https://review.openstack.org/#/c/506720/

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.

Thanks,

--
Steve Gordon,
Principal Product Manager,
Red Hat OpenStack Platform


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 28, 2017 by Steve_Gordon (9,680 points)   2 5 5
0 votes

Hey just a follow up on this ...

FYI ... it does appear that when UEFI booting a VM, a per-instance copy of the OVMF_VARS.fd is indeed created.
See below:

root 97276 1 0 Oct05 ? 00:01:41 /usr/libexec/qemu-kvm -c 0x00000000000000000000000000000001 -n 4 --proc-type=secondary --file-prefix=vs -- -enable-dpdk -name guest=instance-0000003a,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-instance-0000003a/master-key.aes -machine pc-i440fx-rhel7.3.0,accel=kvm,usb=off,dump-guest-core=off -drive file=/usr/share/OVMF/OVMFCODE.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/instance-0000003aVARS.fd,if=pflash,format=raw,unit=1 -m 512 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -object memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/mnt/huge-2048kB/libvirt/qemu/2-instance-0000003a,share=yes,size=536870912,host-nodes=0,policy=bind -numa node,nodeid=0,cpus=0,memdev=ram-node0 -uuid 13c69f91-e91d-4162-aea5-d53aaa7053b0 -smbios type=1,manufacturer=Fedora Project,product=OpenStack Nova,version=14.0.3-1.tis.243,serial=81f8fdfa-744c-4f60-bd39-edb5f0cfd39d,uuid=13c69f91-e91d-4162-aea5-d53aaa7053b0,family=Virtual Machine -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-instance-0000003a/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.losttickpolicy=delay -no-hpet -no-shutdown -boot reboot-timeout=5000,strict=on -global i440FX-pcihost.pci-hole64-size=67108864K -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/dev/disk/by-path/ip-192.168.205.6:3260-iscsi-iqn.2010-10.org.openstack:volume-4c1d2d08-5f13-42ee-8cd4-db950614e031-lun-0,format=raw,if=none,id=drive-ide0-0-0,readonly=on,serial=4c1d2d08-5f13-42ee-8cd4-db950614e031,cache=none,aio=native -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 -drive file=/dev/disk/by-path/ip-192.168.205.6:3260-iscsi-iqn.2010-10.org.openstack:volume-c2c57148-c7ca-4516-8f06-6ed205524057-lun-0,format=raw,if=none,id=drive-virtio-disk0,serial=c2c57148-c7ca-4516-8f06-6ed205524057,cache=none,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -chardev socket,id=charnet0,path=/var/run/vswitch/usvhost-b3113aee-fc06-4277-8e65-c6f2c3b0415d -netdev vhost-user,chardev=charnet0,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:69:16:ec,bus=pci.0,addr=0x3 -add-fd set=0,fd=30 -chardev file,id=charserial0,path=/dev/fdset/0,append=on -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on

Greg.

From: Steve Gordon sgordon@redhat.com
Reply-To: "openstack-dev@lists.openstack.org" openstack-dev@lists.openstack.org
Date: Thursday, September 28, 2017 at 2:50 PM
To: "openstack-dev@lists.openstack.org" openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] how does UEFI booting of VM manage per-instance copies of OVMF_VARS.fd ?

----- Original Message -----
From: "Jay Pipes" jaypipes@gmail.com
To: openstack-dev@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// ?

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 [1]:
LOG.warning("uefi support is without some kind of "
"functional testing and therefore "
"considered experimental.")
[1]
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4530-L4532
From what I can tell, the bootloader is hardcoded to
"/usr/share/OVMF/OVMFCODE.fd" for x8664:
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L130
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4534-L4535
and I see no way to change it via a configuration variable...
Yet another half-baked, completely untested "feature" added to Nova. :(
-jay

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:

https://review.openstack.org/#/c/506720/

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.

Thanks,

--
Steve Gordon,
Principal Product Manager,
Red Hat OpenStack Platform


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 6, 2017 by Waines,_Greg (2,700 points)   1 4 9
...