| 2015-08-03 15:45:42 |
Andreas Scheuring |
bug |
|
|
added bug |
| 2015-08-05 14:40:18 |
OpenStack Infra |
neutron: status |
New |
In Progress |
|
| 2015-08-05 14:40:18 |
OpenStack Infra |
neutron: assignee |
|
Andreas Scheuring (andreas-scheuring) |
|
| 2015-08-05 15:03:19 |
Andreas Scheuring |
description |
Adding macvtap ml2 driver and agent to neutron.
This feature allows instance network attachments via macvtap. A first spec has been hosted on github [1].
A place for this agent was discussed on [2]. The decision was to have it living somewhere in the neutron tree.
[1] https://github.com/scheuran/networking-macvtap/blob/spec/specs/liberty/macvtap-ml2.rst
[2] https://review.openstack.org/#/c/195907/ |
Adding macvtap ml2 driver and agent to neutron.
Problem Statement:
Today, there's no macvtap support in Neutron that can be commonly used on all types of interfaces. But at least there is some support within the sriov-nic driver/agent. But this support cannot be reused, as it
- requires PCI SRIOV Ethernet Adapters
- is tightly coupled with Nova PCI Manager
- does not support vnic_type 'normal'
- only allows macvtaps in passthrough mode
Proposal:
This new ml2 mech driver and agent support macvtap attachments for instances
- independent of the ethernet adapter used
- in a configurable macvtap mode (default 'bridge')
- with vnic_type 'normal'
Macvtap comes along with a couple of values, like performance, availability in each linux kernel and that it can deal with adapters that are not in promisc mode. More details you can find here [1].
The scope of this proposal is the compute node only - attaching instances via macvtap to the network. However support for ports used by the network node could be added in the future using macvlan devices.
High level architecture:
An ml2 mechansim driver and a l2 agent are required.
Macvtap will be used similar like a virtual switch. There is an interface_mapping, that describes the mapping between openstack physical network and the eth interface (or bond) that should be used. One Macvtap will be instantiated on such an eth interface for each guest port. As macvtaps are in bridge mode, macvtaps on the same source device can talk to each other directly, without going out to the cable. For the vlan case, a vlan device will be set up on the eth interface and macvtaps connected to it instead. This ensures tenant isolation. In the first shot there is no support for vxlan and gre.
A first spec has been hosted on github [1].
A place for this agent was discussed on [2]. The decision was to have it living somewhere in the neutron tree.
[1] https://github.com/scheuran/networking-macvtap/blob/spec/specs/liberty/macvtap-ml2.rst
[2] https://review.openstack.org/#/c/195907/ |
|
| 2015-08-05 15:04:54 |
Andreas Scheuring |
description |
Adding macvtap ml2 driver and agent to neutron.
Problem Statement:
Today, there's no macvtap support in Neutron that can be commonly used on all types of interfaces. But at least there is some support within the sriov-nic driver/agent. But this support cannot be reused, as it
- requires PCI SRIOV Ethernet Adapters
- is tightly coupled with Nova PCI Manager
- does not support vnic_type 'normal'
- only allows macvtaps in passthrough mode
Proposal:
This new ml2 mech driver and agent support macvtap attachments for instances
- independent of the ethernet adapter used
- in a configurable macvtap mode (default 'bridge')
- with vnic_type 'normal'
Macvtap comes along with a couple of values, like performance, availability in each linux kernel and that it can deal with adapters that are not in promisc mode. More details you can find here [1].
The scope of this proposal is the compute node only - attaching instances via macvtap to the network. However support for ports used by the network node could be added in the future using macvlan devices.
High level architecture:
An ml2 mechansim driver and a l2 agent are required.
Macvtap will be used similar like a virtual switch. There is an interface_mapping, that describes the mapping between openstack physical network and the eth interface (or bond) that should be used. One Macvtap will be instantiated on such an eth interface for each guest port. As macvtaps are in bridge mode, macvtaps on the same source device can talk to each other directly, without going out to the cable. For the vlan case, a vlan device will be set up on the eth interface and macvtaps connected to it instead. This ensures tenant isolation. In the first shot there is no support for vxlan and gre.
A first spec has been hosted on github [1].
A place for this agent was discussed on [2]. The decision was to have it living somewhere in the neutron tree.
[1] https://github.com/scheuran/networking-macvtap/blob/spec/specs/liberty/macvtap-ml2.rst
[2] https://review.openstack.org/#/c/195907/ |
Adding macvtap ml2 driver and agent to neutron.
Problem Statement:
Today, there's no macvtap support in Neutron that can be commonly used on all types of interfaces. But at least there is some support within the sriov-nic driver/agent. But this support cannot be reused, as it
- requires PCI SRIOV Ethernet Adapters
- is tightly coupled with Nova PCI Manager
- does not support vnic_type 'normal'
- only allows macvtaps in passthrough mode
Proposal:
This new ml2 mech driver and agent support macvtap attachments for instances
- independent of the ethernet adapter used
- in a configurable macvtap mode (default 'bridge')
- with vnic_type 'normal'
Macvtap comes along with a couple of values, like performance, availability in each linux kernel and that it can deal with adapters that are not in promisc mode. More details you can find here [1].
The scope of this proposal is the compute node only - attaching instances via macvtap to the network. However support for ports used by the network node could be added in the future using macvlan devices.
High level architecture:
An ml2 mechansim driver and a l2 agent are required.
Macvtap will be used similar like a virtual switch. There is an interface_mapping, that describes the mapping between openstack physical network and the eth interface (or bond) that should be used. One Macvtap will be instantiated on such an eth interface for each guest port. As macvtaps are in bridge mode, macvtaps on the same source device can talk to each other directly, without going out to the cable. For the vlan case, a vlan device will be set up on the eth interface and macvtaps connected to it instead. This ensures tenant isolation. In the first shot there is no support for vxlan and gre.
A first spec has been hosted on github [1].
A place for this agent was discussed on [2]. The decision was to have it living somewhere in the neutron tree.
Macvtap vif_type is already in nova [3]
[1] https://github.com/scheuran/networking-macvtap/blob/spec/specs/liberty/macvtap-ml2.rst
[2] https://review.openstack.org/#/c/195907/
[3] https://review.openstack.org/#/c/182283/ |
|
| 2015-10-07 09:55:23 |
Andreas Scheuring |
description |
Adding macvtap ml2 driver and agent to neutron.
Problem Statement:
Today, there's no macvtap support in Neutron that can be commonly used on all types of interfaces. But at least there is some support within the sriov-nic driver/agent. But this support cannot be reused, as it
- requires PCI SRIOV Ethernet Adapters
- is tightly coupled with Nova PCI Manager
- does not support vnic_type 'normal'
- only allows macvtaps in passthrough mode
Proposal:
This new ml2 mech driver and agent support macvtap attachments for instances
- independent of the ethernet adapter used
- in a configurable macvtap mode (default 'bridge')
- with vnic_type 'normal'
Macvtap comes along with a couple of values, like performance, availability in each linux kernel and that it can deal with adapters that are not in promisc mode. More details you can find here [1].
The scope of this proposal is the compute node only - attaching instances via macvtap to the network. However support for ports used by the network node could be added in the future using macvlan devices.
High level architecture:
An ml2 mechansim driver and a l2 agent are required.
Macvtap will be used similar like a virtual switch. There is an interface_mapping, that describes the mapping between openstack physical network and the eth interface (or bond) that should be used. One Macvtap will be instantiated on such an eth interface for each guest port. As macvtaps are in bridge mode, macvtaps on the same source device can talk to each other directly, without going out to the cable. For the vlan case, a vlan device will be set up on the eth interface and macvtaps connected to it instead. This ensures tenant isolation. In the first shot there is no support for vxlan and gre.
A first spec has been hosted on github [1].
A place for this agent was discussed on [2]. The decision was to have it living somewhere in the neutron tree.
Macvtap vif_type is already in nova [3]
[1] https://github.com/scheuran/networking-macvtap/blob/spec/specs/liberty/macvtap-ml2.rst
[2] https://review.openstack.org/#/c/195907/
[3] https://review.openstack.org/#/c/182283/ |
Adding macvtap ml2 driver and agent to neutron.
Problem Statement
=================
Today, there's no macvtap support in Neutron that can be commonly used on all types of interfaces. But at least there is some support within the sriov-nic driver/agent. But this support cannot be reused, as it
- requires PCI SRIOV Ethernet Adapters
- is tightly coupled with Nova PCI Manager
- does not support vnic_type 'normal'
- only allows macvtaps in passthrough mode
Proposal
========
This new ml2 mech driver and agent support macvtap attachments for instances
- independent of the ethernet adapter used
- in a configurable macvtap mode (default 'bridge')
- with vnic_type 'normal'
Benefits
--------
Macvtap comes along with a couple of values, like performance, availability in each linux kernel and that it can deal with adapters that are not in promisc mode. More details you can find here [1].
Scope
-----
The scope of this proposal is the compute node only - attaching instances via macvtap to the network. However support for ports used by the network node could be added in the future using macvlan devices.
High level architecture
-----------------------
An ml2 mechansim driver and a l2 agent are required.
Macvtap will be used similar like a virtual switch. There is an interface_mapping, that describes the mapping between openstack physical network and the eth interface (or bond) that should be used. One Macvtap will be instantiated on such an eth interface for each guest port. As macvtaps are in bridge mode, macvtaps on the same source device can talk to each other directly, without going out to the cable. For the vlan case, a vlan device will be set up on the eth interface and macvtaps connected to it instead. This ensures tenant isolation. In the first shot there is no support for vxlan and gre.
A first spec has been hosted on github [1].
Neutron Integration
-------------------
A place for this agent was discussed on [2]. Kyle decided to have this agent living somewhere in the neutron tree.
A new ml2 mechanism driver will be required.
For the agent, the current idea is to integrate it into the linuxbridge agent. Therefore the lb agent needs to be refactored, to separate the common agent code from the linuxbridge specific code via a clear interface. This interface then can be used for macvtap to plug in as well. 2 Approaches for this plugin mechanism are on the table
#1 Keep use the linuxbridgeagent binary (main method + entry point) and make it a pluginframework using stevedore to allow linuxbridge and macvtap to plug in.
#2 Each agent type keeps it's own binary (main method + entry point), but both instantiate the common agent and pass in the their driver as object.
A first prototype [4] showed, that for macvtap integration along this apporach only around 50 lines of macvtap production code are required. Around 500 lines are shared between both agents and 720 are specific to linuxbridge. A new prototype including the lb refactoring is currently under development [5]
Nova Integration
----------------
Macvtap vif_type is already in nova [3]
Links
-----
[1] https://github.com/scheuran/networking-macvtap/blob/spec/specs/liberty/macvtap-ml2.rst
[2] https://review.openstack.org/#/c/195907/
[3] https://review.openstack.org/#/c/182283/
[4] https://github.com/scheuran/networking-macvtap/commit/36a068cf3d3d6930ab9330efb099cd95a84ca785
[5] https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:lb_common_agent_experiment,n,z |
|
| 2015-10-14 17:27:29 |
Armando Migliaccio |
tags |
rfe |
rfe-approved |
|
| 2015-10-16 08:27:38 |
Andreas Scheuring |
description |
Adding macvtap ml2 driver and agent to neutron.
Problem Statement
=================
Today, there's no macvtap support in Neutron that can be commonly used on all types of interfaces. But at least there is some support within the sriov-nic driver/agent. But this support cannot be reused, as it
- requires PCI SRIOV Ethernet Adapters
- is tightly coupled with Nova PCI Manager
- does not support vnic_type 'normal'
- only allows macvtaps in passthrough mode
Proposal
========
This new ml2 mech driver and agent support macvtap attachments for instances
- independent of the ethernet adapter used
- in a configurable macvtap mode (default 'bridge')
- with vnic_type 'normal'
Benefits
--------
Macvtap comes along with a couple of values, like performance, availability in each linux kernel and that it can deal with adapters that are not in promisc mode. More details you can find here [1].
Scope
-----
The scope of this proposal is the compute node only - attaching instances via macvtap to the network. However support for ports used by the network node could be added in the future using macvlan devices.
High level architecture
-----------------------
An ml2 mechansim driver and a l2 agent are required.
Macvtap will be used similar like a virtual switch. There is an interface_mapping, that describes the mapping between openstack physical network and the eth interface (or bond) that should be used. One Macvtap will be instantiated on such an eth interface for each guest port. As macvtaps are in bridge mode, macvtaps on the same source device can talk to each other directly, without going out to the cable. For the vlan case, a vlan device will be set up on the eth interface and macvtaps connected to it instead. This ensures tenant isolation. In the first shot there is no support for vxlan and gre.
A first spec has been hosted on github [1].
Neutron Integration
-------------------
A place for this agent was discussed on [2]. Kyle decided to have this agent living somewhere in the neutron tree.
A new ml2 mechanism driver will be required.
For the agent, the current idea is to integrate it into the linuxbridge agent. Therefore the lb agent needs to be refactored, to separate the common agent code from the linuxbridge specific code via a clear interface. This interface then can be used for macvtap to plug in as well. 2 Approaches for this plugin mechanism are on the table
#1 Keep use the linuxbridgeagent binary (main method + entry point) and make it a pluginframework using stevedore to allow linuxbridge and macvtap to plug in.
#2 Each agent type keeps it's own binary (main method + entry point), but both instantiate the common agent and pass in the their driver as object.
A first prototype [4] showed, that for macvtap integration along this apporach only around 50 lines of macvtap production code are required. Around 500 lines are shared between both agents and 720 are specific to linuxbridge. A new prototype including the lb refactoring is currently under development [5]
Nova Integration
----------------
Macvtap vif_type is already in nova [3]
Links
-----
[1] https://github.com/scheuran/networking-macvtap/blob/spec/specs/liberty/macvtap-ml2.rst
[2] https://review.openstack.org/#/c/195907/
[3] https://review.openstack.org/#/c/182283/
[4] https://github.com/scheuran/networking-macvtap/commit/36a068cf3d3d6930ab9330efb099cd95a84ca785
[5] https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:lb_common_agent_experiment,n,z |
Adding macvtap ml2 driver and agent to neutron.
Problem Statement
=================
Today, there's no macvtap support in Neutron that can be commonly used on all types of interfaces. But at least there is some support within the sriov-nic driver/agent. But this support cannot be reused, as it
- requires PCI SRIOV Ethernet Adapters
- is tightly coupled with Nova PCI Manager
- does not support vnic_type 'normal'
- only allows macvtaps in passthrough mode
Proposal
========
This new ml2 mech driver and agent support macvtap attachments for instances
- independent of the ethernet adapter used
- in a configurable macvtap mode (default 'bridge')
- with vnic_type 'normal'
Benefits
--------
Macvtap comes along with a couple of values, like performance, availability in each linux kernel and that it can deal with adapters that are not in promisc mode. More details you can find here [1].
Scope
-----
The scope of this proposal is the compute node only - attaching instances via macvtap to the network. However support for ports used by the network node could be added in the future using macvlan devices.
Restrictions in the first stage (Mitaka)
----------------------------------------
- Only flat and vlan is supported. local and tunneling - can be easily lifted in a later stage
- No Security Groups, as macvtap is a direct connection (like sriov passthrough and sriov macvtap today)
- Live Migration requires same physnet:interface mapping on each host. physnet1:eth1 on host_a and pyhsnet1:eth2 on host_b will not work (macvtap directly sits on that interface, there's no abstraction layer like a bridge available). This will be documented in the first stage. An enforcement mechanism or device renaming is planned for a later stage.
High level architecture
-----------------------
An ml2 mechansim driver and a l2 agent are required.
Macvtap will be used similar like a virtual switch. There is an interface_mapping, that describes the mapping between openstack physical network and the eth interface (or bond) that should be used. One Macvtap will be instantiated on such an eth interface for each guest port. As macvtaps are in bridge mode, macvtaps on the same source device can talk to each other directly, without going out to the cable. For the vlan case, a vlan device will be set up on the eth interface and macvtaps connected to it instead. This ensures tenant isolation. In the first shot there is no support for vxlan and gre.
A first spec has been hosted on github [1].
Neutron Integration
-------------------
A place for this agent was discussed on [2]. Kyle decided to have this agent living somewhere in the neutron tree.
A new ml2 mechanism driver will be required (currently around 80 lines of code).
For the agent, the current idea is to integrate it into the linuxbridge agent. Therefore the lb agent needs to be refactored, to separate the common agent code from the linuxbridge specific code via a clear interface. This interface then can be used for macvtap to plug in as well. 2 Approaches for this plugin mechanism are on the table
#1 Keep use the linuxbridgeagent binary (main method + entry point) and make it a pluginframework using stevedore to allow linuxbridge and macvtap to plug in.
#2 Each agent type keeps it's own binary (main method + entry point), but both instantiate the common agent and pass in the their driver as object.
A first prototype [4] for the agent showed, that for macvtap integration along this approach only around 50-150 lines of macvtap production code are required (depending on how it will be integrated into lb). Around 500 lines are shared between both agents and 720 are specific to linuxbridge. A new prototype including the lb refactoring is currently under development [5]
Nova Integration
----------------
Macvtap vif_type is already in nova [3]
Links
-----
[1] https://github.com/scheuran/networking-macvtap/blob/spec/specs/liberty/macvtap-ml2.rst
[2] https://review.openstack.org/#/c/195907/
[3] https://review.openstack.org/#/c/182283/
[4] https://github.com/scheuran/networking-macvtap/commit/36a068cf3d3d6930ab9330efb099cd95a84ca785
[5] https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:lb_common_agent_experiment,n,z |
|
| 2015-11-11 21:22:25 |
Armando Migliaccio |
neutron: importance |
Undecided |
Wishlist |
|
| 2015-11-20 01:55:14 |
Armando Migliaccio |
neutron: milestone |
|
mitaka-1 |
|
| 2015-12-03 19:21:08 |
Armando Migliaccio |
neutron: milestone |
mitaka-1 |
mitaka-2 |
|
| 2015-12-08 14:56:52 |
Andreas Scheuring |
summary |
Adding macvtap ml2 driver and agent |
[RFE] Adding macvtap ml2 driver and agent |
|
| 2016-01-13 03:35:19 |
Armando Migliaccio |
neutron: status |
In Progress |
Incomplete |
|
| 2016-01-13 03:35:23 |
Armando Migliaccio |
neutron: assignee |
Andreas Scheuring (andreas-scheuring) |
|
|
| 2016-01-13 03:35:25 |
Armando Migliaccio |
neutron: milestone |
mitaka-2 |
|
|
| 2016-01-13 14:47:47 |
OpenStack Infra |
neutron: status |
Incomplete |
In Progress |
|
| 2016-01-13 14:47:47 |
OpenStack Infra |
neutron: assignee |
|
Andreas Scheuring (andreas-scheuring) |
|
| 2016-01-31 09:45:33 |
Alan Jenkins |
bug |
|
|
added subscriber Alan Jenkins |
| 2016-01-31 12:41:25 |
Alan Jenkins |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1035253 |
|
| 2016-02-08 15:47:17 |
Andreas Scheuring |
description |
Adding macvtap ml2 driver and agent to neutron.
Problem Statement
=================
Today, there's no macvtap support in Neutron that can be commonly used on all types of interfaces. But at least there is some support within the sriov-nic driver/agent. But this support cannot be reused, as it
- requires PCI SRIOV Ethernet Adapters
- is tightly coupled with Nova PCI Manager
- does not support vnic_type 'normal'
- only allows macvtaps in passthrough mode
Proposal
========
This new ml2 mech driver and agent support macvtap attachments for instances
- independent of the ethernet adapter used
- in a configurable macvtap mode (default 'bridge')
- with vnic_type 'normal'
Benefits
--------
Macvtap comes along with a couple of values, like performance, availability in each linux kernel and that it can deal with adapters that are not in promisc mode. More details you can find here [1].
Scope
-----
The scope of this proposal is the compute node only - attaching instances via macvtap to the network. However support for ports used by the network node could be added in the future using macvlan devices.
Restrictions in the first stage (Mitaka)
----------------------------------------
- Only flat and vlan is supported. local and tunneling - can be easily lifted in a later stage
- No Security Groups, as macvtap is a direct connection (like sriov passthrough and sriov macvtap today)
- Live Migration requires same physnet:interface mapping on each host. physnet1:eth1 on host_a and pyhsnet1:eth2 on host_b will not work (macvtap directly sits on that interface, there's no abstraction layer like a bridge available). This will be documented in the first stage. An enforcement mechanism or device renaming is planned for a later stage.
High level architecture
-----------------------
An ml2 mechansim driver and a l2 agent are required.
Macvtap will be used similar like a virtual switch. There is an interface_mapping, that describes the mapping between openstack physical network and the eth interface (or bond) that should be used. One Macvtap will be instantiated on such an eth interface for each guest port. As macvtaps are in bridge mode, macvtaps on the same source device can talk to each other directly, without going out to the cable. For the vlan case, a vlan device will be set up on the eth interface and macvtaps connected to it instead. This ensures tenant isolation. In the first shot there is no support for vxlan and gre.
A first spec has been hosted on github [1].
Neutron Integration
-------------------
A place for this agent was discussed on [2]. Kyle decided to have this agent living somewhere in the neutron tree.
A new ml2 mechanism driver will be required (currently around 80 lines of code).
For the agent, the current idea is to integrate it into the linuxbridge agent. Therefore the lb agent needs to be refactored, to separate the common agent code from the linuxbridge specific code via a clear interface. This interface then can be used for macvtap to plug in as well. 2 Approaches for this plugin mechanism are on the table
#1 Keep use the linuxbridgeagent binary (main method + entry point) and make it a pluginframework using stevedore to allow linuxbridge and macvtap to plug in.
#2 Each agent type keeps it's own binary (main method + entry point), but both instantiate the common agent and pass in the their driver as object.
A first prototype [4] for the agent showed, that for macvtap integration along this approach only around 50-150 lines of macvtap production code are required (depending on how it will be integrated into lb). Around 500 lines are shared between both agents and 720 are specific to linuxbridge. A new prototype including the lb refactoring is currently under development [5]
Nova Integration
----------------
Macvtap vif_type is already in nova [3]
Links
-----
[1] https://github.com/scheuran/networking-macvtap/blob/spec/specs/liberty/macvtap-ml2.rst
[2] https://review.openstack.org/#/c/195907/
[3] https://review.openstack.org/#/c/182283/
[4] https://github.com/scheuran/networking-macvtap/commit/36a068cf3d3d6930ab9330efb099cd95a84ca785
[5] https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:lb_common_agent_experiment,n,z |
Adding macvtap ml2 driver and agent to neutron.
Problem Statement
=================
Today, there's no macvtap support in Neutron that can be commonly used on all types of interfaces. But at least there is some support within the sriov-nic driver/agent. But this support cannot be reused, as it
- requires PCI SRIOV Ethernet Adapters
- is tightly coupled with Nova PCI Manager
- does not support vnic_type 'normal'
- only allows macvtaps in passthrough mode
Proposal
========
This new ml2 mech driver and agent support macvtap attachments for instances
- independent of the ethernet adapter used
- in a configurable macvtap mode (default 'bridge')
- with vnic_type 'normal'
Benefits
--------
Macvtap comes along with a couple of values, like
- performance (compared to ovs) in the sense of cpu consumption, throughput and latency,
- availability in each linux kernel
- can deal with adapters that are not in promisc mode.
Scope
-----
The scope of this proposal is the compute node only - attaching instances via macvtap to the network. However support for ports used by the network node could be added in the future using macvlan devices.
Restrictions in the first stage (Mitaka)
----------------------------------------
- Only flat and vlan is supported. local and tunneling - can be easily lifted in a later stage
- No Security Groups, as macvtap is a direct connection (like sriov passthrough and sriov macvtap today)
- Live Migration requires same physnet:interface mapping on each host. physnet1:eth1 on host_a and pyhsnet1:eth2 on host_b will not work (macvtap directly sits on that interface, there's no abstraction layer like a bridge available). This will be documented in the first stage. An enforcement mechanism or device renaming is planned for a later stage.
- Anti Spoofing rules on IP Level are not supported. However there is some prevention on mac level. An attacker in the guest can not receive packets destinated to a mac address =! its own. But on the other hand, outgoing traffic is not being filtered along the src mac.
High level architecture
-----------------------
An ml2 mechansim driver and a l2 agent are required.
Macvtap will be used similar like a virtual switch. There is an interface_mapping, that describes the mapping between openstack physical network and the eth interface (or bond) that should be used. One Macvtap will be instantiated on such an eth interface for each guest port. As macvtaps are in bridge mode, macvtaps on the same source device can talk to each other directly, without going out to the cable. For the vlan case, a vlan device will be set up on the eth interface and macvtaps connected to it instead. This ensures tenant isolation. In the first shot there is no support for vxlan and gre.
Neutron Integration
-------------------
A place for this agent was discussed on [2]. Kyle decided to have this agent living somewhere in the neutron tree.
A new ml2 mechanism driver will be required (currently around 80 lines of code).
For the agent, the current idea is to integrate it into the linuxbridge agent. Therefore the lb agent needs to be refactored, to separate the common agent code from the linuxbridge specific code via a clear interface. This interface then can be used for macvtap to plug in as well. 2 Approaches for this plugin mechanism are on the table
#1 Keep use the linuxbridgeagent binary (main method + entry point) and make it a pluginframework using stevedore to allow linuxbridge and macvtap to plug in.
#2 Each agent type keeps it's own binary (main method + entry point), but both instantiate the common agent and pass in the their driver as object.
A first prototype [4] for the agent showed, that for macvtap integration along this approach only around 50-150 lines of macvtap production code are required (depending on how it will be integrated into lb). Around 500 lines are shared between both agents and 720 are specific to linuxbridge. A new prototype including the lb refactoring is currently under development [5]
Nova Integration
----------------
Macvtap vif_type is already in nova [3]
Links
-----
[2] https://review.openstack.org/#/c/195907/
[3] https://review.openstack.org/#/c/182283/
[4] https://github.com/scheuran/networking-macvtap/commit/36a068cf3d3d6930ab9330efb099cd95a84ca785
[5] https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:lb_common_agent_experiment,n,z |
|
| 2016-02-19 02:18:31 |
Armando Migliaccio |
neutron: milestone |
|
mitaka-3 |
|
| 2016-03-01 14:49:56 |
OpenStack Infra |
neutron: status |
In Progress |
Fix Released |
|
