<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Hi All,</p>
    <p>I am here with attaching the mockup screens for the proposed
      changes for s390x platform.</p>
    <p><br>
    </p>
    <p>Regards</p>
    <p>Chandra<br>
    </p>
    <div class="moz-cite-prefix">On 8/16/16 10:05 PM, Daniel Henrique
      Barboza wrote:<br>
    </div>
    <blockquote
      cite="mid:5bc74370-0a17-d4b6-8801-cf2769151d53@gmail.com"
      type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      Hi Chandra,<br>
      <br>
      I like the option (2) you provided in all cases, because, as I've
      said, it's a way to<br>
      add the new functionality without changing the existing API/code.
      If libvirt for s390x<br>
      covers the gap and we decide that this new feature is now
      obsolete, it is easier<br>
      to remove it too.<br>
      <br>
      Let's wait for Aline's feedback before deciding which API strategy
      we're going to<br>
      use. Meanwhile I think you can start working in the backend
      modules that will<br>
      add the interface XML to the VM XML (I consider this work to be
      independent<br>
      of how the API will change).<br>
      <br>
      <br>
      Daniel<br>
      <br>
      <br>
      <br>
      <div class="moz-cite-prefix">On 08/16/2016 10:33 AM, Chandra
        Shekhar Reddy Potula wrote:<br>
      </div>
      <blockquote
        cite="mid:6b199d8b-d072-9b2a-0e70-dd94dc13cfa5@linux.vnet.ibm.com"
        type="cite">
        <meta content="text/html; charset=UTF-8"
          http-equiv="Content-Type">
        <p>Hi Daniel,</p>
        <p>Thanks for prompt inputs !!!<br>
        </p>
        Please see my further inputs.<br>
        <br>
        Regards<br>
        Chandra<br>
        <div class="moz-cite-prefix">On 8/15/16 7:40 PM, Daniel Henrique
          Barboza wrote:<br>
        </div>
        <blockquote
          cite="mid:00082379-1c5f-e33f-bcb0-807dbd313a19@gmail.com"
          type="cite">
          <meta content="text/html; charset=UTF-8"
            http-equiv="Content-Type">
          Hi Chandra,<br>
          <br>
          Thanks for this detailed summary. I have a better idea of the
          problem and the proposal now.<br>
          <br>
          First a generic comment: Kimchi also supports a libvirt
          network called passthrough.<br>
          <br>
          Second, I think we may have a different approach here. I am
          seeing that the 'network'<br>
          key isn't required in those APIs, they are optional. If we're
          going into the trouble of changing<br>
          an existing API why not add a new optional parameter
          'interface' to attach the interface<br>
          into the VM without relying on libvirt networks?<br>
          <br>
        </blockquote>
        We had thought about this option too but we were thinking in
        consolidating all the network attributes together. We were
        thinking too many attributes to deal with adding more of them.
        But I like your idea too. <br>
        <br>
        <blockquote
          cite="mid:00082379-1c5f-e33f-bcb0-807dbd313a19@gmail.com"
          type="cite"> This way you have a clearer functionality
          difference in the API and it will be easier to code<br>
          because you will not mess with existing code that relies on
          libvirt networks. And, in my opinion,<br>
          it can be used not only by s390x but for everyone that, for
          any given reason, might want<br>
          to attach directly an interface to the VM instead of relying
          in a libvirt network.<br>
          <br>
          Most of the work will be in adapting the existing UI to
          provide both options (with or without<br>
          libvirt network) and show the user that they are mutually
          exclusive.<br>
          <br>
          Is the idea feasible? Making the 2 approaches coexist?<br>
          <br>
          <br>
        </blockquote>
        See if Proposal 2 provided below looks good. <br>
        <br>
        <blockquote
          cite="mid:00082379-1c5f-e33f-bcb0-807dbd313a19@gmail.com"
          type="cite"> Daniel <br>
          <br>
          <div class="moz-cite-prefix">On 08/12/2016 10:45 AM, Chandra
            Shekhar Reddy Potula wrote:<br>
          </div>
          <blockquote
            cite="mid:3883b7bf-e572-0c3b-50ce-8258f207e228@linux.vnet.ibm.com"
            type="cite">
            <meta content="text/html; charset=UTF-8"
              http-equiv="Content-Type">
            <p>Hi All,</p>
            <p>Let me put the detailed summary !!! <br>
            </p>
            <p>In case of platform s390x, any of the libvirt networks
              are not supported. The only way is attaching the physical
              interface macvtap or attaching ovs bridge directly to the
              guest at this point of time. <br>
            </p>
            <p><b>Expectation of the RFC is to attach macvtap and ovs
                directly to the guest with out libvirt API calls.</b><br>
              <br>
              Example domain xml translations of macvtap and ovs (with
              out any libvirt calls):<br>
              <br>
              <b>OVS: </b><br>
              &lt;interface type="bridge"&gt; <br>
                &lt;source bridge="vswitch0"/&gt; <br>
                &lt;virtualport type="openvswitch"/&gt; <br>
                &lt;model type="virtio"/&gt; <br>
              &lt;/interface&gt; <br>
              <br>
              <b>Macvtap:</b><br>
              macvtap with bridge mode: <br>
              &lt;interface type="direct"&gt; <br>
                &lt;source dev="eth0" mode="bridge"/&gt; <br>
                &lt;model type="virtio"/&gt; <br>
              &lt;/interface&gt; <br>
              <br>
               macvtap with vepa mode: <br>
              &lt;interface type="direct"&gt; <br>
                &lt;source dev="bond0" mode="vepa"/&gt; <br>
                &lt;model type="virtio"/&gt; <br>
              &lt;/interface&gt; <br>
              <br>
              In order to achieve above functionality on s390x,
              recommend the following proposal to the templates and
              guest networking API’s (/templates and /vms/:name/ifaces):<br>
              <b>*Note : the same functionality can also exploited on
                other platforms too like on x86/ppc etc…</b><br>
              <br>
              <b>1. Templates</b><br>
              A. Current : template.conf contains the following details
              for networks :<br>
              <br>
              [main]</p>
            <p>
