[openstack-dev] [Neutron] MultiTenant support for VLAN-Aware-VM

Armando M. armamig at gmail.com
Thu Jul 14 02:51:57 UTC 2016


On 13 July 2016 at 16:51, Kevin Benton <kevin at benton.pub> wrote:

> Sub ports are just regular ports from a logical model perspective, right?
> If so, there should be no problem attaching the port to a shared network or
> RBAC granted network.
>

True, but I don't believe it until I test it :)

On Jul 13, 2016 7:15 PM, "Armando M." <armamig at gmail.com> wrote:
>
>>
>>
>> On 13 July 2016 at 15:32, Cathy Zhang <Cathy.H.Zhang at huawei.com> wrote:
>>
>>> Hi Everyone,
>>>
>>> We have been discussing on multi-tenant VNF for service chain on the OVN
>>> mailing alias.
>>> We are thinking about leveraging the vlan-aware-VM for supporting this.
>>>
>>> AFAIK, with current nova, we cannot create a multi-tenant  VNF.
>>> Currently, nova checks whether the neutron port belongs to the same
>>> tenant as the VM itself.
>>> You attach a network interface (neutron port) to a VM using nova
>>> interface-attach, if the port and the VM are in different tenants, an error
>>> is given.
>>>
>>> With the introduction of the trunk-port/sub-port feature of Neutron, the
>>> sub-ports of a VM are allowed to associate with different networks. But it
>>> seems these networks need to all belong to the same tenant if we read the
>>> vlan-aware-vm spec correctly (
>>> http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html
>>> ).
>>>
>>> Is our understanding correct? Does it work properly if these networks
>>> belong to different tenants?
>>>
>>
>> At the moment this area is still WIP, but we're focusing on the single
>> tenant use case. RBAC may help us down the road to address what you need,
>> but it's premature to speculate on how the implementation looks like.
>>
>> Cheers,
>> Armando
>>
>>
>>>
>>> Thanks,
>>> Cathy
>>>
>>> -----Original Message-----
>>> From: dev [mailto:dev-bounces at openvswitch.org] On Behalf Of Farhad
>>> Sunavala
>>> Sent: Tuesday, July 12, 2016 7:59 PM
>>> To: dev at openvswitch.org
>>> Subject: Re: [ovs-dev] SFC-Summary: MultiTenant
>>>
>>> >I was thinking this could be handled with child / sub-ports.  We do
>>> >this today for containers in VMs.  We can have a single VIF for a VM
>>> >that is connected to multiple networks that are owned by separate
>>> >tenants.  Some sort of encapsulation (VLAN ID, MPLS header, whatever)
>>> >would be used to differentiate the traffic for each networking in/out
>>> >of that VIF.  I had started adding the ability to use MPLS for this in
>>> >my prototype for this reason, as that was what networking-sfc had
>>> defined.
>>> I have a quick question on the above. (multi-tenancy).Yes, I know the
>>> containers can be in different networks of the same tenant.How does it work
>>> when the containers are in different tenants ?
>>> Below is the latest spec for vlan-aware-vms
>>> https://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html
>>>
>>> The trick is to create neutron ports (for the subports) and then link
>>> them to the trunk port using neutron trunk-subport-add TRUNK \
>>>  PORT[,SEGMENTATION-TYPE,SEGMENTATION-ID] \   [PORT,...]
>>>
>>> In the above command all the neutron ports (trunk  ports and subports)
>>> must be in the same tenant.As far as I know, a tenant will not see neutron
>>> ports from another tenant.    Or will this command allow neutron ports from
>>> different tenants to be attached ?
>>> E.g.  VM "X" consists of containers C1 in Tenant 1 with portID = C10000
>>> (network dn1)container C2 in Tenant 2 with portID = C20000 (network dn2)The
>>> trunk port of VM "X" is in tenant 100 with portID = T10000 (network dt) The
>>> above command will be neutron trunk-subport-add T10000 \   A  vlan 10000 \
>>>  B vlan 20000 Is my understanding correct? thanks,Farhad.
>>> _______________________________________________
>>> dev mailing list
>>> dev at openvswitch.org
>>> http://openvswitch.org/mailman/listinfo/dev
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160713/1ddcb68a/attachment.html>


More information about the OpenStack-dev mailing list