Open Stack

Hi Irena,

Issue 1 - I agree. You are correct.

Issue 2
The behavior you outlined
1. When port is created with vnic_type=direct, the vif_type is 'unbound'.
The pci_vendor_info will be available during port update when 'nova boot'
command is invoked and PCI device is allocated.
This happens when the controller and compute are on the same host. Not when
they are on the different host. On a multiserver setup vif_type is set to
binging_failed during port create.

Second is i am not doing nova boot. Instead I am doing nova
interface-attach. In this case the pci_vendor_info is not updated by anyone
but me. and pci_slot is also not populated.

Do you still think this is correct ?



On Wed, Feb 4, 2015 at 8:08 PM, Irena Berezovsky <irenab.dev at gmail.com>
wrote:

> Hi Akilesh,
> please see inline
>
> On Wed, Feb 4, 2015 at 11:32 AM, Akilesh K <akilesh1597 at gmail.com> wrote:
>
>> Hi,
>> Issue 1:
>> I do not understand what you mean. I did specify the physical_network.
>> What I am trying to say is some physical networks exists only on the
>> compute node and not on the network node. We are unable to create a network
>> on those physnets. The work around was to fake their existance on the
>> network node too. Which I believe is the wrong way to do.
>>
>> Every physical network  should be defined at the Controller node,
> including range of segmentation ids (i.e. vlan ids) available for
> allocation.
> When virtual network is created, you should verify that it has associated
>  network type and segmentation id (assuming you are using provider network
> extension).
>
>>
>> Issue2:
>> I looked directly into the code after looking at the logs.
>>
>> 1. What neutron (sriov mech driver ) is doing is loading the default list
>> of 'supported_pci_vendor_devs' , then it picks up the
>> profile->pci_vendor_info from the port defenition we sent in the port
>> create request and checks if it is supported. If not it says
>> 'binding_failed'
>>
> When port is created with vnic_type=direct, the vif_type is 'unbound'. The
> pci_vendor_info will be available during port update when 'nova boot'
> command is invoked and PCI device is allocated.
>
>
>>
>> I am fine with this
>>
>> 2. Then when I attach the created port to a host nova's vif driver
>> (hv_veb) is looking for profile->pci_slot in the context of the port that
>> was supplied and fails to attach to the instance if it is not present.
>>
>> nova vif driver receives profile->pci_slot from neutron, but it was
> actually filed earlier by nova during port-update.
>
>> this is what I think should be done by neutron itself. neutron's sriov
>> mech driver should have updated the port with the pci_slot details when the
>> port got created. and this does happen on a single machine install. We need
>> to find why it does not happen on a multi node install, possibly because
>> the mech driver is not running on the host with sriov devices and fix it.
>>
>> I suggest to follow
> https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking instructions,
> this should work for you.
>
> I hope you guys can understand what I mean.
>
>>
>> Thank you,
>> Ageeleshwar K
>>
>>
>> On Wed, Feb 4, 2015 at 2:49 PM, Itzik Brown <itzikb at redhat.com> wrote:
>>
>>>  Hi,
>>>
>>> Issue 1;
>>> You must specify the physical networks.
>>> Please look at:
>>> https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking
>>>
>>> Issue 2:
>>> AFAIK the agent is supported by only one vendor.
>>> Can you please look for errors in Neutron's log?
>>>
>>> Thanks,
>>> Itzik
>>>
>>> On 02/04/2015 09:12 AM, Akilesh K wrote:
>>>
>>>     Hi,
>>>  I found two issues with the way neutron behaves on a multi server
>>> install. I got it to work but I do not this this is the right way to do it.
>>> It might be a bug we might want to fix and for which I could volunteer.
>>>
>>>  Setup - Multiserver juno on ubuntu.
>>>
>>>  Machine 1 - Controller
>>>  All api servers , l3, dhcp and ovs agent
>>>
>>>  Machine 2 - Compute
>>>  nova compute, neutron-ovs-agent, neutron sriov agent.
>>>
>>>
>>>  Issue 1:
>>>
>>>  Controller node has physnets 'External', 'Internal' configured in ml2
>>>
>>>  Compute node has physnets 'Internal', 'Physnet1', 'Physnet2' configured
>>> in ml2
>>>
>>>  When I do neutron net-create --provider:physicalnetwork Physnet1, It
>>> complains that 'Physnet1' is not available.
>>>
>>>  Offcourse its not available on the controller but is available on the
>>> compute node and there is no way to tell neutron to host that network on
>>> compute node alone
>>>
>>>  Work around
>>> I had to include 'Physnet1' in the controller node also to get it to
>>> work, except that there is not bridge mapings for this physnet.
>>>
>>>
>>>  Issue 2:
>>>
>>>  This is related to sriov agent. This agent is configured only on the
>>> compute node as that node alone has supported devices.
>>>
>>>  When I do a port create --binding:vnic_type direct --binding:host_id
>>> <compute node> The port is created but with binding:vif_type:
>>> *'binding-failed'*.   and naturally I could not attach it to any
>>> instance.
>>>
>>>  I looked at the code and figured out that neutron api is expecting
>>> binding:profile also in the format
>>>  {"pci_slot": "0000:03:10.1", "pci_vendor_info": "8086:10ed"}
>>>
>>>  Is this how it should be. Because on a single machine install I did
>>> not have to do this. However on a multiserver I had to even give the pci
>>> address is the exact format to get it to work.
>>>
>>>  I have a serious feeling that this could be lot simpler if neutron
>>> could take care of finding the details in a smart way rather than relying
>>> on the administrator to find which device is available and configure it.
>>>
>>>
>>>  Note:
>>>  1. If I can get some expert advice I can fix both these.
>>>  2. I am not sure if this question should rather be sent to
>>> openstack-dev group. Let me know.
>>>
>>>
>>>  Thank you,
>>>  Ageeleshwar K
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> Post to     : openstack at lists.openstack.org
>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>
>>>
>>>
>>
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20150205/1881da42/attachment.html>