| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-10-21 | |||
| 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. | |
| 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 | ACTUAL_SIZE=262144 | |
| 10:13:53 | zigo | VIRTUAL_SIZE=262144 | |
| 10:13:53 | zigo | SAFETY_CHECK_PASSED=False | |
| 10:13:53 | zigo | # python3 -m oslo_utils.imageutils -v -i /path/to/disk | |
| 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 | |
| 10:19:05 | sean-k-mooney | so that path means that the os type is 0xEE a protective MBR https://uefi.org/specs/UEFI/2.10/05_GUID_Partition_Table_Format.html#os-types | |
| 10:25:15 | sean-k-mooney | the check that is failign is "(starth, starts, startt) != (0x00, 0x02, 0x00):" thats StartHead StartSector and StartTrack | |