| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-03 | |||
| 14:31:27 | stephenfin | sean-k-mooney: nope http://paste.openstack.org/show/729336/ | |
| 14:32:50 | sean-k-mooney | ? that is the domain xml for a direct passhtoug device | |
| 14:33:18 | sean-k-mooney | do you have the queue lenght set in /etc/nova/nova-cpu.conf | |
| 14:33:49 | sean-k-mooney | if so then that is correct for direct but we should see it populated in the driver section for macvtap | |
| 14:34:36 | stephenfin | sean-k-mooney: Oh, good point. 02:00.0 is the PF. That's a 'direct' attach | |
| 14:35:00 | stephenfin | Used 'openstack port create --network 84b18250-c0d3-4594-92d1-19328fb37da5 --vnic-type direct sriov-port' | |
| 14:35:10 | sean-k-mooney | well direct could also be a vf | |
| 14:35:40 | stephenfin | Based on the address, that's the PF. I probably have my whitelist set up wrong | |
| 14:36:00 | sean-k-mooney | stephenfin: yes with that commandline we do not expect the domain xml to contain the queulenght | |
| 14:36:19 | sean-k-mooney | the fact its a pf or vf is irelevent in this case | |
| 14:36:33 | stephenfin | Cool. So that's working as expected | |
| 14:36:53 | sean-k-mooney | yes but you have not confirms if you set the queue lenght in your config | |
| 14:36:54 | stephenfin | The macvtap route is interesting though. I'm seeing this | |
| 14:37:05 | stephenfin | sean-k-mooney: Oh, sorry. Yes, I have set it | |
| 14:37:25 | sean-k-mooney | ok cool. so for macvtap what is the result? | |
| 14:37:43 | stephenfin | and as a result, got this error (without the fix) http://paste.openstack.org/show/729332/ | |
| 14:38:11 | stephenfin | sean-k-mooney: For macvtap, I'm seeing http://paste.openstack.org/show/729339/ | |
| 14:38:27 | stephenfin | so it turns out those warnings are a big deal :) | |
| 14:38:40 | stephenfin | and I didn't think they were simply because it was the PF being attached instead of the VF | |
| 14:39:05 | sean-k-mooney | stephenfin: is the pf still bound? | |
| 14:39:11 | sean-k-mooney | e.g to a vm | |
| 14:39:17 | stephenfin | No, I killed that VM | |
| 14:39:31 | stephenfin | There are no VMs running | |
| 14:39:34 | sean-k-mooney | you should be able to use the pf for the macvtap if you delete the neturon port that is currectly using it | |
| 14:40:12 | sean-k-mooney | actullly if you deleted the vm that might be enough | |
| 14:40:53 | sean-k-mooney | stephenfin: it makes sense however if the netdev does not exist then you cant create a macvtap from it | |
| 14:42:04 | stephenfin | sean-k-mooney: Nope, same error after deleting the two ports :/ | |
| 14:42:17 | stephenfin | Yeah, it does. I've no idea how to create said netdevs though | |
| 14:42:42 | sean-k-mooney | stephenfin: can you try deaclloating the vf by echoing 0 into sriov_num_vf then restart the n-cpu agent so that only the pf is available | |
| 14:43:22 | sean-k-mooney | stephenfin: the pf shows up with ifconfig/ip link right? | |
| 14:43:41 | stephenfin | sean-k-mooney: Yup, along with its VMs. It's in up state | |
| 14:44:05 | sean-k-mooney | stephenfin: VMs? | |
| 14:44:13 | stephenfin | VFs, sorry | |
| 14:44:28 | stephenfin | Heh, "-su: echo: write error: Function not implemented" | |
| 14:45:12 | sean-k-mooney | stephenfin: you could just change your whitelisnt to onely have 02:00:00 address | |
| 14:45:27 | openstackgerrit | sahid proposed openstack/nova stable/rocky: hardware: fix memory check usage for small/large pages https://review.openstack.org/599413 | |
| 14:47:01 | sean-k-mooney | stephenfin: gibi anyway it sounds like the patch is working as expect in terms of fixing the direct case. the macvtap case likely will work if the nic was correctly configured | |
| 14:51:27 | openstackgerrit | sahid proposed openstack/nova stable/rocky: libvirt: Always escape IPv6 addresses when used in migration URI https://review.openstack.org/599419 | |
| 14:55:12 | gibi | stephenfin, sean-k-mooney: thanks for the extra check. I'm a lot more confident to +A that patch | |
| 15:06:44 | bauzas | stephenfin: I was looking at https://review.openstack.org/#/c/588570/2 | |
| 15:07:10 | bauzas | stephenfin: maybe because it's changing a lot of tech debt, that's why people wonder if that's a feature backport | |
| 15:07:17 | bauzas | while not, of course | |
| 15:07:35 | bauzas | after all, the change is hairy, you know | |
| 15:07:53 | bauzas | and https://review.openstack.org/#/c/588570/2/nova/objects/numa.py is a bit concerning | |
| 15:08:01 | stephenfin | bauzas: Yeah, I get that. Unfortunately it's pretty much unavoidable though :( | |
| 15:09:02 | stephenfin | bauzas: Is it? None of those functions are stored in a DB so there's no issues around versioning | |
| 15:10:28 | bauzas | stephenfin: yup, we're not changing the RPC API | |
| 15:10:33 | sean-k-mooney | stephenfin: well we could greatly simply that code by rewriting it in a declarive/fuctional style with filters and transforms instead of the imperitive stily that is currently used for numa affinity | |
| 15:11:00 | bauzas | stephenfin: I meant, when someone provides a backport change asking to modify an o.vo object, we need to look more | |
| 15:11:17 | sean-k-mooney | so the complexity is not entirely due to the problem statement however that is not backportable in anyway | |
| 15:11:27 | bauzas | and why it's taking me a long time to look at it | |
| 15:11:31 | stephenfin | bauzas: Yup, that's fair :) I figured as much | |
| 15:12:06 | bauzas | sean-k-mooney: well, it would be an only-stable change, then ? | |
| 15:12:24 | bauzas | if so, that's difficult | |
| 15:12:39 | stephenfin | Hmm, I wonder how I can resolve the issue, in that case. We could stick on more sellotape but I haven't even thought how I'd do that | |
| 15:12:39 | kashyap | Hey folks, can anyone do a small test for me: Boot a Nova instance with Q35 machine type, and post the complete guest XML somewhere, please | |
| 15:12:54 | kashyap | You can set Q35 in two ways: either vai the Nova config: `hw_machine_type=x86_64=q35`, or on the Glance image image: `openstack image set --property hw_machine_type=x86_64=q35 Fedora28Template` | |
| 15:12:57 | stephenfin | kashyap: What properties would I need to set to do that? | |
| 15:12:58 | stephenfin | Ah :) | |
| 15:13:04 | sean-k-mooney | bauzas: rewriting the numa code to be fucntional instead of imperitve. i was talking generally not for this specific patch | |
| 15:13:17 | stephenfin | sean-k-mooney: oh, gotcha | |
| 15:13:51 | sean-k-mooney | stephenfin: for this patch the only object change i see is a new property | |
| 15:13:55 | stephenfin | Yeah, all that code is crufty af. I might look to take that "track CPUs in placement" spec from jaypipes this cycle, assuming he's oversubscribed as usual | |
| 15:14:10 | stephenfin | ...though I don't really want to wade into the great placement war of 2018 | |
| 15:14:51 | kashyap | stephenfin: Thank you! | |
| 15:15:14 | sean-k-mooney | stephenfin: well we could clean up that code without ever touching placement but thats a different topic. e.g. keep existing functionality jsut do it differently | |
| 15:16:04 | bauzas | sean-k-mooney: oh well, sure we could do it | |
| 15:16:18 | bauzas | or use Haskell :p | |
| 15:16:30 | kashyap | stephenfin: I need to head to my Dutch class (starts afresh) in a few; when you get to it, post it here, I'll take a look. Gracias! | |
| 15:16:48 | bauzas | (FWIW, I *love* Haskell) | |
| 15:16:53 | sean-k-mooney | stephenfin: bauzas anyway back to https://review.openstack.org/#/c/588570/2 the only object change there is a syntasied property that will now be included in teh serialisation of the object so i think this is backportable as there is no rpc change right? | |
| 15:17:00 | kashyap | (s/starts afresh/new level starts today) | |
| 15:17:08 | bauzas | sean-k-mooney: I feel so | |
| 15:17:34 | sean-k-mooney | bauzas: that explains a lot .... | |
| 15:18:14 | bauzas | very simple | |
| 15:18:36 | stephenfin | bauzas: I studied Haskell in NZ and adored it (helped me grasp recursion at long last). Alas, it's not something I've had the chance to work with since | |
| 15:18:41 | stephenfin | Prolog, on the other hand. Ick | |
| 15:19:11 | sean-k-mooney | stephenfin: python has really good fuctional programing supprot built in by they way. | |
| 15:19:15 | bauzas | sean-k-mooney: since we're adding a new property, that's not chaning what we pass over RPC | |
| 15:19:25 | bauzas | sean-k-mooney: my only concern is on the left side | |
| 15:19:29 | bauzas | ie.what we remove | |
| 15:20:07 | stephenfin | kashyap: Here's the output of 'virsh dumpxml' http://paste.openstack.org/show/729345/ | |
| 15:20:29 | bauzas | anyway, time for wrapping off | |
| 15:20:58 | kashyap | stephenfin: Nice, /me clicks | |
| 15:21:06 | stephenfin | kashyap: and here are the commands I ran to get there http://paste.openstack.org/show/729348/ | |
| 15:21:18 | bauzas | today was school's back for my daughters, so I want to take time to discuss with them | |
| 15:21:27 | bauzas | so, calling it a day \o | |
| 15:21:40 | sean-k-mooney | bauzas: as you should. o/ | |
| 15:21:43 | stephenfin | kashyap: That's using commit 90cdf807503f94bfbd3ae9a62a9bfe466a18bcad (so about two month old cold) | |
| 15:21:47 | stephenfin | bauzas: Enjoy o/ | |
| 15:21:48 | kashyap | stephenfin: Nice. Can I ask one more, since you have the env? Also related to PCIe | |
| 15:21:56 | stephenfin | kashyap: shoot | |
| 15:22:45 | kashyap | stephenfin: Set the 'num_pcie_ports=2' in nova.conf, restart the Compute service, and again boot an instance afresh, and post the guest XML | |
| 15:22:56 | kashyap | Thanks a for the quick response :-) | |
| 15:23:24 | stephenfin | kashyap: num_pcie_ports ? That's not a nova.conf option, is it? | |
| 15:23:25 | sean-k-mooney | kashyap: wait why is that a nova conf setting and not a flavor extra spec | |
| 15:23:46 | stephenfin | Oh, what do you know, so it is | |
| 15:23:57 | kashyap | sean-k-mooney: Hehe, I haven't checked if there's a flavor extra spec for it or not. | |
| 15:24:00 | sean-k-mooney | stephenfin: really that sucks. | |
| 15:24:14 | sean-k-mooney | stephenfin: that is going to make live migration even more of a pain | |