# List of networks separated by comma
# Represents the
              virtual network interfaces to be assigned to
              guest
#networks = default,<br>
              <br>
              Proposal : is to have dictionary based network details in
              the conf file similar to storage pools.<br>
              <br>
              [interfaces]
</p>
            <p># List of interfaces in the form of dictionary 
#
              Supports attaching virtual networks, macvtap and ovs
              bridge to the guest. <br>
              # type can be of ‘network’ | ‘macvtap’ | ‘ovs’<br>
              # source can be list network or interface or resource
              bridge name. Comma separated values allowed if they are of
              same type.<br>
              # mode required only for macvtap. mode can be either
              bridge or vepa<br>
              <br>
              [interfaces.0]<br>
              #type=network<br>
              #source=default<br>
              #mode=NA<br>
              <br>
              For example to understand other possible types:<br>
              [interfaces.1]<br>
              #type=macvtap<br>
              #source=eth0, eth1<br>
              #mode=bridge or vepa<br>
              <br>
              [interfaces.2]<br>
              #type=ovs<br>
              #source=ovsswitch1<br>
              #mode=NA<br>
              <br>
            </p>
          </blockquote>
        </blockquote>
        Proposal 2: to have existing attribute <i>networks</i> as list
        of virtual network as it is, and have additional attribute <i>
          interfaces</i> for direct network connections (no libvirt
        calls).<br>
        <br>
        [main] <br>
        # List of virtual/libvirt networks separated by comma
<br>
        # Represents the virtual/libvirt network interfaces to be
        assigned to guest
, by default default virtual network attached.
        <br>
        # On s390x if attribute <i>networks</i> commented out then no
        virtual network will be attached by default.<br>
        #networks = default      
<br>
        <br>
        Along with existing configuration additional attribute <i>interfaces</i>
        for direct network interfaces<br>
        <br>
        [interfaces]
 <br>
        # List of network interfaces in the form of dictionary <br>
        
