libvirt/tests/networkxml2xmlin
Laine Stump 40fd7073be conf: support abstracted interface info in network XML
The network XML is updated in the following ways:

1) The <forward> element can now contain a list of forward interfaces:

     <forward .... >
       <interface dev='eth10'/>
       <interface dev='eth11'/>
       <interface dev='eth12'/>
       <interface dev='eth13'/>
     </forward>

   The first of these takes the place of the dev attribute that is
   normally in <forward> - when defining a network you can specify
   either one, and on output both will be present. If you specify
   both on input, they must match.

2) In addition to forward modes of 'nat' and 'route', these new modes
   are supported:

     private, passthrough, vepa - when this network is referenced by a
     domain's interface, it will have the same effect as if the
     interface had been defined as type='direct', e.g.:

        <interface type='direct'>
          <source mode='${mode}' dev='${dev}>
          ...
        </interface>

     where ${mode} is one of the three new modes, and ${dev} is an interface
     selected from the list given in <forward>.

     bridge - if a <forward> dev (or multiple devs) is defined, and
     forward mode is 'bridge' this is just like the modes 'private',
     'passthrough', and 'vepa' above. If there is no forward dev
     specified but a bridge name is given (e.g. "<bridge
     name='br0'/>"), then guest interfaces using this network will use
     libvirt's "host bridge" mode, equivalent to this:

       <interface type='bridge'>
          <source bridge='${bridge-name}'/>
          ...
       </interface>

3) A network can have multiple <portgroup> elements, which may be
   selected by the guest interface definition (by adding
   "portgroup='${name}'" in the <source> element along with the
   network name). Currently a portgroup can only contain a
   virtportprofile, but the intent is that other configuration items
   may be put there int the future (e.g. bandwidth config). When
   building a guest's interface, if the <interface> XML itself has no
   virtportprofile, and if the requested network has a portgroup with
   a name matching the name given in the <interface> (or if one of the
   network's portgroups is marked with the "default='yes'" attribute),
   the virtportprofile from that portgroup will be used by the
   interface.

4) A network can have a virtportprofile defined at the top level,
   which will be used by a guest interface when connecting in one of
   the 'direct' modes if the guest interface XML itself hasn't
   specified any virtportprofile, and if there are also no matching
   portgroups on the network.
2011-07-21 14:46:53 -04:00
..
8021Qbh-net.xml conf: support abstracted interface info in network XML 2011-07-21 14:46:53 -04:00
direct-net.xml conf: support abstracted interface info in network XML 2011-07-21 14:46:53 -04:00
host-bridge-net.xml conf: support abstracted interface info in network XML 2011-07-21 14:46:53 -04:00
isolated-network.xml Give each virtual network bridge its own fixed MAC address 2011-02-17 13:36:32 -05:00
nat-network-dns-hosts.xml Network: Add support for DNS hosts definition to the network XML 2011-06-24 16:15:36 -04:00
nat-network-dns-txt-record.xml Add TXT record support for virtual DNS service 2011-06-24 16:15:12 -04:00
nat-network.xml Change virtual network XML parsing/formatting to support IPv6 2010-12-23 15:53:55 -05:00
netboot-network.xml
netboot-proxy-network.xml
routed-network.xml Give each virtual network bridge its own fixed MAC address 2011-02-17 13:36:32 -05:00
vepa-net.xml conf: support abstracted interface info in network XML 2011-07-21 14:46:53 -04:00