Wednesday, 2025-09-24

*** bauzas6 is now known as bauzas00:43
Ugglazigo release of F should be next week.07:37
gibizigo: nice!07:38
Ugglazigo yep thx for the testing, that's cool !07:39
lajoskatonaUggla: Hi, just would like to highlight that the first green patch for migrating from neutronclient to SDK is ready: https://review.opendev.org/c/openstack/nova/+/928022 , I plan to migrate the remaining calls (like subnets, ports, sec_groups....) also (I hope I will have time for it)07:43
Ugglalajoskatona cool good news07:45
gokhan__hello folks, is there a way to rescue openstack windows instance ? 09:30
gokhan__What values should I set for the hw_rescue_device and hw_rescue_bus image properties for Windows instances in OpenStack?09:32
jssfrgokhan__, that probably depends on what image you want to use for rescuing?10:22
jssfrif 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:22
elodillesUggla: 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:27
gokhan__jssfr, I am using windows server 2019  qcow2 image and I want to give this image also as rescue disk image. 10:45
jssfrgokhan__, 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:51
gokhan__hw_rescue_device10:52
gokhan__cdrom10:52
gokhan__hw_rescue_bus10:52
gokhan__sata didn't work  jssfr 10:52
jssfrgokhan__, yeah, I just noticed sata is not an option. try scsi and if that doesn't work, try usb.10:54
gokhan__jssfr, ok I will try with different options. may be if  hw_rescue_device=cdrom we need to use .iso image. 11:00
*** sambork_ is now known as sambork11:25
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 11:46
*** mtreinish_ is now known as mtreinish11:49
opendevreviewTaketani 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/+/96077712:01
opendevreviewTaketani 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/+/96077712:05
opendevreviewTaketani 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/+/96077712:12
ykarel_uptime12:18
*** ykarel_ is now known as ykarel12:35
gibifyi eventlet sync in ~90 minutes meet.google.com/bcy-uqoz-hje13:03
gibi13:03
gibicontent_copy13:03
gibiCopy conference info13:03
gibibaad copy past buffer, baaad :)13:03
gibibut the link is correct 13:03
opendevreviewBalazs Gibizer proposed openstack/nova master: [hacking] N374 do not use time.sleep(0) to yield  https://review.opendev.org/c/openstack/nova/+/95099213:38
gibistephenfin: thanks. Good catch of my sloppy conflict resolution on ^^. I fixed it up13:39
bauzasgibi: can't join the eventlet meeting unfortunately :(14:12
gibibauzas: no worries14:12
gibithe doc has some links and text about where we are if you later want to take a look14:12
opendevreviewLajos Katona proposed openstack/nova master: Use SDK for Neutron networks  https://review.opendev.org/c/openstack/nova/+/92802214:17
opendevreviewLajos Katona proposed openstack/nova master: Use SDK for Neutron subnets  https://review.opendev.org/c/openstack/nova/+/96219014:17
dansmithI've not made much progress on my thing in the last week due to other distractions14:19
*** masayukig_ is now known as masayukig14:20
gibisame here. but I want to get back to the rally stuff this week finally 14:22
*** zseguin_ is now known as zseguin14:26
*** auniyal3 is now known as auniyal14:26
*** mnasiadka_ is now known as mnasiadka14:26
*** mtreinish_ is now known as mtreinish14:26
*** johnsom_ is now known as johnsom14:26
*** TheJulia_ is now known as TheJulia14:26
gibibtw, 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:26
gibiso that is anoher reason I did not progress with rally :)14:28
*** hemna4 is now known as hemna14:39
*** masayukig_ is now known as masayukig14:39
*** mtreinish_ is now known as mtreinish14:39
*** johnsom_ is now known as johnsom14:39
*** mnaser_ is now known as mnaser14:39
*** tmazur_ is now known as tmazur14:39
*** haleyb_ is now known as haleyb14:39
tkajinamCan we merge https://review.opendev.org/c/openstack/osc-placement/+/935121 ? (post unmaintained transition change, kept for some time)14:42
*** haleyb_ is now known as haleyb14:42
gibitkajinam: done14:42
tkajinamgibi, thx !14:43
opendevreviewMerged openstack/osc-placement master: reno: Update master for unmaintained/2023.1  https://review.opendev.org/c/openstack/osc-placement/+/93512114:54
atmarkhello, is nova host-evacuate-live concurrent or serial? 14:56
*** haleyb_ is now known as haleyb15:05
tkajinamatmark, API calls by cli would be done in serial but the operation is asynchronous so actual migration may be run concurrently.15:07
tkajinamatmark, 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 one15:07
tkajinamunless you tune it15:07
opendevreviewJonas Schäfer proposed openstack/nova master: Preserve vTPM state between power off and power on  https://review.opendev.org/c/openstack/nova/+/95565715:18
*** cardoe_ is now known as cardoe15:32
melwittbauzas, 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:open15:37
bauzasack, will try to review it shortly15:37
melwittty15:38
dansmithmelwitt: I know, I've had the notification marked in my client to follow up, I just keep ... not15:38
dansmithsorry15:38
melwittdansmith: sure np15:39
melwittfor 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 about15:44
melwitt it when they are back15:44
dansmithby "regular tempest" do you mean in an upstream  job?15:47
melwittyes15:50
melwittthe unsuccess is here at the top of the series https://review.opendev.org/c/openstack/nova/+/95747715:50
melwittit 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.txt15:51
melwittthe 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 work15:52
dansmithum, duh15:52
dansmith reason=crashed15:52
dansmiththere15:52
dansmithis your reason15:52
melwittlol right15:52
dansmithit 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:52
melwittI 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 happens15:53
melwittwhitebox has the same libvirt and qemu version and I _think_ the same distro. I'm stumped so far15:54
melwittI 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 environment15:55
melwittin 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:56
melwittERROR:system/cpus.c is where it's raised from i.e. https://github.com/qemu/qemu/blob/master/system/cpus.c15:57
dansmithwhat's the diff in the XMLs?15:58
melwittit looked the same at an eyeballing but let me actually diff them15:59
dansmithyeah let's actually diff16:00
dansmithif they're the same I can't really imagine how they wouldn't work the same unless it's distro/qemu16:00
melwittyeah. 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 work16:05
clarkbyou 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
dansmithyeah 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 overlap16:07
melwittdiff https://paste.openstack.org/show/82921416:07
clarkb(there are nested virt node labels in zuul to exclude the half of resources that can't do it)16:08
melwittthanks 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
melwittI will try16:09
clarkbya I would say its still difficult in that we do still see occasional errors related to it that re basically impossible to debug16:10
clarkbbut for cases like this it may be helpful and we've got the ability ot at least try and do it without too much trouble16:10
melwittmakes sense ++16:11
opendevreviewmelanie witt proposed openstack/nova master: DNM vtpm tempest  https://review.opendev.org/c/openstack/nova/+/95747716:15
jssfrdansmith, 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?16:48
melwittdansmith, clarkb: it was indeed nested virt making the difference, works now with virt_type=kvm!17:03
dansmithgood.. I guess? :)17:04
opendevreviewJonas Schäfer proposed openstack/nova master: Preserve vTPM state between power off and power on  https://review.opendev.org/c/openstack/nova/+/95565717:05
jssfrdansmith,  ugh. sometimes I have tomatoes on the eyes (as we germans say). thanks, hopefully fixed.17:05
dansmithjssfr: ack :)17:06
*** iurygregory_ is now known as iurygregory23:41

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!