| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-06-03 | |||
| 08:46:13 | sean-k-mooney | kashyap: yep just sayign they used to be the same | |
| 08:46:33 | kashyap | sean-k-mooney: The thing is on Fedora the binary is this: /usr/bin/qemu-system-x86_64 | |
| 08:46:34 | sean-k-mooney | kashyap: but when centos change to that it broke live migration between centos and ubunutu | |
| 08:47:05 | bauzas | songwenping: no, we leave them | |
| 08:47:07 | kashyap | (And IIRC, Ubuntu uses a different binary name and a different path) | |
| 08:47:13 | sean-k-mooney | /usr/bin/qemu-system-x86_64 | |
| 08:47:30 | sean-k-mooney | its qemu im not seeing qemu-kvm on 22.04 | |
| 08:47:30 | kashyap | Ah, same as Fedora then. Thanks | |
| 08:47:36 | sean-k-mooney | let me double check | |
| 08:47:51 | bauzas | songwenping: you can even precreate the mdevs before starting the nova-compute service, then the n-cpu service will use them instead of creating them | |
| 08:47:51 | sean-k-mooney | sean@cloud:~$ qemu-kvm | |
| 08:47:53 | sean-k-mooney | qemu-kvm: command not found | |
| 08:47:58 | sean-k-mooney | so its not on my path at least | |
| 08:48:04 | kashyap | sean-k-mooney: I don't want that; it's an alias to the QEMU binary on Fedora | |
| 08:48:18 | kashyap | sean-k-mooney: So, "/usr/bin/qemu-system-x86_64" exists on Ubuntu, right? | |
| 08:48:29 | sean-k-mooney | yes | |
| 08:48:48 | songwenping | bauzas:then there will has race problem, https://bugs.launchpad.net/nova/+bug/1836204 | |
| 08:48:58 | sean-k-mooney | sean@cloud:~$ file /usr/bin/qemu-system-x86_64 | |
| 08:49:00 | sean-k-mooney | /usr/bin/qemu-system-x86_64: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=f28deae95b4b0f19a8c8be87c45d1be213cf8b6b, for GNU/Linux 3.2.0, stripped | |
| 08:49:12 | kashyap | sean-k-mooney: Thanks! | |
| 08:49:16 | sean-k-mooney | kashyap: it exiss and is not a symlink its the binary | |
| 08:49:22 | kashyap | Okay, I see that I could've checked it here: https://packages.ubuntu.com/bionic/i386/qemu-system-x86/filelist | |
| 08:49:32 | kashyap | sean-k-mooney: Yeah, I know; if that's the name, then it's the real binary | |
| 08:49:43 | kashyap | 'qemu-kvm' is the symlink on Fedora/CentOS | |
| 08:50:00 | sean-k-mooney | kashyap: not quite | |
| 08:50:12 | sean-k-mooney | well it might be a symlink but it was a script on ubuntu | |
| 08:50:22 | kashyap | /usr/bin/qemu-kvm: symbolic link to qemu-system-x86_64 | |
| 08:50:22 | kashyap | $> file /usr/bin/qemu-kvm | |
| 08:50:28 | songwenping | bauzas:if we create new mdev when alloc, there will be no this problem. | |
| 08:50:33 | kashyap | sean-k-mooney: Yeah, it used to be a wrapper script | |
| 08:50:40 | sean-k-mooney | yep | |
| 08:50:45 | kashyap | (Which just pointed to the real binary. So they removed that) | |
| 08:50:53 | sean-k-mooney | it was a wrapper on ubuntu in 20.04 | |
| 08:51:00 | sean-k-mooney | in 22.04 they droped it | |
| 08:51:44 | bauzas | songwenping: I don't see how it could help | |
| 08:51:59 | sean-k-mooney | kashyap: looks like ti snow a virtual package/metapackage https://packages.ubuntu.com/jammy/qemu-kvm | |
| 08:52:31 | sean-k-mooney | likely for upgrade reasons | |
| 08:53:05 | kashyap | Yeah, same on Fedora | |
| 08:53:19 | sean-k-mooney | kashyap: if you want to poke around i can give you access to the server just let me know | |
| 08:53:19 | kashyap | (contains no files) | |
| 08:53:19 | kashyap | $> rpm -ql qemu-kvm | |
| 08:53:55 | elodilles | gibi: for the sake of easier reviewing i'd say squash is better to avoid. some rare cases though we can have squash: e.g. in case otherwise we could not unblock the gate. or in case we can avoid some introduced bug that the follow-up fixes. | |
| 08:54:04 | kashyap | sean-k-mooney: Thank you, it's not needed at this time. I just wanted to be sure of the path - so that we could supply it to `coredumpctl` :) | |
| 08:54:27 | sean-k-mooney | hum never had to use that | |
| 08:54:39 | sean-k-mooney | does that parse them or cause them :) | |
| 08:55:05 | songwenping | bauzas: in this function https://github.com/openstack/nova/blob/8260979b71b29ce2666d37b3adc7c256482aa16d/nova/virt/libvirt/driver.py#L6416, we use _create_new_mediated_device for every vm instead of select a mdev from mdevs_available. | |
| 08:57:40 | sean-k-mooney | songwenping: we inteded to not reuse mdevs for new vms | |
| 08:57:54 | sean-k-mooney | the other path for intedd for agent restart if i rememebr correctly | |
| 08:58:11 | sean-k-mooney | songwenping: so we shoudl be delete the mdevs if we delete the vm | |
| 08:58:27 | songwenping | sean-k-mooney: cool | |
| 08:58:51 | sean-k-mooney | songwenping: this become more important for cards that can support more then one mdev at a time with generic mdev support | |
| 08:59:15 | sean-k-mooney | i dont think nvidia do with any of there gpus btu other vendors might in the future | |
| 09:00:22 | songwenping | sean-k-mooney: ack, agree to delete the mdevs if we delete the vm | |
| 09:00:22 | sean-k-mooney | bauzas: precrating does not work and i dont think it was part of the sepc so if that was added its a bug | |
| 09:00:31 | bauzas | sean-k-mooney: if we make nova creating the mdevs directly, this could create other problems | |
| 09:00:42 | bauzas | for reboot, for example | |
| 09:00:57 | sean-k-mooney | bauzas: we dont support using mdevctl and the current case faild our qe | |
| 09:01:03 | bauzas | remember the difference between SR-IOV devices and mdevs | |
| 09:01:09 | sean-k-mooney | bauzas: nova is not able to create the mdevs because it did not clean up | |
| 09:01:16 | sean-k-mooney | bauzas: yes i know | |
| 09:01:31 | sean-k-mooney | we only support nova creating the mdevs today | |
| 09:01:40 | sean-k-mooney | including in the mig case | |
| 09:02:00 | bauzas | in the mig case, nothing changes from nova pov | |
| 09:02:11 | bauzas | this is just that we precreate the pci devices | |
| 09:02:17 | sean-k-mooney | yep | |
| 09:02:17 | bauzas | not the mdevs | |
| 09:02:32 | songwenping | when manage vgpus by cyborg, we precreate the mdevs when discover | |
| 09:02:33 | sean-k-mooney | pre creat the pci device and list the vfs instead of the pf | |
| 09:02:45 | bauzas | songwenping: sean-k-mooney: anyway, I'm not against fixing this old bug | |
| 09:03:03 | bauzas | songwenping: if you have time for fixing it, would be appreciated | |
| 09:03:11 | bauzas | none of this requires a spec | |
| 09:06:54 | songwenping | bauzas:i'll try. | |
| 09:29:28 | kashyap | dansmith: To answer to your question in the scrollback: yeah, I'm guessing it's different - based on the trigger here (backup) vs. the older one (disk-detach) | |
| 09:32:08 | frickler | gibi: hacking-integration-nova has been busted for ages | |
| 09:32:58 | frickler | likely before we moved to zull v3 even https://zuul.opendev.org/t/openstack/builds?job_name=hacking-integration-nova&project=openstack%2Fhacking&result=SUCCESS&skip=0 | |
| 09:33:05 | frickler | *zuul | |
| 09:34:08 | opendevreview | Balazs Gibizer proposed openstack/nova master: Fix PciAddressSpec descendants to call super.__init__ https://review.opendev.org/c/openstack/nova/+/844565 | |
| 09:34:37 | gibi | frickler: I think it shows that nova is not compatible with latest hacking | |
| 09:34:43 | gibi | frickler: am I mistaken? | |
| 09:35:47 | frickler | gibi: this is true. afaict nova also hasn't been compatible with at least 3 years of previous releases of hacking, so not much change | |
| 09:36:09 | gibi | ahh OK | |
| 09:36:43 | gibi | frickler: so you think we can land the flake version bump after I drop py35 testing or we need to fix nova first? | |
| 09:37:57 | sean-k-mooney | frickler: gibi if we use black hacking become less importnat. still nice for extra non style related checks like dont improt prev sep stuff with from | |
| 09:38:13 | sean-k-mooney | or any other rules we want to enforece but the systle related ones are less requried | |
| 09:38:21 | gibi | sean-k-mooney: the current failures are thinks that are not covered by black / flake | |
| 09:38:43 | frickler | gibi: nova caps to 3.1.0, there are 3.2.0, 4.0.0 and 4.1.0 already. so adapting nova to recent hacking should not block updating hacking IMO | |
| 09:38:49 | sean-k-mooney | ack i was just hoping it would reduce the number of things we have to port | |
| 09:38:59 | gibi | frickler: thanks | |
| 09:39:08 | gibi | I will update the hacking patch to drop py35 then | |
| 09:39:16 | sean-k-mooney | frickler: yep it should not | |
| 09:40:45 | frickler | also I must reduce my "3 years" claim to 2 years, 3.1.0 was released in May 2020. no idea how far back our history of zuul builds actually goes | |
| 09:54:49 | sean-k-mooney | frickler: i think there was a change in hackign that broke some fo our checks which is why we pinned | |
| 09:55:10 | sean-k-mooney | frickler: but then stephenfin who was lookign at fixing it moved to not work on nova as part of there day job | |
| 09:55:17 | sean-k-mooney | and we had others move too | |
| 09:55:28 | sean-k-mooney | so we just never got aroudn to adressint the issues | |
| 09:55:46 | sean-k-mooney | we might still have patches form stephenfin for some of the issues | |
| 09:57:31 | sean-k-mooney | not that i can see on this topic | |
| 09:58:31 | sean-k-mooney | frickler: we did recently move to 3.1 | |
| 09:58:34 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/836639/1/.pre-commit-config.yaml | |
| 10:03:05 | sean-k-mooney | actully i guess the bump was done in victoria https://github.com/openstack/nova/commit/61b99a1295c5208deef806b69ba74a7d031ad851 | |