| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-03 | |||
| 13:14:52 | sean-k-mooney | moshele: i belive that the intel driver generates unique macs automaticaly for the pfs | |
| 13:14:57 | sean-k-mooney | * vfs | |
| 13:16:17 | sean-k-mooney | personally the fact that libvirt is seting 00:00:00:00:00:00 on deleteing the vm sound like a libvirt bug to me | |
| 13:16:40 | sean-k-mooney | or a nova bug if we are doing that in the libvirt vir driver | |
| 13:18:30 | moshele | sean-k-mooney: basically it set the restore the previously used mac so if you auto generate it. it will restore the auto generate one. in mellanox case the vf is start with 00:00:00:00:00:00 so we allowed to restore to 00:00:00:00:00:00 | |
| 13:18:37 | sean-k-mooney | amarao: well would a flavor extra-spec for disableing the console on an instace work? | |
| 13:19:53 | amarao | sean-k-mooney are there such property for extra-spec? | |
| 13:19:55 | sean-k-mooney | moshele: right in anycase when the vf is detached from a instance its linkstate should be down so no trafic will travers it so does it matter if spoof checking is disabled | |
| 13:20:37 | sean-k-mooney | amarao: ill check you can chages several aspecs of the vm like this via extra-sepcs and or image metadata. | |
| 13:22:46 | amarao | If I could disable console via flavor specs, it would be cool. | |
| 13:23:03 | sean-k-mooney | amarao: you can change the type of gpu in the guest and ram https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt-image.json#L45-L62 | |
| 13:23:14 | moshele | sean-k-mooney: right, but I think the default links state is auto, (at least for Mellanox) | |
| 13:23:15 | sean-k-mooney | you can also set the serial port count https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt.json#L18-L23 | |
| 13:23:34 | sean-k-mooney | amarao: we could add a display count extra spec | |
| 13:24:04 | sean-k-mooney | amarao: or extend hw_video_model to allow none to signel no display | |
| 13:24:52 | amarao | Nodisplay wouldn't work with many OSes. | |
| 13:25:06 | amarao | But disable_vnc (or disable_access) will be cool. | |
| 13:25:40 | sean-k-mooney | amarao: hum the perhaps we should leave the display and allow disabling of the vnc/spice console that is attached to it instead? | |
| 13:27:11 | sean-k-mooney | amarao: atleast in terms of libvirt/kvm the vnc/spice console is a sperate device form the gpu/display so we could disable it speraate ly or leave it here but limit its acess to local scope so you cannot connect to it via the novnc_proxy | |
| 13:28:05 | amarao | For the best user expirience it's better to return error on get-vnc-console, saying 'VNC console is disabled for this instance'. | |
| 13:28:45 | amarao | ... And admins will love that they still can connect to VNC through local IP on libvirt host. | |
| 13:29:20 | amarao | Should I report wishbug into launchpad? | |
| 13:29:25 | sean-k-mooney | amarao: we could proably do that based on the extraspec via an api check. amarao this would be a good topic for a blueprint care to write one | |
| 13:29:45 | sean-k-mooney | amarao: yes. a bug or sepcless blueprint. | |
| 13:30:19 | amarao | I'll start from a bug. I never created a blueprint, so I'll write down a bug and then will try with blueprint. | |
| 13:31:53 | sean-k-mooney | amarao: ok sound good. feel free to add me to the bug if you like. am will you be attending the PTG next week. if not i can highlight this as an RFE | |
| 13:34:31 | amarao | Should I put it into 'hw' namespace? | |
| 13:35:07 | sean-k-mooney | am you dont have to detail the impmentation in the bug but yes i would think so | |
| 13:35:15 | amarao | I thought about something like 'hw:disable_consoles: vnc,spice,serial' | |
| 13:36:41 | amarao | Oh, it's simpler than I thought. https://blueprints.launchpad.net/nova/+spec/flavor-based-access-to-console | |
| 13:37:45 | sean-k-mooney | amarao: perhapes invert that to hw:consoles=<one of vnc|spice|serial|None> | |
| 13:38:13 | amarao | .. and if this field is absent, everything is permitted. ack. | |
| 13:38:14 | sean-k-mooney | amarao: yes blueprints are baseicelay jsut what is the problem you would like to fix | |
| 13:38:36 | sean-k-mooney | amarao: yep if the field is not there just do waht we do today | |
| 13:39:25 | sean-k-mooney | amarao: i dont think we actully allow more then one console currently hence the one of but that is something we could figure out as we start looking at the implementaion | |
| 13:39:47 | sean-k-mooney | e.g. i dont think you can have an instance with both spice and vnc enabled | |
| 13:41:17 | amarao | ack, updated. | |
| 13:41:29 | amarao | It's more about serial/vnc thing, actually. | |
| 13:42:31 | sean-k-mooney | ya serial likely can be mix with vnc as they attach do different virualised hardware | |
| 13:42:44 | sean-k-mooney | rdp/vnc/spice all share teh virutal gpu | |
| 13:43:39 | amarao | Anyway, we are still on mitaka (sad, but true), so I'll continue to search some kind of dirty hack for that. Thank you for help. | |
| 13:43:46 | sean-k-mooney | the other think about inverting it is we could model what consoles are available on each host as traits in the placement api and use this extraspec if present to land on a host that is able to support that console | |
| 13:44:30 | stephenfin | Afternoon, gibi. Think this is something you'd be happy reviewing? https://review.openstack.org/#/c/595592/ | |
| 13:45:13 | sean-k-mooney | amarao: no worries, you may be able to use policies but that is not a area im familar with unfrotuetly. | |
| 13:46:23 | amarao | ... policy.json is like a path in a swamp. Everyone knew it exist, but rarely someone passes through. :) | |
| 13:49:30 | gibi | stephenfin: sure, looking | |
| 13:58:50 | gibi | stephenfin: https://review.openstack.org/#/c/595592/ looks good overall. I'm wondering how we can tests this other than in the unit test that is in the patch | |
| 13:59:53 | stephenfin | gibi: I'm not sure how we could do it in the gate due to the hardware dependencies. I do have an SR-IOV machine locally that I could validate the fix with, if you'd like | |
| 14:00:40 | stephenfin | gibi: Downstream we will likely look at automating this as part of the whitebox-tempest-plugin Tempest plugin, but how we actually run those tests is still very much in the air | |
| 14:02:52 | bauzas | given we're on a US holiday today, I guess we won't have any scheduler meeting? | |
| 14:02:53 | gibi | stephenfin: if it does not take more than 2 hours of your time to locally test it then could you please run that test? It would give sizeable confidence boost to me towards this patch | |
| 14:03:17 | stephenfin | gibi: No problem, should only take me 20 minutes | |
| 14:03:25 | gibi | bauzas: cdent asked it in openstack-placement where I said it is OK to me to skip | |
| 14:03:33 | bauzas | k | |
| 14:03:33 | gibi | stephenfin: thanks a lot | |
| 14:07:57 | moshele | stephenfin: Mellanox CI was update to test this | |
| 14:16:16 | sean-k-mooney | stephenfin: gibi moshele if you are refering to https://review.openstack.org/#/c/595592/3 i think that is a pretty safe change | |
| 14:18:41 | gibi | sean-k-mooney: yes, we are talking about that. If stephenfin's timeline is correct he will have test results in 5 minutes anyhow :) | |
| 14:20:14 | sean-k-mooney | stephenfin: if not i can prep an sriov env if needed but ill have to do an os reinstall on the node so it will be more like 2-3 hours before ill be able to check this directly. | |
| 14:20:36 | sean-k-mooney | * or rather if you have issues | |
| 14:23:09 | stephenfin | sean-k-mooney: Think I'm all good. Will known in 60 seconds :P | |
| 14:23:46 | sean-k-mooney | stephenfin: i take it you worked out your sriov issues then? | |
| 14:24:32 | stephenfin | gibi: Without the fix http://paste.openstack.org/show/729332/ | |
| 14:24:52 | stephenfin | sean-k-mooney: Sure did. It was a really stupid typo | |
| 14:25:08 | stephenfin | sean-k-mooney: and those warnings didn't seem to affect anything. | |
| 14:25:09 | sean-k-mooney | ha they are always the best typos | |
| 14:25:17 | sean-k-mooney | stephenfin: ya they dont | |
| 14:25:42 | sean-k-mooney | libvirt is just unhappy that a netdev does not exist for the device | |
| 14:25:43 | stephenfin | sean-k-mooney: I'm not sure why they're warnings actually and not debug (or removed entirely). Must ask moshele that | |
| 14:25:52 | stephenfin | sean-k-mooney: No, we emit those logs | |
| 14:26:46 | sean-k-mooney | stephenfin: in that case we must be trying to read stuff via ip or sysfs that we should not assume is available | |
| 14:27:24 | stephenfin | sean-k-mooney: Yeah, this is what I see http://paste.openstack.org/show/729333/ | |
| 14:27:26 | sean-k-mooney | stephenfin: in gerearal we assumt that pci device of type pf or vf are network devices which is not always correct | |
| 14:28:16 | stephenfin | gibi: and with the fix http://paste.openstack.org/show/729334/ | |
| 14:28:19 | sean-k-mooney | ya this is likely coming form the code that tryis to get the netdev feature flags | |
| 14:29:17 | sean-k-mooney | we shold only do that if a netdev exists for the vf. i dont see why this should be a warning instead of debug as you said | |
| 14:29:50 | sean-k-mooney | stephenfin: do you have the queue lenght set in your conf? | |
| 14:30:44 | sean-k-mooney | stephenfin: if not can you add it an restart the n-cpu agent and try one more time with both vnic-type=macvtap and vnic-type=direct | |
| 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 | |