Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-09-24
09:32:18 gokhan__ What values should I set for the hw_rescue_device and hw_rescue_bus image properties for Windows instances in OpenStack?
10:22:06 jssfr gokhan__, that probably depends on what image you want to use for rescuing?
10:22:28 jssfr if it's a windows image, I'd suggest to try a sata CDROM as bus (I think virtio still needs specific drivers on windows, so I'd stay away from that)
10:27:12 elodilles Uggla: I'm about to check and generate last-minute RCs where needed, and I see that nova has a merged bug fix on stable/2025.2 already. do you consider that bug release critical? should I generate an RC2 for that? (the bug fix is: https://review.opendev.org/c/openstack/nova/+/961804 )
10:45:51 gokhan__ jssfr, I am using windows server 2019 qcow2 image and I want to give this image also as rescue disk image.
10:51:37 jssfr gokhan__, then I'd go for hw_rescue_device=cdrom and hw_rescue_bus= ... hm, sata is not an option, then I'd first try scsi and if that doesn't work usb.
10:52:22 gokhan__ hw_rescue_device
10:52:22 gokhan__ sata didn't work jssfr
10:52:22 gokhan__ hw_rescue_bus
10:52:22 gokhan__ cdrom
10:54:07 jssfr gokhan__, yeah, I just noticed sata is not an option. try scsi and if that doesn't work, try usb.
11:00:31 gokhan__ jssfr, ok I will try with different options. may be if hw_rescue_device=cdrom we need to use .iso image.
11:46:10 gokhan__ jssfr, with windows 2019 server image iso hw_rescue_device=cdrom and hw_rescue_bus=scsi worked. I can see console. But when I try to repair instance it didn't worked. it can't show disks. it says no disk to repair
12:01:40 opendevreview Taketani Ryo proposed openstack/nova-specs master: Add a spec for 2026.1 for libvirt launching Arm CCA instances https://review.opendev.org/c/openstack/nova-specs/+/960777
12:05:47 opendevreview Taketani Ryo proposed openstack/nova-specs master: Add a spec for 2026.1 for libvirt launching Arm CCA instances https://review.opendev.org/c/openstack/nova-specs/+/960777
12:12:55 opendevreview Taketani Ryo proposed openstack/nova-specs master: Add a spec for 2026.1 for libvirt launching Arm CCA instances https://review.opendev.org/c/openstack/nova-specs/+/960777
12:18:34 ykarel_ uptime
13:03:28 gibi Copy conference info
13:03:28 gibi content_copy
13:03:28 gibi fyi eventlet sync in ~90 minutes meet.google.com/bcy-uqoz-hje
13:03:28 gibi 
13:03:40 gibi baad copy past buffer, baaad :)
13:03:53 gibi but the link is correct
13:38:44 opendevreview Balazs Gibizer proposed openstack/nova master: [hacking] N374 do not use time.sleep(0) to yield https://review.opendev.org/c/openstack/nova/+/950992
13:39:32 gibi stephenfin: thanks. Good catch of my sloppy conflict resolution on ^^. I fixed it up
14:12:14 bauzas gibi: can't join the eventlet meeting unfortunately :(
14:12:19 gibi bauzas: no worries
14:12:42 gibi the doc has some links and text about where we are if you later want to take a look
14:17:30 opendevreview Lajos Katona proposed openstack/nova master: Use SDK for Neutron subnets https://review.opendev.org/c/openstack/nova/+/962190
14:17:30 opendevreview Lajos Katona proposed openstack/nova master: Use SDK for Neutron networks https://review.opendev.org/c/openstack/nova/+/928022
14:19:22 dansmith I've not made much progress on my thing in the last week due to other distractions
14:22:18 gibi same here. but I want to get back to the rally stuff this week finally
14:26:13 gibi btw, for me devstack in 24.04 in a VM generates strangely high io load recently. So high that it affects the normla use of the host. I'm not seem to able to pinpoint the source in the VM. I rolled back libvirt and qemu to pre sept 16 version in sid and that seems to help at least to get it back to unnoticed if I don't measure it. Maybe it is also related of my use of iommu and IGB for SRIOV...
14:28:03 gibi so that is anoher reason I did not progress with rally :)
14:42:23 tkajinam Can we merge https://review.opendev.org/c/openstack/osc-placement/+/935121 ? (post unmaintained transition change, kept for some time)
14:42:58 gibi tkajinam: done
14:43:11 tkajinam gibi, thx !
14:54:24 opendevreview Merged openstack/osc-placement master: reno: Update master for unmaintained/2023.1 https://review.opendev.org/c/openstack/osc-placement/+/935121
14:56:54 atmark hello, is nova host-evacuate-live concurrent or serial?
15:07:15 tkajinam atmark, API calls by cli would be done in serial but the operation is asynchronous so actual migration may be run concurrently.
15:07:48 tkajinam atmark, note that the max_concurrent_live_migrations option controls how a single nova-compute can run live migration concurrently so by default it processes multiple live migration requests one by one
15:07:52 tkajinam unless you tune it
15:18:05 opendevreview Jonas Schäfer proposed openstack/nova master: Preserve vTPM state between power off and power on https://review.opendev.org/c/openstack/nova/+/955657
15:37:39 melwitt bauzas, dansmith: for your awareness, the spec re-proposal for vtpm live migration is available for review at https://review.opendev.org/c/openstack/nova-specs/+/961564 and the updated patch series is at https://review.opendev.org/q/topic:%22bp/vtpm-live-migration%22+is:open
15:37:55 bauzas ack, will try to review it shortly
15:38:17 melwitt ty
15:38:52 dansmith melwitt: I know, I've had the notification marked in my client to follow up, I just keep ... not
15:38:57 dansmith sorry
15:39:57 melwitt dansmith: sure np
15:44:58 melwitt it when they are back
15:44:58 melwitt for tempest testing I have https://review.opendev.org/c/openstack/whitebox-tempest-plugin/+/955969 proposed and I will be adding a test to it for the resize-opt-in. I have also been trying to get vtpm to work with regular tempest but have been unsuccessful. I have got all the setup in place but the guest crashes in qemu and I can't find why. they work fine in whitebox obvs but regular tempest no. I will probably ask sean-k-mooney about
15:47:57 dansmith by "regular tempest" do you mean in an upstream job?
15:50:09 melwitt yes
15:50:30 melwitt the unsuccess is here at the top of the series https://review.opendev.org/c/openstack/nova/+/957477
15:51:17 melwitt it gets tpm enabled in the capabilities and everything and the guest xml properly gets the tpm device in it but the guest just crashes when it tries to start, example: https://zuul.opendev.org/t/openstack/build/35be637426de4f7db36e56d76c554964/log/compute1/logs/libvirt/libvirt/qemu/instance-00000003_log.txt
15:52:08 melwitt the regular tempest patch is https://review.opendev.org/c/openstack/tempest/+/957475 and what I linked above is the nova patch that depends-on it to see if it could work
15:52:13 dansmith um, duh
15:52:14 dansmith reason=crashed
15:52:15 dansmith there
15:52:18 melwitt lol right
15:52:18 dansmith is your reason
15:52:53 dansmith it does say starting tpm emulator so it seems like it supports it.. are the whitebox and regular tests running different distros/qemu versions, etc?
15:53:26 melwitt I looked in the qemu source code out of curiosity and did not find anything helpful there. it's failing some mutex assertion but I dunno what that could mean as far as cause. and the libvirtd log isn't helping either as to showing why it happens
15:54:14 melwitt whitebox has the same libvirt and qemu version and I _think_ the same distro. I'm stumped so far
15:55:53 melwitt I have been looking for differences between the two because I don't get how it works there and not here. the cpu model looks to be the same. whitebox sets some extra cpu flags but afaict that is specifically for some cpu flags related tests in whitebox and nothing to do with them really being needed by the environment
15:56:58 melwitt in the googling I've done so far regarding the mutex assertion failure I have only found that it has something to do with cpu stuff. like model or arch or something like that?
15:57:52 melwitt ERROR:system/cpus.c is where it's raised from i.e. https://github.com/qemu/qemu/blob/master/system/cpus.c
15:58:24 dansmith what's the diff in the XMLs?
15:59:14 melwitt it looked the same at an eyeballing but let me actually diff them
16:00:12 dansmith yeah let's actually diff
16:00:32 dansmith if they're the same I can't really imagine how they wouldn't work the same unless it's distro/qemu
16:05:19 melwitt yeah. looking at this I'm reminded that there is virt_type=kvm in whitebox whereas upstream is virt_type=qemu. I know that the former means nested virt but from what I googled that should not affect whether the tpm would work
16:07:44 clarkb you can run virt_type=kvm upstream too. But half of our resources will fail (no nested virt) and you get occasional failures elsewhere due to bugs in nested virt. Still maybe worth testing if it helps narrow down the problem?
16:07:47 dansmith yeah but I think it changes a bunch of how cpu stuff works, so.. maybe that is the reason it's crashing there and there's some odd overlap
16:07:48 melwitt diff https://paste.openstack.org/show/829214
16:08:01 clarkb (there are nested virt node labels in zuul to exclude the half of resources that can't do it)
16:09:03 melwitt thanks clarkb, I wondered about that. I have vague memory of nested virt being difficult or problematic upstream so it's good to know that it is indeed possible
16:09:19 melwitt I will try
16:10:17 clarkb ya I would say its still difficult in that we do still see occasional errors related to it that re basically impossible to debug
16:10:35 clarkb but for cases like this it may be helpful and we've got the ability ot at least try and do it without too much trouble
16:11:01 melwitt makes sense ++
16:15:54 opendevreview melanie witt proposed openstack/nova master: DNM vtpm tempest https://review.opendev.org/c/openstack/nova/+/957477
16:48:51 jssfr dansmith, I'm confused about one of your comments on https://review.opendev.org/c/openstack/nova/+/955657 , can you please check the unresolved one and help me find the issue?
17:03:03 melwitt dansmith, clarkb: it was indeed nested virt making the difference, works now with virt_type=kvm!
17:04:52 dansmith good.. I guess? :)
17:05:13 opendevreview Jonas Schäfer proposed openstack/nova master: Preserve vTPM state between power off and power on https://review.opendev.org/c/openstack/nova/+/955657
17:05:27 jssfr dansmith, ugh. sometimes I have tomatoes on the eyes (as we germans say). thanks, hopefully fixed.
17:06:23 dansmith jssfr: ack :)
#openstack-nova - 2025-09-25
11:13:03 LarsErikP Hi.. I'm experienceing the exact same scenario as this post from 2019, running Caracal: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/5QSBZDKQLA7HJF3IYMLYOF7PACWX5QQE/ am I doing something wrong here?
11:14:21 LarsErikP volume-backed instance - create snapshot (either in horizon or with openstack server image create) - volume snapshots are created, but the image in glance is created with disk_format=qcow2 even though everything along the way here is in raw
11:14:59 LarsErikP I've tried to set snapshot_image_format=raw both on compute nodes and nova-api servers, but it does not make a difference
11:16:41 LarsErikP and I understand from the api-ref for this, that this scenario should indeed both create the volume snap, and an "empty" glance image with bdm properties pointing to the volume snap. But this fails with a http 415 and "Image disk_format qcow2 does not match stream data raw"
11:34:57 LarsErikP got rid of the http 415 when setting image_format/require_image_format_match to false in glance!
11:55:46 opendevreview Lajos Katona proposed openstack/nova master: Use SDK for Neutron extensions https://review.opendev.org/c/openstack/nova/+/962270
13:51:21 opendevreview Lajos Katona proposed openstack/nova master: Use SDK for Neutron extensions https://review.opendev.org/c/openstack/nova/+/962270
13:51:21 opendevreview Lajos Katona proposed openstack/nova master: Use SDK for Neutron subnets https://review.opendev.org/c/openstack/nova/+/962190
16:26:12 opendevreview Lajos Katona proposed openstack/nova master: Use SDK for Neutron extensions https://review.opendev.org/c/openstack/nova/+/962270
19:39:38 opendevreview melanie witt proposed openstack/nova master: FUP for vTPM live migration https://review.opendev.org/c/openstack/nova/+/962309
19:39:38 opendevreview melanie witt proposed openstack/nova master: DNM vtpm tempest https://review.opendev.org/c/openstack/nova/+/957477
20:02:36 melwitt LarsErikP: if I'm understanding you correctly, what you're seeing is the "empty" glance image that gets created when you snapshot a volume backed instance. nova calls cinder to snapshot the actual volume but will also call glance to create an empty/dummy image whose purpose is only to hold image metadata https://github.com/openstack/nova/blob/b99a882366251f88d145e27312b94692e0b2266f/nova/compute/api.py#L3459-L3466

Earlier   Later