<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 08/01/2012 03:59 PM, Mark Wu wrote:
    <blockquote cite="mid:50192822.9030309@linux.vnet.ibm.com"
      type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      Sorry for cross-posting!<br>
      <br>
      I would like to inquiry about the roadmap of host network
      management in oVirt in order to<br>
      make sure the ideas to be worked on are welcomed by community. <br>
      <br>
      I did some initial investigation on the following topics.&nbsp; <font
        color="#ff0000">I am not very familiar with them, so the
        information may contain some inaccuracies or errors.<br>
      </font><br>
      netcf:<br>
      &nbsp;&nbsp; &nbsp;<br>
      &nbsp;&nbsp;&nbsp; It provides cross-platform network configuration library/tool
      by converting the XML definition of an interface into local config
      file. It's already used by libvirt to manage host network
      interfaces.It supports all network entities including bridge,
      vlan, bond, nic. And it also supports configuration rollback.&nbsp; The
      benefit for vdsm is making host network stack configuration easy
      to port to other distros. <br>
      &nbsp;&nbsp; &nbsp;<br>
      Problems found:<br>
      &nbsp;&nbsp;&nbsp; It doesn't restore interface live state during config
      transaction now. There's a feature request submit for it.<br>
      &nbsp;&nbsp;&nbsp; There're some advanced settings not supported in netcf, like
      'NM_CONTROLLED' and some less used bonding options.<br>
      <br>
      &nbsp;&nbsp;&nbsp; It doesn't provide python binding officially. But we can use
      libvirt API to integrate it into vdsm. It shouldn't have any
      impact on engine side.<br>
      <br>
      <br>
      IEEE 802.1Qbg(VEPA)<br>
      <br>
      &nbsp;&nbsp;&nbsp;&nbsp; It can offload network switching from server to external
      physical switch. It makes all VMs' traffic visible to physical
      switch, and therefore the existing switch functions (firewall, QoS
      etc) can be applied to VM immediately. The offload also frees up
      the server resource used by switching. <br>
      &nbsp;&nbsp;&nbsp;&nbsp; Now libvirt supports it by using macvtap as vif and working
      with lldpad, which registers vif's mac/vlan information to the
      physical switch. We can just add a 'virtualport' element to an
      interface XML definition to add a VEPA interface. Probably, to
      support it in oVirt we still need configure lldpad&nbsp; and query
      available VSI types for virtualport profile.<br>
      <br>
      <br>
      quantum<br>
      <br>
      &nbsp;&nbsp; Both the plugins openvswitch and linuxbridge stores abstract
      network entities (network, port) in database and create
      bridge/vlan via the tool ip/brctl or ovs-vsctl on demand. Only one
      bridge is created on one server and one vlan is created for each
      virtual network. That means that only one nic can be configured
      for vm network.&nbsp; It doesn't configure nic or bond even if
      openvswitch also supports bond. Both of traditional network stack
      configuration and quantum will be supported oVirt for different
      purpose, right?<br>
    </blockquote>
    <br>
    Please not that there are a large amount of suported plugins. Please
    look at <a class="moz-txt-link-freetext" href="http://wiki.openstack.org/Quantum">http://wiki.openstack.org/Quantum</a> to see a list of plugins.
    In addition to this there is a meta plugin which is currently in
    review - this is a plugin that can support more than one plugin :)
    (At the moment Quantum only supports one plugin)<br>
    <blockquote cite="mid:50192822.9030309@linux.vnet.ibm.com"
      type="cite"> <br>
      &nbsp;&nbsp; Any comments? Thanks!<br>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Arch mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Arch@ovirt.org">Arch@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/arch">http://lists.ovirt.org/mailman/listinfo/arch</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>