# Supports attaching macvtap and ovs bridge to the guest. <br>
        # type can be of ‘macvtap’ | ‘ovs’<br>
        # name can be of list network interface or ovs bridge name.
        Comma separated values allowed if they are of same type.<br>
        # mode required only for macvtap. mode can be either bridge or
        vepa<br>
        <br>
        Please note by default no network interface will be attached to
        guest/template.<br>
        <br>
        For example to understand other possible types:<br>
        [interfaces.1]<br>
        #type=macvtap<br>
        #name=eth0, eth1<br>
        #mode=bridge or vepa<br>
        <br>
        [interfaces.2]<br>
        #type=ovs<br>
        #name=ovsswitch1<br>
        #mode=NA
        <blockquote
          cite="mid:00082379-1c5f-e33f-bcb0-807dbd313a19@gmail.com"
          type="cite">
          <blockquote
            cite="mid:3883b7bf-e572-0c3b-50ce-8258f207e228@linux.vnet.ibm.com"
            type="cite">
            <p> B. API changes for the templates<br>
              <br>
              Current: network attributes for create/update of template<br>
              networks (optional): list of networks will be assigned to
              the new VM.<br>
              <br>
              Proposal:<br>
              networks (optional): list of dictionary of networks will
              be assigned to the new VM.<br>
                                              type : ‘network’ |
              ‘macvtap’ | ‘ovs’. By specifying macvtap or ovs these
              interface will be attaching to guest directly.<br>
                                              source : network or
              interface or resource bridge name<br>
                                              mode(optional) : kimchi
              supports ’bridge’ or ‘vepa’. required only if
              type=‘macvtap’<br>
              <br>
              <br>
            </p>
          </blockquote>
        </blockquote>
        Proposal 2: attribute <i>networks</i> for get/create/update of
        template<br>
        <ul>
          <li> networks (optional): list of virtual/libvirt networks
            will be assigned to the new VM. By default, <i>default
              virtual network</i> will not be attached in case of s390x.</li>
        </ul>
        <b> </b><br>
        In addition to the attribute <i>networks</i>, template API can
        have attribute <i>interfaces  </i>to deal with direct network
        interfaces (no libvirt calls)<br>
        <ul>
          <li>interfaces (optional) : list of dictionary of network
            interfaces to be assigned to the guest. By specifying
            macvtap or ovs these interface will be attaching to guest
            directly.</li>
        </ul>
                                        type : ‘macvtap’ | ‘ovs’<br>
                                        name : network interface or ovs
        bridge name<br>
                                        mode(optional) : kimchi supports
        ’bridge’ or ‘vepa’. required only if type=‘macvtap’<br>
        <br>
        Please note by default no network interface will be attached to
        guest/template.
        <blockquote
          cite="mid:00082379-1c5f-e33f-bcb0-807dbd313a19@gmail.com"
          type="cite">
          <blockquote
            cite="mid:3883b7bf-e572-0c3b-50ce-8258f207e228@linux.vnet.ibm.com"
            type="cite">
            <p> <b>2. Virtual Machine Network Interfaces</b><br>
              <b>URI: </b>/plugins/kimchi/vms/:name/ifaces<br>
              <br>
              Current:<br>
              POST: attach a network interface to VM<br>
              * model (optional): model of emulated network interface
              card. It can be one of these models: ne2k_pci, i82551,
              i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When
              model is missing, libvirt will set 'rtl8139' as default
              value.<br>
              * network (optional): the name of resource network, it is
              required when the interface type is network.<br>
              * type: The type of VM network interface that libvirt
              supports. Now kimchi just supports 'network' type.<br>
              <br>
              Proposal:<br>
              POST: attach a network interface to VM<br>
              * model (optional): model of emulated network interface
              card. It can be one of these models: ne2k_pci, i82551,
              i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When
              model is missing, libvirt will set 'rtl8139' as default
              value.<br>
              * source : the name of resource network or interface or
              resource bridge name<br>
              * type: kimchi supports 'network'  | ‘macvtap’ | ‘ovs’
              type.<br>
              * mode : kimchi supports ’bridge’ or ‘vepa’. required only
              if type=‘macvtap’<br>
            </p>
          </blockquote>
        </blockquote>
        Proposal 2:<br>
        <strong>GET</strong>: <br>
        <ul>
          <li>networks (optional): Retrieve a summarized list of all
            virtual network interfaces attached to a Virtual Machine. </li>
        </ul>
        <b> </b><br>
        In addition to the attribute <i>networks</i>,  API can have
        attribute <i>interfaces  </i>to deal with direct network
        interfaces (no libvirt calls)<br>
        <ul>
          <li>interfaces (optional):  list of dictionary of network
            interfaces to be assigned to the Virtual Machine. By
            specifying macvtap or ovs, these interfaces will be attached
            to guest directly.</li>
        </ul>
                                        type : ‘macvtap’ | ‘ovs’. <br>
                                        name : network interface or ovs
        bridge name<br>
                                        mode(optional) : kimchi supports
        ’bridge’ or ‘vepa’. required only if type=‘macvtap’<br>
        <br>
        <strong>POST</strong>: attach a virtual network or direct
        interface to VM<br>
        <ul>
          <li>model <em>(optional)</em>: model of emulated network
            interface card. It can be one of these models: ne2k_pci,
            i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio.
            When model is missing, libvirt will set 'rtl8139' as default
            value.</li>
          <li>network <em>(optional)</em>: the name of resource
            network, it is required when the interface type is network.</li>
          <li>type: The type of VM network interface that libvirt
            supports. Now kimchi just supports 'network' type.<br>
          </li>
        </ul>
        In addition to the attribute <i>networks</i>,  API can have
        attribute <i>interfaces  </i>to deal with direct network
        interfaces (no libvirt calls)<br>
        <ul>
          <li>interface (optional):  network interface to be assigned to
            the Virtual Machine. By specifying macvtap or ovs, this
            interface will be attached to guest directly.<br>
                                            type : ‘macvtap’ | ‘ovs’. <br>
                                            name : network interface or
            ovs bridge name<br>
                                            mode(optional) : kimchi
            supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’</li>
        </ul>
        <blockquote
          cite="mid:00082379-1c5f-e33f-bcb0-807dbd313a19@gmail.com"
          type="cite">
          <blockquote
            cite="mid:3883b7bf-e572-0c3b-50ce-8258f207e228@linux.vnet.ibm.com"
            type="cite">
            <p> <br>
              <b>3. Virtual Machine Network Interface</b><b><br>
              </b><b>URI:</b> /plugins/kimchi/vms/:name/ifaces/:mac<br>
              <br>
              Current:<br>
              GET: Retrieve the full description of the VM network
              interface<br>
              * bridge (optional): the name of resource bridge, only be
              available when the interface type is bridge.<br>
              * mac: Media Access Control Address of the VM interface.<br>
              * ips: A list of IP addresses associated with this MAC.<br>
              * model (optional): model of emulated network interface
              card. It will be one of these models: ne2k_pci, i82551,
              i82557b, i82559er, rtl8139, e1000, pcnet and virtio.<br>
              * network (optional): the name of resource network, only
              be available when the interface type is network.<br>
              * type: The type of VM network interface that libvirt
              supports. It will be one of these types: 'network',
              'bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast',
              'server' and 'client'.<br>
              <br>
              Proposal:  <br>
              GET: Retrieve the full description of the VM network
              interface<br>
              * mac: Media Access Control Address of the VM interface.<br>
              * ips: A list of IP addresses associated with this MAC.<br>
              * model (optional): model of emulated network interface
              card. It will be one of these models: ne2k_pci, i82551,
              i82557b, i82559er, rtl8139, e1000, pcnet and virtio.<br>
              * source: the name of resource network or resource bridge
              or interface<br>
              * type: It will be one of these types: 'network',
              ‘macvtap’, ‘ovs’, ’bridge', 'user','ethernet', 'direct',
              'hostdev', 'mcast', 'server' and 'client'.<br>
              * mode : kimchi supports ’bridge’ or ‘vepa’. required only
              if type=‘macvtap’</p>
          </blockquote>
        </blockquote>
        Proposal 2:  <br>
        GET: Retrieve the full description of the VM network interface<br>
        <ul>
          <li> bridge (optional): the name of resource bridge, only be
            available when the interface type is bridge.</li>
          <li> mac: Media Access Control Address of the VM interface.</li>
          <li> ips: A list of IP addresses associated with this MAC.</li>
          <li> model (optional): model of emulated network interface
            card. It will be one of these models: ne2k_pci, i82551,
            i82557b, i82559er, rtl8139, e1000, pcnet and virtio.</li>
          <li> network (optional): the name of resource network, only be
            available when the interface type is network.</li>
          <li> type: The type of VM network interface that libvirt
            supports. It will be one of these types: 'network',
            'bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast',
            'server' and 'client'.</li>
        </ul>
        <br>
        In addition to the attribute <i>networks</i>,  API can have
        attribute <i>interfaces  </i>to deal with direct network
        interfaces (no libvirt calls)<br>
        <ul>
          <li>interface (optional):  network interface to be assigned to
            the Virtual Machine. By specifying macvtap or ovs, this
            interface will be attached to guest directly.<br>
                                            type : ‘macvtap’ | ‘ovs’. <br>
                                            name : network interface or
            ovs bridge name<br>
                                            mode(optional) : kimchi
            supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’</li>
        </ul>
        <br>
        <p><strong>DELETE</strong>: <strong><br>
          </strong></p>
        <p>Deletion of network interfaces has to be supported along with
          virtual network deletions.<br>
        </p>
        <p><br>
        </p>
        <p><strong>PUT</strong>:</p>
        <ul>
          <li>model <em>(optional)</em>: model of emulated network
            interface card. It will be one of these models: ne2k_pci,
            i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio.
            This change is only on the persisted VM configuration.</li>
          <li>network <em>(optional)</em>: the name of resource
            network, only be available when the interface type is
            network. This change is on the active VM instance and
            persisted VM configuration.</li>
        </ul>
        <p>In addition to the attribute <i>networks</i>,  API can have
          attribute <i>interfaces  </i>to deal with direct network
          interfaces (no libvirt calls)</p>
        <ul>
          <li>interface (optional):  network interface to be assigned to
            the Virtual Machine. By specifying macvtap or ovs, this
            interface will be attached to guest directly.<br>
                                            type : ‘macvtap’ | ‘ovs’. <br>
                                            name : network interface or
            ovs bridge name<br>
                                            mode(optional) : kimchi
            supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’</li>
        </ul>
        <p><br>
        </p>
        <blockquote
          cite="mid:00082379-1c5f-e33f-bcb0-807dbd313a19@gmail.com"
          type="cite">
          <blockquote
            cite="mid:3883b7bf-e572-0c3b-50ce-8258f207e228@linux.vnet.ibm.com"
            type="cite">
            <p>Please feel free to suggest any other better ways of
              doing !!!<br>
            </p>
            Regards<br>
            Chandra<br>
            <div class="moz-cite-prefix">On 8/11/16 4:46 PM, Suresh Babu
              Angadi wrote:<br>
            </div>
            <blockquote cite="mid:57AC5E8C.4000300@linux.vnet.ibm.com"
              type="cite"> <br>
              <br>
              On 08/10/2016 11:56 PM, Daniel Henrique Barboza wrote: <br>
              <blockquote type="cite">A lot of changes to be made. <br>
                <br>
                The changes in Ginger -&gt; Gingerbase regarding OVS
                bridges is the simplest <br>
                to do. Gingerbase already has some OVS legacy functions
                from before Ginger <br>
                developed the OVS bridges backend in the module
                netinfo.py. We can see if <br>
                there's something there to list OVS interfaces (can't
                recall now) and, if not, we <br>
                can add it. <br>
                <br>
                The remaining Kimchi changes will need to either do in
                small chunks, avoiding <br>
                changing the working code we have today, or all at once
                with UI changes included <br>
                to avoid breaking the existing UI with the API change.
                I'll leave it up to you which <br>
                approach to go, as long as we don't break the existing
                network support in Kimchi <br>
                in the process. <br>
              </blockquote>
              Agree. <br>
              <blockquote type="cite"> <br>
                Assuming that all this precautions are made, I approve
                this RFC. However, note that <br>
                this is *my* opinion. I am not the official maintainer
                of this plug-in and it would <br>
                be unwise to rely solely on it. It is safer to wait for
                Aline's opinion in this <br>
                RFC before taking any step toward the implementation. <br>
              </blockquote>
              To support s390x architecture which doesn't support
              libvirt virtual networks as of today,, its necessary to
              allow attaching physical interface to guest. Hence would
              start implementing, however any changes/suggestions can be
              accommodated. <br>
              <blockquote type="cite"> <br>
                <br>
                Daniel <br>
                <br>
                On 08/10/2016 05:46 AM, Archana Singh wrote: <br>
                <blockquote type="cite"> <br>
                  On 08/10/2016 12:23 PM, Suresh Babu Angadi wrote: <br>
                  <blockquote type="cite"> <br>
                    <br>
                    On 08/10/2016 12:24 AM, Daniel Henrique Barboza
                    wrote: <br>
                    <blockquote type="cite">I am worried not only by the
                      API.json changes but also in the <br>
                      potential backend changes required. Do you have
                      any prediction of <br>
                      how far these changes might go? <br>
                    </blockquote>
                    from backend, it would remain same for virtual
                    network. For macvtap, validation of interface would
                    be okay since interfaces listing is moved to
                    gingerbase and kimchi is using it for networks hence
                    same code can be utilized. For openvswitch, ginger
                    code will have to be moved to gingerbase to enable
                    kimchi to list host ovs interfaces. <br>
                  </blockquote>
                  On high level I guess below needs to be done, and both
                  point below are independent of each-other. <br>
                  1) Listing of networks based on selected type. (This
                  will mostly use to show list in UI, based on type). <br>
                  2) Once network is selected/provided, an REST API call
                  which will land to control and model. From control
                  point of view it will be addition of parameters. And
                  from model point of view, we need to add if and else
                  to check type. <br>
                  And for virtual type, existing code implementation
                  should work. And for other two type, we need add code
                  for addition of these options in template params. And
                  also code to generate corresponding xml based on type.
                  <br>
                  It will be mostly on template/guest edit/create code
                  and network add/remove from guest/template. <br>
                  <br>
                  May be validation of network(s) to check if network(s)
                  exist( for type macvtap and ovs) or not can be done as
                  improvement to feature. <br>
                  <br>
                  <blockquote type="cite">
                    <blockquote type="cite"> <br>
                      On 08/09/2016 06:12 AM, Suresh Babu Angadi wrote:
                      <br>
                      <blockquote type="cite">Hi All, <br>
                        To support, attaching a physical interface to
                        guest as macvtap or attaching ovs bridge to
                        guest without creating libvirt network, I
                        propose following changes to 'networks'
                        attribute of templates josn. <br>
                        <br>
                        current implementation: <br>
                        'networks' attribute expects list of virtual
                        network names <br>
                        <br>
                        changes: <br>
                        'networks': list of dictionary <br>
                                        type: can be direct, network or
                        bridge <br>
                      </blockquote>
                    </blockquote>
                  </blockquote>
                </blockquote>
              </blockquote>
              Small change in type, to be explicit, its good to have
              type as macvtap(instead of direct), ovs(instead of bridge)
              and virtualnetwork(instead of network). <br>
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <blockquote type="cite">
                      <blockquote type="cite">                interface:
                        name of physical interface(type=direct) or ovs
                        (type=bridge) or virtual network(type=direct) <br>
                                        mode(required if type=direct):
                        bridge or vepa <br>
                        <br>
                        for macvtap: type is direct and mode can be
                        bridge or vepa <br>
                        for ovs: type is bridge and mode is not required
                        <br>
                        for virtual network: type=network(current
                        implementation) <br>
                        <br>
                        Examples of network xml for attaching macvtap
                        and ovs to guest without libvirt: <br>
                        OVS: <br>
                        &lt;interface type="bridge"&gt; <br>
                          &lt;source bridge="vswitch0"/&gt; <br>
                          &lt;virtualport type="openvswitch"/&gt; <br>
                          &lt;model type="virtio"/&gt; <br>
                        &lt;/interface&gt; <br>
                        <br>
                        macvtap with bridge mode: <br>
                        &lt;interface type="direct"&gt; <br>
                          &lt;source dev="eth0" mode="bridge"/&gt; <br>
                          &lt;model type="virtio"/&gt; <br>
                        &lt;/interface&gt; <br>
                        <br>
                         macvtap with vepa mode: <br>
                        &lt;interface type="direct"&gt; <br>
                          &lt;source dev="bond0" mode="vepa"/&gt; <br>
                          &lt;model type="virtio"/&gt; <br>
                        &lt;/interface&gt; <br>
                        <br>
                      </blockquote>
                      <br>
                      _______________________________________________ <br>
                      Kimchi-devel mailing list <br>
                      <a moz-do-not-send="true"
                        class="moz-txt-link-abbreviated"
                        href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
                      <br>
                      <a moz-do-not-send="true"
                        class="moz-txt-link-freetext"
                        href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
                      <br>
                      <br>
                    </blockquote>
                    <br>
                  </blockquote>
                  <br>
                  _______________________________________________ <br>
                  Kimchi-devel mailing list <br>
                  <a moz-do-not-send="true"
                    class="moz-txt-link-abbreviated"
                    href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
                  <br>
                  <a moz-do-not-send="true"
                    class="moz-txt-link-freetext"
                    href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
                  <br>
                </blockquote>
                <br>
                _______________________________________________ <br>
                Kimchi-devel mailing list <br>
                <a moz-do-not-send="true"
                  class="moz-txt-link-abbreviated"
                  href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
                <br>
                <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
                <br>
                <br>
              </blockquote>
              <br>
            </blockquote>
            <br>
            <br>
            <fieldset class="mimeAttachmentHeader"></fieldset>
            <br>
            <pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
          </blockquote>
          <br>
          <br>
          <fieldset class="mimeAttachmentHeader"></fieldset>
          <br>
          <pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
        </blockquote>
        <br>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>