Wednesday, 2024-03-27

manuvakery1Hey .. 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.html05:46
*** mklejn_ is now known as mklejn06:43
sahidbauzas, sean-k-mooney o/07:30
sahidall good for  https://review.opendev.org/c/openstack/nova/+/896512 ?07:30
sahidany action that I have to take?07:30
bauzassahid : the action is for me, I need to modify the blueprint to be accepted and add the series in our etherpad :-)07:34
sahidbauzas: perfect ! thanks07:50
sahidguys, 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 paths08:01
sahidbut we can notice that some have only 4 or 3 or 7 paths08:01
opendevreviewribaudr 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/+/90370608:33
opendevreviewribaudr proposed openstack/nova master: Test live migration between hosts with differnet cpu_shared_sets  https://review.opendev.org/c/openstack/nova/+/91374408:33
bauzassahid: I'm not a specialist but I think it depends on the machine type09:59
bauzasnevermind, looked too quickly10:00
*** mklejn__ is now known as mklejn13:15
melwittdansmith: 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.html16:08
dansmithmelwitt: oh yeah, that was the *only* way I could make sense of it :D16:09
dansmithI was remarking about choosing which line to complain about in the source :)16:09
melwittoh, gotcha16:09
melwittsean-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/+/91004116:15
bauzasmelwitt: I can shortly quick-approve back the persistent mdevs bp 16:25
bauzasso I could look at your patch16:26
melwittbauzas: ok, that would be great, thanks16:26
bauzaswe agreed last cycle it was a specless bp, so I feel brave enough to approve it again without asking other folks16:26
melwittspecless bp ftw16:27
bauzasdone16:27
melwittthanks16:31
bauzasmelwitt: 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
bauzasmelwitt: 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 works16:32
melwittbauzas: 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 fine16:35
bauzas\o/16:35
bauzasmelwitt: -1d with my comment https://review.opendev.org/c/openstack/nova/+/91004116:40
melwittbauzas: ok thanks16:41
bauzasmelwitt: 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
bauzastl;dr: this works for time-sliced vGPUs but if you enable MIG types, you're screwed16:44
dansmithwow16:44
bauzasbecause all of this is fuckingly on the userspacez16:45
bauzasthanks nvidia16:45
melwittbauzas: oh, I see. I don't know what MIG types means but I'll look it up :)16:48
bauzasmelwitt: that's another mechanism to slice your GPU, this time using capable hardware resources16:48
bauzaseg. a A100 can be sliced either by concurrency (time-sliced types) or physically (using MIG graphical instances)16:49
melwittah ok16:49
bauzasMIGs are only available with another "new" licence, which isn't particularly cheap 'AI Enterprise'16:54
bauzasthat's why you didn't see it :)16:54
bauzasseen*16:54
melwittAI $$$16:56
bauzaswell, 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
opendevreviewStephen Finucane proposed openstack/nova-specs master: Add openapi spec  https://review.opendev.org/c/openstack/nova-specs/+/90944817:21
opendevreviewStephen Finucane proposed openstack/nova-specs master: Add openapi spec  https://review.opendev.org/c/openstack/nova-specs/+/90944817:22
opendevreviewMerged openstack/nova master: Fix nova-manage image_property show unexpected keyword  https://review.opendev.org/c/openstack/nova/+/88055718:32
melwittdansmith: 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 meantime19:15
dansmithoh yeah, it's a thing, but the link is broken19:16
dansmithit's also completely unmerged and still needs some discussion I think.. not sure how much review it has really gotten19:17
dansmithit too has been pending for many cycles19:17
dansmithI reached out to those folks this morning and I think we'll get a good cross-project session on it at PTG19:17
dansmithit's quite different from what you have proposed here too, AFAICT from a skim19:17
melwittyeah, that paragraph has been in there forever so I'm not sure what happened to the link19:18
melwittok that sounds good re: PTG19:18
dansmithpotentially a presumptive link that never became a 200 because it was never merged, or perhaps a de-approval19:18

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