Earlier  
Posted Nick Remark
#openstack-nova - 2025-10-21
16:51:55 Uggla #linkAnnonce : https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/H5PBFZJ4X3TSGSC4YF6E4WTV43CBOVS6/
16:52:04 Uggla the trend seems to go on Monday
16:52:27 nicolairuckel I iterated on my NVRAM patch (https://review.opendev.org/c/openstack/nova/+/959682) but there's still an open issue regarding the file permissions.
16:53:36 nicolairuckel Also, I heard that it would be a good idea to bring that up for the PTG as a crossproject topic, so I'll add that to the etherpad later.
16:54:02 Uggla nicolairuckel, yep please do
16:54:35 Uggla crossproject with cinder ?
16:55:09 nicolairuckel I think so
16:55:25 nicolairuckel I was told it was related to image encryption
16:55:43 Uggla more glance though
16:55:50 nicolairuckel tbh, I'm still quite new to openstack so I'm not *that* sure about the scope yet.
16:56:32 Uggla ok I'll look at that and try to find the appropriate slot.
16:56:38 nicolairuckel thank you
16:56:40 Uggla Any expected duratio, ?
16:56:46 Uggla *duration
16:56:48 sean-k-mooney gibi: supporting freethread pytyon is defeintly a post eventlet topic.
16:57:44 Uggla r-taketn I think you would like to share something, aren't you ?
16:57:55 sean-k-mooney nicolairuckel: the nvram patch is not related to the image encyption work
16:57:57 nicolairuckel I'm not sure yet. I'll think about that and add it to the Etherpad if that's okay.
16:57:58 r-taketn yes. Thank you. I have one quick request. Could someone please check this spec and give some feedbacks later?
16:58:10 r-taketn #link https://review.opendev.org/c/openstack/nova-specs/+/962578
16:58:19 r-taketn I have proposed this spec for generalizing sev/sev-es code to add new confidential computing from other architecture(Intel TDX,Arm CCA)
16:58:25 r-taketn I have re-written the spec. In particular, I detailed the problem description about current sev/sev-es code.
16:58:25 sean-k-mooney but we shoudl dicuss the imange encyption work in the nova/glance slot.
16:58:42 sean-k-mooney r-taketn: i have not had time yet but ill tray and look at that again
16:58:56 r-taketn I have this topic on ptg slot, but I'd appreciate if you give some feedbacks in advance
16:59:04 r-taketn sean-k-mooney: Thank you
16:59:27 sean-k-mooney the real goal of this work is to enabel you to supprot arm CCA and SEV-SNP more eaisly in the future right
16:59:44 r-taketn yes
16:59:51 sean-k-mooney this is prepareing the memory encyption logic to be more generic and extensible in advance of the hardware
17:01:10 sean-k-mooney r-taketn: ok small comment initally . most of tghe work items shoudl be experses in pros in the proposed changes section and the work ites shoudl be a very short list of the thing that need to be deliverd
17:01:59 gibi sorry folks I have to drop.
17:02:01 gibi I will read back
17:02:14 Uggla gibi no pb about to close
17:02:16 sean-k-mooney r-taketn: so if you look at the sev-es spec form last cycle https://github.com/openstack/nova-specs/blob/master/specs/2025.2/implemented/amd-sev-es-libvirt-support.rst?plain=1#L287
17:02:34 Uggla Anything else you'd like to share ?
17:02:39 sean-k-mooney you can see more or less what is expected for that section vs proposed changes https://github.com/openstack/nova-specs/blob/master/specs/2025.2/implemented/amd-sev-es-libvirt-support.rst?plain=1#L50
17:03:18 sean-k-mooney r-taketn: the sev spec is a good example fo what level of detail ectra is expected that you can use as a guide
17:03:18 r-taketn sean-k-mooney: ok. sorry. I'll fix it.
17:03:19 bauzas we're overtime :)
17:03:59 Uggla bauzas atm reasonable overtime
17:04:31 r-taketn Uggla: That's all from me. thank you
17:04:46 Uggla ok so I'm going to close.
17:04:57 Uggla Thank you for participating in this meeting.
17:05:04 sean-k-mooney r-taketn: no worries at all. we just do it this way so that we we have discsed what we want to change before dissusing the impact of the change. ill look at your proposal regardless
17:05:19 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-10-21-16.00.log.html
17:05:19 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-10-21-16.00.txt
17:05:19 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-10-21-16.00.html
17:05:19 opendevmeet Meeting ended Tue Oct 21 17:05:19 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
17:05:19 Uggla #endmeeting
17:05:34 elodilles thanks Uggla o/
17:05:44 Uggla elodilles you are welcome.
17:05:50 r-taketn Thank you for discussion all
#openstack-nova - 2025-10-22
00:30:01 opendevreview Merged openstack/nova-specs master: Repropose flavor-search-by-name spec https://review.opendev.org/c/openstack/nova-specs/+/958866
05:51:46 opendevreview Taketani Ryo proposed openstack/nova-specs master: Adjust the SEV/SEV-ES code for multiple cc support https://review.opendev.org/c/openstack/nova-specs/+/962578
05:55:15 opendevreview Taketani Ryo proposed openstack/nova-specs master: Adjust the SEV/SEV-ES code for multiple cc support https://review.opendev.org/c/openstack/nova-specs/+/962578
06:12:32 alibasafa Why did this happen
06:12:32 alibasafa that, I tried to resize the instance to its own flavor, but I got an error related to FilterScheduler and zone specifications. I found that in the nova_api database, the availability_zone was updated correctly, but in the nova database, the availability_zone was not updated.
06:12:32 alibasafa can anyone answer the my question ? . I have two aggregates named general and dedicated. The availability zone of general is nova, and the zone of dedicated is another one I wanted to live migrate an instance from the nova zone to the other zone To do this, I removed the host from the dedicated aggregate and added it to the general aggregate. After the live migration completed, I moved the compute host back to the dedicated aggregate After
06:30:42 gibi It is not allowed to move instances between Availability Zones. If adding a host to an aggregate or removing a host from an aggregate would cause an instance to move between Availability Zones, including moving from or moving to the default AZ, then the operation will be rejected. The administrator should drain the instances from the host first then the host can be moved.
06:30:49 gibi https://docs.openstack.org/nova/latest/admin/availability-zones.html
06:31:27 gibi you might have an older openstack when this is not clearly rejected yet but causing issues down the line
07:51:22 opendevreview Balazs Gibizer proposed openstack/nova master: Rally job for eventlet-removal https://review.opendev.org/c/openstack/nova/+/960130
08:37:41 opendevreview Konrad Gube proposed openstack/nova master: Use Cinder's os-extend_volume_completion volume action. https://review.opendev.org/c/openstack/nova/+/873560
09:07:24 zigo inspector.safety_check()
09:07:24 zigo File "/usr/lib/python3/dist-packages/nova/virt/images.py", line 162, in do_image_deep_inspection
09:07:24 zigo Traceback (most recent call last):
09:07:24 zigo dansmith: Hi there! I'm running a Dalmatian deployment, and when uploading an image, it fails in the image inspector with the MBR:
09:07:25 zigo File "/usr/lib/python3/dist-packages/oslo_utils/imageutils/format_inspector.py", line 430, in safety_check
09:07:27 zigo raise SafetyCheckFailed(failures)
09:07:29 zigo oslo_utils.imageutils.format_inspector.SafetyCheckFailed: Safety checks failed: mbr
09:07:31 zigo Is this known, and should I backport some patches?
09:08:30 zigo https://review.opendev.org/c/openstack/oslo.utils/+/928448 maybe ?
09:50:37 zigo This doesn't fix my issue ... :/
09:51:30 sean-k-mooney zigo: i think there is a glance config option related to funky mbrs
09:51:56 zigo sean-k-mooney: The issue for me is in nova-compute.
09:52:04 zigo When it spawns the VM.
09:52:19 sean-k-mooney oh ok
09:52:40 sean-k-mooney is that the full traceback
09:52:53 zigo Nope.
09:53:22 zigo https://paste.opendev.org/show/bwgoYQ6LeWlUFYcIZ998/
09:53:30 zigo That's what I have in "server show"
09:55:24 sean-k-mooney ah, and form that i tatke it the image is in raw? format based on the call to fetch_to_raw
09:56:01 zigo Correct. The image is an upload from another cloud's /var/lib/nova/instance/<uuid>/disk
09:56:52 zigo Will it go nicer if I convert to Qcow2 first?
09:57:47 sean-k-mooney it would work in either case
09:58:10 sean-k-mooney i suspect its failing somehwere here https://github.com/openstack/oslo.utils/blob/master/oslo_utils/imageutils/format_inspector.py#L1388-L1421
09:58:29 sean-k-mooney however i woudl expect a more verbose excetion message in that case
09:59:20 zigo The image is, as much as I can tell, made from the Debian one, with grub-cloud, dual boot (ie: UEFI + mbr).
09:59:49 zigo At least it looks like it, I didn't check much, but it has all of the usual partitionning.
10:03:40 sean-k-mooney is it publicly aviable or would you beable to provide say the first 1mb of the image which has the format info so we coudl inspect it
10:04:08 zigo I'll investigate myself first. It's not a public image, it's customer's data.
10:04:09 sean-k-mooney we dont actully need the full image all the gpu info is in the first few KBs
10:04:14 sean-k-mooney ack
10:05:07 sean-k-mooney on master we provided a cli that you can use to run the inspector https://github.com/openstack/oslo.utils/blob/master/oslo_utils/imageutils/cli.py
10:05:45 sean-k-mooney so you can do python -m oslo_utils.imageutils -i /path/to/image [-v|--verbose]
10:05:48 zigo Ah, nice ! :) I can try it in my Flamingo virtualized test cluster then.
10:06:07 sean-k-mooney its in epoxy too
10:06:21 sean-k-mooney just not 2024.2
10:06:39 sean-k-mooney https://github.com/openstack/oslo.utils/blob/stable/2025.1/oslo_utils/imageutils/cli.py
10:07:29 zigo It's a shame there's no script entry point then.

Earlier   Later