yahoo-eng-team team mailing list archive

[OpenStack Infra <1480979@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/275306
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=2e7eb09271912e9db1948b15ab3f8e184d4c324a
Submitter: Jenkins
Branch:    master

commit 2e7eb09271912e9db1948b15ab3f8e184d4c324a
Author: Andreas Scheuring <andreas.scheuring@xxxxxxxxxx>
Date:   Tue Feb 2 16:34:59 2016 +0100

    macvtap: Macvtap L2 Agent
    
    This agent is required by the macvtap ml2 driver to support
    macvtap attachments for libvirt qemu/kvm instances. It introduces
    a new configuration option MACVTAP.physical_interface_mappings.
    
    The review is submitted in three parts:
     - Part 1
        Common functions that are used by the ml2 driver and the agent
     - Part 2
         The Mechanism Driver to support port binding for macvtap attachments
     - Part 3 (this part)
        The Macvtap L2 Agent.
    
    DocImpact
    New ML2 mech driver + l2 agent
    New config option "macvtap.physical_interface_mappings"
    
    Change-Id: I219d80b4c704ac2f41edd3501f4b2198925778d6
    Closes-Bug: #1480979


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1480979

Title:
  [RFE] Adding macvtap ml2 driver and agent

Status in neutron:
  Fix Released

Bug 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 (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

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1480979/+subscriptions