| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-01-19 | |||
| 17:11:05 | sean-k-mooney | the guiding principal for nova is alwasy "what woudl the behvior be if this was a physical system" | |
| 17:11:35 | sean-k-mooney | on a phsyical system rebooting host or movign it form one rack to another woudl nto change the bios config or the nvram | |
| 17:11:59 | tkajinam | nicolairuckel, I can create one later this week | |
| 17:12:00 | sean-k-mooney | however if you were reinstallign the OS you might do that | |
| 17:12:37 | sean-k-mooney | and if you are cahngign the hardware you might do that too. so rebuild and resize coudl be valid point to change the secure boot config in my view | |
| 17:13:17 | sean-k-mooney | hard reboot or cold/live migrate dont fit with the "what woudl happen with a real server" lithmus test if the secure boot or nvram sate chagnes | |
| 17:13:19 | nicolairuckel | thank you, tkajinam. Let me know if I can help/contribute. | |
| 17:13:58 | sean-k-mooney | tkajinam: nicolairuckel that the critia im trying to apply if that makes sense. | |
| 17:14:13 | nicolairuckel | yes, that makes sense to me | |
| 17:15:11 | tkajinam | sean-k-mooney, cold migration is most problematic. because it basically inherits resize which assumes that the instance can be rebuilt... | |
| 17:15:13 | sean-k-mooney | tkajinam: in the short term we could provide a workaround flag to block cold/live migration with os_secure_boot=optional or we could record the current state somewhere say in instnace_system_netadata and ensure it does not change when we do migrate | |
| 17:16:07 | sean-k-mooney | tkajinam: ya, the other wrinkel is we can preserve the nvram if its there but unfrotuanlly that is not enough to tell us if we need to enable secure boot or not in the xml | |
| 17:16:17 | tkajinam | makes sense | |
| 17:17:12 | sean-k-mooney | that why we need to stash the state somewhere in the cold migrate and shelve/unshelve case | |
| 17:17:40 | sean-k-mooney | shelve/unshelve today loses the nvram so it will regenerate it regardless today | |
| 17:18:03 | tkajinam | another scenario I still have to consider in additiona to os_firmware_secure='optional' is the case where a different firmware is selected after hard reboot but I'll give more thoughts to it. | |
| 17:18:07 | sean-k-mooney | but again preserving it is out of scope fo the iniall reboot bug | |
| 17:18:21 | tkajinam | an annoying thing is that it's not clear how these firmware files are updated (due to no documentation about their update policy) | |
| 17:19:08 | sean-k-mooney | right the frimware itself and the base tempelates are part of the ovmf package i bleive | |
| 17:19:15 | tkajinam | yeah | |
| 17:19:16 | sean-k-mooney | so they update when the host package is updated | |
| 17:20:05 | sean-k-mooney | tkajinam: when we use the statelest firmware feature do we still have an nvram file? i think no correct? | |
| 17:20:15 | tkajinam | sean-k-mooney, no | |
| 17:20:52 | tkajinam | yeah so one example question which I can't answer now is "can existing code file and var file be updated when ovmf package is updated ? then do we need to reset nvram in that case ?" | |
| 17:21:05 | sean-k-mooney | its unfortunet that windows stores it bitlocker keys or key config in the nvram file | |
| 17:21:30 | tkajinam | I totally agree | |
| 17:21:33 | sean-k-mooney | the update of the ovmf package just updates teh template | |
| 17:21:56 | sean-k-mooney | but i guess nova woudl have update the backign file because the existng nvram was lost on hard-reboot | |
| 17:22:40 | sean-k-mooney | so in parctis it woudl have updated after the next vm reboot after the host package but i dont think that is what shoudl have been expected | |
| 17:23:47 | tkajinam | I hope so but compatibility between template and var is quite unclear, tbvh | |
| 17:24:17 | sean-k-mooney | ya im not really sure how the qemu/libvirt/ovmf comuity expect that too work | |
| 17:24:51 | sean-k-mooney | if they provided a migraton tool to migrate the nvram file to a newer version invoking that woudl be a potinally reasonabel thing to do on hard reboot | |
| 17:25:05 | sean-k-mooney | but im not aware of any such tool | |
| 17:25:16 | sean-k-mooney | it might exsit i have never looked into it | |
| 17:28:46 | sean-k-mooney | ai says no that tool does not exsit for what that worth | |
| 17:29:42 | nicolairuckel | Is there other software that uses qemu, libvirt, or ovmf that may have the same problem? | |
| 17:30:16 | nicolairuckel | Then it might make sense to see how other projects handle that issue. | |
| 17:30:31 | sean-k-mooney | yes, kubvirt, proxmox and virtuozo but apprently the fix is delete the file losing the data and just recreate it in the rare case it does nto work | |
| 17:30:44 | sean-k-mooney | apprently imcompatiablity is rare | |
| 17:30:55 | nicolairuckel | That doesn't sound like a very elegant solution though. | |
| 17:31:20 | sean-k-mooney | its not but unintally that has been what nova did by defualt becuase we were alwsy regenerating it | |
| 17:35:42 | nicolairuckel | I see... | |
| 17:36:57 | sean-k-mooney | nova uefi supprot predates secure boot support and bitlocker using the nvram var to sotre its config so that behavior as not initally observed or problematic | |
| 17:38:00 | sean-k-mooney | i.e. we were not aware that libvirt was deletign the nvram when we underfiend the domain. | |
| 17:42:07 | tkajinam | quick search shows kubevirt supports persistence of uefi vars (which by default does not persist uefi vars) but no useful information about its lifecycle management really :-( | |
| 17:42:16 | tkajinam | https://kubevirt.io/user-guide/compute/persistent_tpm_and_uefi_state/ | |
| 17:44:24 | tkajinam | if anyone from the core have a moment to review/merge https://review.opendev.org/c/openstack/python-novaclient/+/973846 to fix py313 job, that'd be nice. | |
| 17:55:20 | sean-k-mooney | tkajinam: i belive that a releivitly new fetature and it currently has some limeiations | |
| 17:56:02 | sean-k-mooney | tkajinam: there are some internal difcusion with the virt folks about the correct way that and vtpm should sork i bleive and htey havnt really figuried it all out yet | |
| 17:56:31 | tkajinam | hmm | |
| 17:56:36 | sean-k-mooney | i dont really know the details jsu tnoteice it was on the virt devel list which might be upstream actully not sure | |
| 17:57:16 | sean-k-mooney | there was some discussion about live migration and the use of pvcs to store the nvram/tpm data | |
| 17:57:54 | sean-k-mooney | im ont aware of anythign related to "how do we mighate teh data if ovmf updates" | |
| 17:57:56 | tkajinam | ok | |
| 17:58:49 | tkajinam | I'll see if any public outcome can be found | |
| 17:58:53 | tkajinam | sean-k-mooney, thanks for that info ! | |
| 17:59:15 | sean-k-mooney | what im tryign to avoid is the need to have a glance iamge property or flavor extra spec for persictence other then the ephermal firmware flag | |
| 17:59:41 | sean-k-mooney | basiclaly if you want ephermal firmware i think you shoudl opt into it | |
| 18:00:16 | sean-k-mooney | otherwise we shoudl treat the tpm and nvram data as user data and persitit it | |
| 18:00:43 | sean-k-mooney | i have no idea where we woudl eventually store it for shleve but that a future us problem | |
| 18:02:22 | sean-k-mooney | orginally i was hopign the tpm and nvram files would be small enough to be able to store as secrete in barbican in teh future | |
| 18:02:37 | sean-k-mooney | but that was just an idea not something i looked into | |
| 18:03:37 | sean-k-mooney | the nvram and tpm data is privlaged enouch that i woudl not be comfrotable storign it in glance unless it was encypted | |
| #openstack-nova - 2026-01-20 | |||
| 09:26:32 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: stop using _get_mem_encryption_config() for SEV checks https://review.opendev.org/c/openstack/nova/+/967970 | |
| 09:26:32 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: refactor memory encryption trait logic for extensiblity https://review.opendev.org/c/openstack/nova/+/967971 | |
| 09:26:33 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: make RP creation independent of specific encryption models https://review.opendev.org/c/openstack/nova/+/967972 | |
| 09:26:33 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: refactor _guest_configure_mem_encryption() for extensibility https://review.opendev.org/c/openstack/nova/+/967973 | |
| 09:26:34 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: adjust requirement checks for mem_encryption guests https://review.opendev.org/c/openstack/nova/+/967974 | |
| 09:26:34 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: introduce a check between mem_encryption and locked_memory https://review.opendev.org/c/openstack/nova/+/971300 | |
| 11:14:17 | opendevreview | Serhii Ivanov proposed openstack/nova master: Add Linux bridge support to `network_data.json` https://review.opendev.org/c/openstack/nova/+/973924 | |
| 13:05:06 | opendevreview | Serhii Ivanov proposed openstack/nova master: Add Linux bridge support to `network_data.json` https://review.opendev.org/c/openstack/nova/+/973924 | |
| 14:12:41 | opendevreview | Johannes Kulik proposed openstack/nova master: Attaching a volume returns HTTP 202 https://review.opendev.org/c/openstack/nova/+/971068 | |
| 14:14:30 | opendevreview | Takashi Kajinami proposed openstack/nova master: Replace obsolete PCRE packages https://review.opendev.org/c/openstack/nova/+/970063 | |
| 14:17:02 | opendevreview | Takashi Kajinami proposed openstack/placement master: Replace obsolete PCRE packages https://review.opendev.org/c/openstack/placement/+/970068 | |
| 14:18:24 | opendevreview | Serhii Ivanov proposed openstack/nova master: Add Linux bridge support to `network_data.json` https://review.opendev.org/c/openstack/nova/+/973924 | |
| 14:19:47 | opendevreview | Takashi Kajinami proposed openstack/python-novaclient master: Replace obsolete PCRE packages https://review.opendev.org/c/openstack/python-novaclient/+/970066 | |
| 14:36:22 | opendevreview | Zhan Zhang proposed openstack/nova-specs master: Refine network setup procedure in live migrations https://review.opendev.org/c/openstack/nova-specs/+/970298 | |
| 14:52:10 | tkajinam | sean-k-mooney bauzas gibi, if you are around, could you review https://review.opendev.org/c/openstack/python-novaclient/+/973846 to fix py313 job ? | |
| 14:52:34 | tkajinam | the same bindep update was made in nova repo earlier by https://review.opendev.org/c/openstack/nova/+/970011 ... | |
| 14:52:39 | sean-k-mooney | tkajinam: sure i was trying to decied what to start next thats as good as anything else | |
| 14:52:54 | bauzas | done | |
| 14:53:00 | bauzas | sorry pretty busy this afternoon with meetings | |
| 14:53:04 | gibi | double done | |
| 14:53:05 | bauzas | but I've +2d it | |
| 14:53:07 | gibi | :D | |
| 14:53:20 | sean-k-mooney | ok i wont bother | |
| 14:53:22 | gibi | :) | |
| 14:53:38 | sean-k-mooney | the one think i was going to say is while we generally use whereto for the doc redirect | |
| 14:53:49 | sean-k-mooney | its a dep that is minimally maintained in oslo | |
| 14:53:56 | tkajinam | bauzas gibi sean-k-mooney, thanks all ! | |
| 14:53:57 | tkajinam | yeah | |
| 14:54:07 | sean-k-mooney | so long term we may consider droping it but i dont knwo what woudl replce it | |
| 14:54:16 | sean-k-mooney | we seam to have got lucky as well | |
| 14:54:29 | sean-k-mooney | there are some pcre regex changes with v2 | |
| 14:54:37 | sean-k-mooney | but we dont seam to be useign anything that chageds | |
| 14:54:42 | tkajinam | I even wonder if we need to maintain these redirects nowadays | |
| 14:54:43 | sean-k-mooney | *changed | |
| 14:55:14 | tkajinam | I've checked the repos using whereto but I've seen that all redirects were added in old days ( multiple years ago ) | |
| 14:55:21 | sean-k-mooney | ya not sure. while this isnt flat out broken there is no point it remvoing it | |
| 14:55:34 | tkajinam | yeah | |