| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-05 | |||
| 07:09:28 | takashin | brinzhang: If the microversion less than 2.78, the delete_on_termination field will not contained in the response. But it is not problem because the parameter description says delete_on_termination has been added since microversion 2.78. | |
| 07:14:20 | brinzhang | takashin: thanks, I will replace it by follow-up. | |
| 07:47:35 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.opendev.org/621646 | |
| 07:58:02 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Make evacuation respects anti-affinity rule https://review.opendev.org/649963 | |
| 07:58:02 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Fix live migration break group policy simultaneously https://review.opendev.org/651969 | |
| 08:07:59 | openstackgerrit | Brin Zhang proposed openstack/python-novaclient master: Microversion 2.78: Add delete_on_termination to volume-attach API https://review.opendev.org/673485 | |
| 08:34:00 | openstackgerrit | Yongli He proposed openstack/nova master: Clean up orphan instances virt driver https://review.opendev.org/648912 | |
| 08:34:01 | openstackgerrit | Yongli He proposed openstack/nova master: clean up orphan instances https://review.opendev.org/627765 | |
| 08:41:42 | kashyap | aspiers: This is from OpenSUSE, see the maddenning number of OVMF binaries :-( -- http://paste.openstack.org/show/693648/ | |
| 08:41:46 | kashyap | aspiers: An impressive 35 | |
| 08:42:54 | kashyap | aspiers: Anyway, can you get the same output from SLES? (`rpm -ql qemu-ovmf-x86_64`) | |
| 08:44:09 | kashyap | aspiers: But my educated guess is that, these two are the recommended ones for Secure Boot: | |
| 08:44:12 | kashyap | /usr/share/qemu/ovmf-x86_64-ms-4m-code.bin | |
| 08:44:14 | kashyap | /usr/share/qemu/ovmf-x86_64-ms-4m-vars.bin | |
| 08:44:27 | kashyap | (The above are from OpenSUSE. Hopefully they're similarly named on SLES.) | |
| 08:45:20 | kashyap | aspiers: In short, for SB, you want the 'ms'-variant '-code.bin' (and its corresponding '-vars.bin') | |
| 08:46:26 | aspiers | kashyap: it's not 35, you're counting text files and directories in that | |
| 08:46:38 | aspiers | kashyap: but still agree that it's way too many | |
| 08:46:51 | kashyap | aspiers: Yeah, sorry, exaggerated; do rake me on coals | |
| 08:46:54 | aspiers | XD | |
| 08:47:20 | aspiers | It's the same on SLES | |
| 08:52:45 | dr_gogeta86 | good morning | |
| 08:52:58 | dr_gogeta86 | any hitachi guys here ? | |
| 08:58:03 | kashyap | aspiers: Okay, then. Do you have the recorded notes from your previous successful Secure Boot? | |
| 08:58:21 | kashyap | aspiers: If so, I'd bet they are the ms-variant binaries. | |
| 08:58:50 | aspiers | kashyap: No it was -suse-code | |
| 08:59:55 | kashyap | aspiers: Ah, okay. So they are the MS-enrolled ones for SLES | |
| 09:00:11 | aspiers | kashyap: But the problem is I'm trying to boot an unreleased test kernel | |
| 09:00:18 | aspiers | so it doesn't have the official signature | |
| 09:01:00 | kashyap | Nod; for this unrelease kernel, either you just go into the Tianocore BIOS and disable SB | |
| 09:01:20 | aspiers | kashyap: https://en.opensuse.org/openSUSE:UEFI#Booting_a_custom_kernel has been suggested | |
| 09:01:53 | kashyap | Yep, those are the steps the Secure Boot / BIOS dev I know recommended too | |
| 09:02:05 | kashyap | You have to do a lot of manual muckery, generate certs, run 'mokutil', etc | |
| 09:03:12 | aspiers | kashyap: do BIOS definitions get persisted to the VARS file? is that what https://review.opendev.org/#/c/621646/ is about? | |
| 09:04:11 | aspiers | kashyap: I'm confused by that commit, because even without it I *already* see the vars files persisting in /var/lib/libvirt/qemu/nvram | |
| 09:04:26 | kashyap | aspiers: The VARS file contains anything a user configures. | |
| 09:04:28 | aspiers | Oh, that's the bug | |
| 09:04:54 | kashyap | aspiers: The context is: just like traditional BIOS, UEFI has menus (just more of them), and needs to store them somewher | |
| 09:04:55 | aspiers | "Anything" meaning what though? BIOS settings? anything else? | |
| 09:05:10 | kashyap | So, if a user customizes something, it goes into the "VARS" file | |
| 09:06:00 | kashyap | aspiers: One of the things it stores is the UEFI keys | |
| 09:07:45 | kashyap | aspiers: Yeah, the bug is reinitializing a VARS from the default template, which is is undesirable. | |
| 09:08:51 | aspiers | right | |
| 09:09:00 | aspiers | so e.g. SB would have to be disabled every boot | |
| 09:09:19 | aspiers | there should really also be some way to change the default template | |
| 09:09:23 | aspiers | even per image | |
| 09:10:10 | kashyap | aspiers: In what else way do you want to "change the default (VARS) template"? | |
| 09:10:34 | aspiers | e.g. disabling SB | |
| 09:10:45 | aspiers | or any other BIOS tweak you can imagine | |
| 09:11:46 | kashyap | You don't want to mess with the default template itself, but rather do what libvirt does -- copy it per guest, in the "domain private path", and _then_ do what you want | |
| 09:12:06 | kashyap | aspiers: If you _don't_ want SB, then simply use the un-enrolled VARS file. | |
| 09:12:14 | aspiers | How? | |
| 09:12:28 | aspiers | I guess I didn't explain the use case clearly enough | |
| 09:12:38 | aspiers | Let's say I want to boot 100 VMs with SB, and another 100 without SB | |
| 09:12:41 | aspiers | How do I do that? | |
| 09:12:59 | kashyap | This way: | |
| 09:13:48 | kashyap | - For the 100 VMs with SB: When booting the guest, use the OVMF the binary that is built with SB/SMM (i.e. suse-code.bin) | |
| 09:14:24 | kashyap | - For the 100 VMs with SB: When booting the guest, use the OVMF the binary that is *not* with SB/SMM (i.e. suse.bin -- or whatever it's called) | |
| 09:14:30 | aspiers | But as an unprivileged non-admin how do I choose which OVMF binary gets used? | |
| 09:15:07 | kashyap | (Both the above is for UEFI boot, though.) | |
| 09:15:12 | kashyap | aspiers: So for a non-admin uesr: | |
| 09:15:36 | kashyap | You simply _don't_ set the 'uefi' image property | |
| 09:15:52 | aspiers | No, because then SEV breaks | |
| 09:16:13 | kashyap | Ah! We're talking in SEV context | |
| 09:16:17 | aspiers | Of course :) | |
| 09:16:24 | aspiers | Well, just as an example | |
| 09:16:28 | kashyap | Forgot the world spins around SEV for a sec :D | |
| 09:16:39 | aspiers | It's one example of a more general issue | |
| 09:16:58 | aspiers | What if I want to boot 100 VMs with some UEFI option tweaked and 100 with it not tweaked? It's not always going to be the case that there's a binary offering exactly what I want; there should be an option to create custom VARS templates, and to choose which VARS template to start from | |
| 09:17:04 | kashyap | aspiers: Now the question is: why would you want SEV *without* SB? | |
| 09:17:24 | aspiers | Well I already gave yesterday's example: testing new unsigned kernels | |
| 09:17:48 | aspiers | but please don't get hung up on the SEV part, that's just one example | |
| 09:18:00 | kashyap | Sure, sure. | |
| 09:18:17 | aspiers | It seems entirely reasonable to assume that at some point hardly anyone will want to boot non-UEFI | |
| 09:18:35 | kashyap | aspiers: For enrolling your own VARS files, the process is not "simple" :-( | |
| 09:18:48 | aspiers | and even though maybe most people will want SB and other default UEFI options most of the time, I'm sure they will want non-defaults at other times | |
| 09:19:09 | kashyap | E.g. to enroll _default_ UEFI (MS) keys (which most distros ship now), we wrote this tool: https://github.com/puiterwijk/qemu-ovmf-secureboot | |
| 09:19:13 | aspiers | and at those other times, it will *not* be acceptable to manually go into the console of every single VM at boot-time and press Escape and manually customise things | |
| 09:19:41 | aspiers | This is entirely analogous to the need for datacentre operators to tweak legacy BIOS settings over 1000s of machines | |
| 09:20:08 | aspiers | At some point around 2002, people got really tired and fed up of having to do that | |
| 09:20:20 | aspiers | so the h/w vendors gradually introduced ways of programmatically tweaking the BIOS settings | |
| 09:20:34 | aspiers | What we are talking about here is just the 2019 equivalent of that problem | |
| 09:20:35 | kashyap | aspiers: Yeah, I completely agree that manually tweaking BIOS settings at boot-time is fugly | |
| 09:20:42 | kashyap | (And undesirable) | |
| 09:20:58 | aspiers | OK, so do you now see why customisable VARS templates are useful? | |
| 09:21:13 | aspiers | or am I missing another way to achieve the same? | |
| 09:21:53 | kashyap | aspiers: I see the rationale for customizable VARS templates -- | |
| 09:22:37 | kashyap | but for most majority use cases won't need it | |
| 09:22:51 | kashyap | aspiers: On any other way -- we can ask Laszlo (OVMF maint) on email | |
| 09:23:16 | aspiers | Why would most use cases need it any less than people needed to tweak BIOS settings in 2002? | |
| 09:23:31 | aspiers | I would expect more need if anything, since surely UEFI is way more tweakable | |
| 09:23:47 | aspiers | although granted I know very little about UEFI | |
| 09:24:28 | kashyap | Yeah, I don't claim to be an expert either. | |
| 09:26:15 | aspiers | Anyway, that's thinking ahead. So for now it sounds like there is no way to cater for use case #1 - i.e. choosing per SEV image whether to use SB or not | |
| 09:26:29 | kashyap | aspiers: Talking to a BIOS dev: | |
| 09:26:31 | aspiers | so that makes my life a little harder | |
| 09:26:46 | kashyap | 11:24 <kashyap> Do you know of any other way to create customizable VARS files? | |
| 09:26:49 | kashyap | 11:24 <puiterwijk> There's no way, just boot and enter the tianocore bios setup | |
| 09:27:12 | aspiers | kashyap: Sure, *creation* is the easy part. It's the *reuse* which I'm talking about. | |
| 09:27:26 | aspiers | Creation of a VARS template only has to be done once, so manual is fine | |