Open Stack

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/20150204/3c75d551/attachment.html>