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/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/instance-0000003a_VARS.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.lost_tick_policy=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 <sgor...@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" <jaypi...@gmail.com<mailto:jaypi...@gmail.com>> To: openstack-dev@lists.openstack.org<mailto: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/<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 [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/OVMF_CODE.fd" for x86_64: 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-requ...@lists.openstack.org<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
