libvirt/docs/schemas
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
..
basictypes.rng xml: create an RNG file for common types and move some definitions there 2011-07-05 12:33:21 -04:00
capability.rng microblaze: Add architecture support 2011-07-07 17:49:21 -06:00
domain.rng conf: support abstracted interface info in domain interface XML 2011-07-21 14:46:44 -04:00
domainsnapshot.rng
interface.rng xml: create an RNG file for common types and move some definitions there 2011-07-05 12:33:21 -04:00
Makefile.am conf: put virtPortProfile struct / functions in a common location 2011-07-21 14:46:33 -04:00
network.rng conf: support abstracted interface info in network XML 2011-07-21 14:46:53 -04:00
networkcommon.rng conf: put virtPortProfile struct / functions in a common location 2011-07-21 14:46:33 -04:00
nodedev.rng maint: convert leading TABs in *.rng files to equivalent spaces 2010-03-01 20:19:20 +01:00
nwfilter.rng nwfilter: enable filtering of gratuitous ARP packets 2011-05-23 19:41:18 -04:00
secret.rng
storageencryption.rng
storagepool.rng Fix parsing of port attribute in storage XML configuration 2010-11-23 14:55:33 +00:00
storagevol.rng