manuvakery1 | Hey .. I am getting ConflictNovaUsingAttachment while dettaching volume from VM. I do have the service_user enabled in nova.conf as per https://docs.openstack.org/cinder/latest/configuration/block-storage/service-token.html | 05:46 |
---|---|---|
*** mklejn_ is now known as mklejn | 06:43 | |
sahid | bauzas, sean-k-mooney o/ | 07:30 |
sahid | all good for https://review.opendev.org/c/openstack/nova/+/896512 ? | 07:30 |
sahid | any action that I have to take? | 07:30 |
bauzas | sahid : the action is for me, I need to modify the blueprint to be accepted and add the series in our etherpad :-) | 07:34 |
sahid | bauzas: perfect ! thanks | 07:50 |
sahid | guys, quick question, we have noticed that some VMs that are using volumes do not have the right number of iscsi path, normally they should all have 8 paths | 08:01 |
sahid | but we can notice that some have only 4 or 3 or 7 paths | 08:01 |
opendevreview | ribaudr proposed openstack/nova master: Fix: Live migrating to a host with cpu_shared_set configured will now update the VM's configuration accordingly. https://review.opendev.org/c/openstack/nova/+/903706 | 08:33 |
opendevreview | ribaudr proposed openstack/nova master: Test live migration between hosts with differnet cpu_shared_sets https://review.opendev.org/c/openstack/nova/+/913744 | 08:33 |
bauzas | sahid: I'm not a specialist but I think it depends on the machine type | 09:59 |
bauzas | nevermind, looked too quickly | 10:00 |
*** mklejn__ is now known as mklejn | 13:15 | |
melwitt | dansmith: thanks for looking at the spec. I haven't gone through it yet in depth but wanted to mention it might be easier to read(at least the tables) to look at the docs preview https://793e4b83b6aee9c90173-a0541882d2023eca9a1cc07087449de0.ssl.cf2.rackcdn.com/907654/7/check/openstack-tox-docs/55aebd2/docs/specs/2024.2/approved/ephemeral-storage-encryption.html | 16:08 |
dansmith | melwitt: oh yeah, that was the *only* way I could make sense of it :D | 16:09 |
dansmith | I was remarking about choosing which line to complain about in the source :) | 16:09 |
melwitt | oh, gotcha | 16:09 |
melwitt | sean-k-mooney: just a heads up that I did go through and test the systemd way of enabling gpu virtual functions and it worked for me https://review.opendev.org/c/openstack/nova/+/910041 | 16:15 |
bauzas | melwitt: I can shortly quick-approve back the persistent mdevs bp | 16:25 |
bauzas | so I could look at your patch | 16:26 |
melwitt | bauzas: ok, that would be great, thanks | 16:26 |
bauzas | we agreed last cycle it was a specless bp, so I feel brave enough to approve it again without asking other folks | 16:26 |
melwitt | specless bp ftw | 16:27 |
bauzas | done | 16:27 |
melwitt | thanks | 16:31 |
bauzas | melwitt: can you confirm that besides persisting the sriov-manage VFs, all the mdevs were persisted after reboot without modifying some systemd files or udev rules ? | 16:31 |
bauzas | melwitt: I have concern with documenting some specific nvidia command in our upstream docs, so I'll just leave a -1 about that tomorrow, but I just wanted to make sure it works | 16:32 |
melwitt | bauzas: yes it worked for me. to be clear, I could boot a vm with vgpu, reboot the host, sriov-manage -e (via systemd service file), then 'server start' the vm and it retained the mdev in its xml and started up fine | 16:35 |
bauzas | \o/ | 16:35 |
bauzas | melwitt: -1d with my comment https://review.opendev.org/c/openstack/nova/+/910041 | 16:40 |
melwitt | bauzas: ok thanks | 16:41 |
bauzas | melwitt: if you read the nvidia doc link I gave in the review, you'll see this paragraph : | 16:44 |
bauzas | " Note: If you are using a GPU that supports SR-IOV, the mdev device file persists after a host reboot only if you perform Step 1 before rebooting any VM that is configured with a vGPU on the | 16:44 |
bauzas | GPU. You cannot use the mdevctl command to make the mdev device file for a MIG-backed vGPU persistent. The mdev device file for a MIG-backed vGPU is not retained after the host is rebooted because MIG | 16:44 |
bauzas | instances are no longer available. " | 16:44 |
bauzas | tl;dr: this works for time-sliced vGPUs but if you enable MIG types, you're screwed | 16:44 |
dansmith | wow | 16:44 |
bauzas | because all of this is fuckingly on the userspacez | 16:45 |
bauzas | thanks nvidia | 16:45 |
melwitt | bauzas: oh, I see. I don't know what MIG types means but I'll look it up :) | 16:48 |
bauzas | melwitt: that's another mechanism to slice your GPU, this time using capable hardware resources | 16:48 |
bauzas | eg. a A100 can be sliced either by concurrency (time-sliced types) or physically (using MIG graphical instances) | 16:49 |
melwitt | ah ok | 16:49 |
bauzas | MIGs are only available with another "new" licence, which isn't particularly cheap 'AI Enterprise' | 16:54 |
bauzas | that's why you didn't see it :) | 16:54 |
bauzas | seen* | 16:54 |
melwitt | AI $$$ | 16:56 |
bauzas | well, you indirectly support nvidia to become a new GAFAM | 16:56 |
bauzas | (which indirectly helps me, since I have a position on the nasdaq index :) ) | 16:58 |
opendevreview | Stephen Finucane proposed openstack/nova-specs master: Add openapi spec https://review.opendev.org/c/openstack/nova-specs/+/909448 | 17:21 |
opendevreview | Stephen Finucane proposed openstack/nova-specs master: Add openapi spec https://review.opendev.org/c/openstack/nova-specs/+/909448 | 17:22 |
opendevreview | Merged openstack/nova master: Fix nova-manage image_property show unexpected keyword https://review.opendev.org/c/openstack/nova/+/880557 | 18:32 |
melwitt | dansmith: I replied to your comments on the spec except the one about glance + secrets. I had thought I read something in docs or specs related to that at some point but I can't find it. I wanted to look around a little more before replying on that so I posted everything else in the meantime | 19:15 |
dansmith | oh yeah, it's a thing, but the link is broken | 19:16 |
dansmith | it's also completely unmerged and still needs some discussion I think.. not sure how much review it has really gotten | 19:17 |
dansmith | it too has been pending for many cycles | 19:17 |
dansmith | I reached out to those folks this morning and I think we'll get a good cross-project session on it at PTG | 19:17 |
dansmith | it's quite different from what you have proposed here too, AFAICT from a skim | 19:17 |
melwitt | yeah, that paragraph has been in there forever so I'm not sure what happened to the link | 19:18 |
melwitt | ok that sounds good re: PTG | 19:18 |
dansmith | potentially a presumptive link that never became a 200 because it was never merged, or perhaps a de-approval | 19:18 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!