Earlier  
Posted Nick Remark
#openstack-nova - 2025-10-21
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 r-taketn sean-k-mooney: ok. sorry. I'll fix it.
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: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 Uggla #endmeeting
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 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-10-21-16.00.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 Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-10-21-16.00.log.html
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 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: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 Why did this happen
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 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:24 zigo Traceback (most recent call last):
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 inspector.safety_check()
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.
10:07:31 sean-k-mooney the master just has type hints
10:08:20 sean-k-mooney well there is a __main__.py for the module
10:08:35 zigo Yeah, but something in /usr/bin would have been much nicer.
10:08:37 sean-k-mooney but you can basiclly just copy paste it somehwere and run it with the older version of oslo
10:08:44 zigo I'll see if I can push such patch ! :)
10:09:06 zigo Oh, I see. Ok, thanks.
10:09:07 sean-k-mooney i think we did that to not pullute /usr/bin with a debug helper
10:09:34 sean-k-mooney but i dont really have a strong opionion either way
10:10:29 sean-k-mooney if we wanted it to be a cli in /bin all that really needed is addting the console_scripts entry point ot setup.cfg to point at the cli module
10:11:12 sean-k-mooney although on master yo uwoudl now do that via pyproject.toml i think
10:12:10 zigo python3 -m oslo_utils.imageutils -i /path/to/disk <--- Shows nothing, just exists. This means validated in Flamingo ?
10:13:08 sean-k-mooney zigo: anyway my hunch is the mbr is subtlly invalid and not fully complient with the gpt spec
10:13:19 sean-k-mooney am thatm mean our error handleing sucks :)
10:13:25 sean-k-mooney try adding -v
10:13:53 zigo # python3 -m oslo_utils.imageutils -v -i /path/to/disk
10:13:53 zigo SAFETY_CHECK_PASSED=False
10:13:53 zigo VIRTUAL_SIZE=262144
10:13:53 zigo ACTUAL_SIZE=262144
10:13:55 zigo IMAGE_FORMAT="gpt"
10:13:57 zigo OSLO_UTILS_VERSION="9.1.0"
10:14:00 zigo FAILURE_REASONS='mbr: GPT MBR has invalid start CHS'
10:14:14 sean-k-mooney there you go
10:14:23 zigo Great, that was very helpful sean!
10:14:26 sean-k-mooney lookign at the code it exits 0 on success and 1 on failure by default
10:15:09 sean-k-mooney so that is form here https://github.com/openstack/oslo.utils/blob/stable/2025.2/oslo_utils/imageutils/format_inspector.py#L1267-L1270

Earlier   Later