Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-01-19
17:08:00 nicolairuckel I think it would make sense if tkajinam files the bug as he knows more about it but of course I can also write something and then update it with feedback from tkajinam and sean-k-mooney. I'm fine either way.
17:08:02 sean-k-mooney i think that woudl only cause issues if we had bindep problems like how we define pcre as a dep
17:08:23 tkajinam sean-k-mooney, yup
17:08:31 sean-k-mooney i could be wrong about that but it is good to keep an eye on the py313 job in any case
17:09:10 sean-k-mooney so for the secure boot optional case i have 2 tought on it
17:09:46 sean-k-mooney as i noted above i think the fact we dont fix the behavior on first boot is arguabel a but but that does not mean there is not merit in the current behavior
17:10:05 sean-k-mooney my concern with it ever changign after the workload is created is basiclly it can break the geust os if it does
17:10:38 sean-k-mooney my other tought on this is dan mention that the ver all interaction is starting to get complex enough that perhaps we need a spec to defien the behvior longterm
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

Earlier   Later