mirror of https://gitee.com/openkylin/libvirt.git
778 lines
36 KiB
HTML
778 lines
36 KiB
HTML
<html>
|
|
<body>
|
|
<h1>Network XML format</h1>
|
|
|
|
<ul id="toc">
|
|
</ul>
|
|
|
|
<p>
|
|
This page provides an introduction to the network XML format. For background
|
|
information on the concepts referred to here, consult the <a href="archnetwork.html">network driver architecture</a>
|
|
page.
|
|
</p>
|
|
|
|
<h2><a name="elements">Element and attribute overview</a></h2>
|
|
|
|
<p>
|
|
The root element required for all virtual networks is
|
|
named <code>network</code> and has no configurable attributes
|
|
(although <span class="since">since 0.10.0</span> there is one
|
|
optional read-only attribute - when examining the live
|
|
configuration of a network, the
|
|
attribute <code>connections</code>, if present, specifies the
|
|
number of guest interfaces currently connected via this
|
|
network). The network XML format is
|
|
available <span class="since">since 0.3.0</span>
|
|
</p>
|
|
|
|
<h3><a name="elementsMetadata">General metadata</a></h3>
|
|
|
|
<p>
|
|
The first elements provide basic metadata about the virtual
|
|
network.
|
|
</p>
|
|
|
|
<pre>
|
|
<network>
|
|
<name>default</name>
|
|
<uuid>3e3fce45-4f53-4fa7-bb32-11f34168b82b</uuid>
|
|
...</pre>
|
|
|
|
<dl>
|
|
<dt><code>name</code></dt>
|
|
<dd>The content of the <code>name</code> element provides
|
|
a short name for the virtual network. This name should
|
|
consist only of alpha-numeric characters and is required
|
|
to be unique within the scope of a single host. It is
|
|
used to form the filename for storing the persistent
|
|
configuration file. <span class="since">Since 0.3.0</span></dd>
|
|
<dt><code>uuid</code></dt>
|
|
<dd>The content of the <code>uuid</code> element provides
|
|
a globally unique identifier for the virtual network.
|
|
The format must be RFC 4122 compliant, eg <code>3e3fce45-4f53-4fa7-bb32-11f34168b82b</code>.
|
|
If omitted when defining/creating a new network, a random
|
|
UUID is generated. <span class="since">Since 0.3.0</span></dd>
|
|
</dl>
|
|
|
|
<h3><a name="elementsConnect">Connectivity</a></h3>
|
|
|
|
<p>
|
|
The next set of elements control how a virtual network is
|
|
provided connectivity to the physical LAN (if at all).
|
|
</p>
|
|
|
|
<pre>
|
|
...
|
|
<bridge name="virbr0" stp="on" delay="5"/>
|
|
<domain name="example.com"/>
|
|
<forward mode="nat" dev="eth0"/>
|
|
...</pre>
|
|
|
|
<dl>
|
|
<dt><code>bridge</code></dt>
|
|
<dd>The <code>name</code> attribute on the <code>bridge</code> element
|
|
defines the name of a bridge device which will be used to construct
|
|
the virtual network. The virtual machines will be connected to this
|
|
bridge device allowing them to talk to each other. The bridge device
|
|
may also be connected to the LAN. It is recommended that bridge
|
|
device names started with the prefix <code>vir</code>, but the name
|
|
<code>virbr0</code> is reserved for the "default" virtual
|
|
network. This element should always be provided when defining
|
|
a new network with a <code><forward></code> mode of
|
|
"nat" or "route" (or an isolated network with
|
|
no <code><forward></code> element).
|
|
Attribute <code>stp</code> specifies if Spanning Tree Protocol
|
|
is 'on' or 'off' (default is
|
|
'on'). Attribute <code>delay</code> sets the bridge's forward
|
|
delay value in seconds (default is 0).
|
|
<span class="since">Since 0.3.0</span>
|
|
</dd>
|
|
<dt><code>domain</code></dt>
|
|
<dd>
|
|
The <code>name</code> attribute on the <code>domain</code>
|
|
element defines the DNS domain of the DHCP server. This
|
|
element is optional, and is only used for those networks with
|
|
a <code><forward></code> mode of "nat" or "route" (or an
|
|
isolated network with no <code><forward></code>
|
|
element). <span class="since">Since 0.4.5</span>
|
|
</dd>
|
|
<dt><code>forward</code></dt>
|
|
<dd>Inclusion of the <code>forward</code> element indicates that
|
|
the virtual network is to be connected to the physical
|
|
LAN.<span class="since">Since 0.3.0.</span>
|
|
The <code>mode</code> attribute determines the method of
|
|
forwarding. If there is no <code>forward</code> element, the
|
|
network will be isolated from any other network (unless a
|
|
guest connected to that network is acting as a router, of
|
|
course). The following are valid settings
|
|
for <code>mode</code> (if there is a <code>forward</code>
|
|
element but mode is not specified, <code>mode='nat'</code> is
|
|
assumed):
|
|
<dl>
|
|
<dt><code>nat</code></dt>
|
|
<dd>
|
|
All traffic between guests connected to this network and
|
|
the physical network will be forwarded to the physical
|
|
network via the host's IP routing stack, after the guest's
|
|
IP address is translated to appear as the host machine's
|
|
public IP address (a.k.a. Network Address Translation, or
|
|
"NAT"). This allows multiple guests, all having access to
|
|
the physical network, on a host that is only allowed a
|
|
single public IP address. If a network has any IPv6
|
|
addresses defined, the IPv6 traffic will be forwarded
|
|
using plain routing, since IPv6 has no concept of NAT.
|
|
Firewall rules will allow outbound connections to any
|
|
other network device whether ethernet, wireless, dialup,
|
|
or VPN. If the <code>dev</code> attribute is set, the
|
|
firewall rules will restrict forwarding to the named
|
|
device only. Inbound connections from other networks are
|
|
all prohibited; all connections between guests on the same
|
|
network, and to/from the host to the guests, are
|
|
unrestricted and not NATed.<span class="since">Since
|
|
0.4.2</span>
|
|
</dd>
|
|
|
|
<dt><code>route</code></dt>
|
|
<dd>
|
|
Guest network traffic will be forwarded to the physical
|
|
network via the host's IP routing stack, but without
|
|
having NAT applied. Again, if the <code>dev</code>
|
|
attribute is set, firewall rules will restrict forwarding
|
|
to the named device only. This presumes that the local LAN
|
|
router has suitable routing table entries to return
|
|
traffic to this host. All incoming and outgoing sessions
|
|
to guest on these networks are unrestricted. (To restrict
|
|
incoming traffic to a guest on a routed network, you can
|
|
configure <a href="formatnwfilter.html">nwfilter rules</a>
|
|
on the guest's interfaces.)
|
|
<span class="since">Since 0.4.2</span>
|
|
</dd>
|
|
|
|
<dt><code>bridge</code></dt>
|
|
<dd>
|
|
This network describes either 1) an existing host bridge
|
|
that was configured outside of libvirt (if
|
|
a <code><bridge name='xyz'/></code> element has been
|
|
specified, <span class="since">Since 0.9.4</span>), 2) an
|
|
existing Open vSwitch bridge that was configured outside of
|
|
libvirt (if both a <code><bridge name='xyz'/></code>
|
|
element <b>and</b> a <code><virtualport
|
|
type='openvswitch'/></code> have been
|
|
specified <span class="since">Since 0.10.0</span>) 3) an
|
|
interface or group of interfaces to be used for a "direct"
|
|
connection via macvtap using macvtap's "bridge" mode (if
|
|
the forward element has one or
|
|
more <code><interface></code>
|
|
subelements, <span class="since">Since 0.9.4</span>)
|
|
(see <a href="formatdomain.html#elementsNICSDirect">Direct
|
|
attachment to physical interface</a> for descriptions of
|
|
the various macvtap modes). libvirt doesn't attempt to
|
|
manage the bridge interface at all, thus
|
|
the <code><bridge></code> element's <code>stp</code>
|
|
and <code>delay</code> attributes are not allowed; no
|
|
iptables rules, IP addresses, or DHCP/DNS services are
|
|
added; at the IP level, the guest interface appears to be
|
|
directly connected to the physical
|
|
interface.<span class="since">Since 0.9.4</span>
|
|
</dd>
|
|
<dt><code>private</code></dt>
|
|
<dd>
|
|
This network uses a macvtap "direct" connection in
|
|
"private" mode to connect each guest to the network. The
|
|
physical interface to be used will be picked from among
|
|
those listed in <code><interface></code> subelements
|
|
of the <code><forward></code> element; when using
|
|
802.1Qbh mode (as indicated by
|
|
the <code><virtualport></code> type attribute - note
|
|
that this requires an 802.1Qbh-capable hardware switch),
|
|
each physical interface can only be in use by a single
|
|
guest interface at a time; in modes other than 802.1Qbh,
|
|
multiple guest interfaces can share each physical
|
|
interface (libvirt will attempt to balance usage between
|
|
all available interfaces).<span class="since">Since
|
|
0.9.4</span>
|
|
</dd>
|
|
<dt><code>vepa</code></dt>
|
|
<dd>
|
|
This network uses a macvtap "direct" connection in "vepa"
|
|
mode to connect each guest to the network (this requires
|
|
that the physical interfaces used be connected to a
|
|
vepa-capable hardware switch. The physical interface to be
|
|
used will be picked from among those listed
|
|
in <code><interface></code> subelements of
|
|
the <code><forward></code> element; multiple guest
|
|
interfaces can share each physical interface (libvirt will
|
|
attempt to balance usage between all available
|
|
interfaces).<span class="since">Since 0.9.4</span>
|
|
</dd>
|
|
<dt><code>passthrough</code></dt>
|
|
<dd>
|
|
This network uses a macvtap "direct" connection in
|
|
"passthrough" mode to connect each guest to the network
|
|
(note that this is <i>not</i> the same thing as "PCI
|
|
passthrough"). The physical interface to be used will be
|
|
picked from among those listed
|
|
in <code><interface></code> subelements of
|
|
the <code><forward></code> element. Each physical
|
|
interface can only be in use by a single guest interface
|
|
at a time, so libvirt will keep track of which interfaces
|
|
are currently in use, and only assign unused interfaces
|
|
(if there are no available physical interfaces when a
|
|
domain interface is being attached, an error will be
|
|
logged, and the operation causing the attach will fail
|
|
(usually either a domain start, or a hotplug interface
|
|
attach to a domain).<span class="since">Since 0.9.4</span>
|
|
</dd>
|
|
<dt><code>hostdev</code></dt>
|
|
<dd>
|
|
This network facilitates PCI Passthrough of a network
|
|
device. A network device is chosen from the interface
|
|
pool and directly assigned to the guest using generic
|
|
device passthrough, after first optionally setting the
|
|
device's MAC address and vlan tag to the configured value,
|
|
and optionally associating the device with an 802.1Qbh
|
|
capable switch using a <code><virtualport></code>
|
|
element. Note that - due to limitations in standard
|
|
single-port PCI ethernet card driver design - only SR-IOV
|
|
(Single Root I/O Virtualization) virtual function (VF)
|
|
devices can be assigned in this manner; to assign a
|
|
standard single-port PCI or PCIe ethernet card to a guest,
|
|
use the traditional <code>< hostdev></code> device
|
|
definition. <span class="since"> Since 0.10.0</span>
|
|
|
|
<p>Note that this "intelligent passthrough" of network
|
|
devices is very similar to the functionality of a
|
|
standard <code>< hostdev></code> device, the
|
|
difference being that this method allows specifying a MAC
|
|
address, vlan tag, and <code><virtualport ></code>
|
|
for the passed-through device. If these capabilities are
|
|
not required, if you have a standard single-port PCI,
|
|
PCIe, or USB network card that doesn't support SR-IOV (and
|
|
hence would anyway lose the configured MAC address during
|
|
reset after being assigned to the guest domain), or if you
|
|
are using a version of libvirt older than 0.10.0, you
|
|
should use a standard
|
|
<code><hostdev></code> device definition in the
|
|
domain's configuration to assign the device to the guest
|
|
instead of defining an <code><interface
|
|
type='network'></code> pointing to a network
|
|
with <code><forward mode='hostdev'/></code>.
|
|
</p>
|
|
</dd>
|
|
</dl>
|
|
As mentioned above, a <code><forward></code> element can
|
|
have multiple <code><interface></code> subelements, each
|
|
one giving the name of a physical interface that can be used
|
|
for this network <span class="since">Since 0.9.4</span>:
|
|
<pre>
|
|
...
|
|
<forward mode='passthrough'>
|
|
<interface dev='eth10'/>
|
|
<interface dev='eth11'/>
|
|
<interface dev='eth12'/>
|
|
<interface dev='eth13'/>
|
|
<interface dev='eth14'/>
|
|
</forward>
|
|
...
|
|
</pre>
|
|
<p>
|
|
<span class="since">since 0.10.0</span>,
|
|
<code><interface></code> also has an optional read-only
|
|
attribute - when examining the live configuration of a
|
|
network, the attribute <code>connections</code>, if present,
|
|
specifies the number of guest interfaces currently connected
|
|
via this physical interface.
|
|
</p>
|
|
<p>
|
|
Additionally, <span class="since">since 0.9.10</span>, libvirt
|
|
allows a shorthand for specifying all virtual interfaces
|
|
associated with a single physical function, by using
|
|
the <code><pf></code> subelement to call out the
|
|
corresponding physical interface associated with multiple
|
|
virtual interfaces:
|
|
</p>
|
|
<pre>
|
|
...
|
|
<forward mode='passthrough'>
|
|
<pf dev='eth0'/>
|
|
</forward>
|
|
...
|
|
</pre>
|
|
|
|
<p>When a guest interface is being constructed, libvirt will pick
|
|
an interface from this list to use for the connection. In
|
|
modes where physical interfaces can be shared by multiple
|
|
guest interfaces, libvirt will choose the interface that
|
|
currently has the least number of connections. For those modes
|
|
that do not allow sharing of the physical device (in
|
|
particular, 'passthrough' mode, and 'private' mode when using
|
|
802.1Qbh), libvirt will choose an unused physical interface
|
|
or, if it can't find an unused interface, fail the operation.</p>
|
|
|
|
<p>
|
|
<span class="since">since 0.10.0</span> When using forward
|
|
mode 'hostdev', the interface pool is specified with a list
|
|
of <code><address></code> elements, each of which has
|
|
<code>< type></code> (must always be <code>'pci'</code>,
|
|
<code><domain></code>, <code><bus></code>,
|
|
<code><slot></code>, and <code><function></code>
|
|
attributes.
|
|
</p>
|
|
<pre>
|
|
...
|
|
<forward mode='hostdev' managed='yes'>
|
|
<address type='pci' domain='0' bus='4' slot='0' function='1'/>
|
|
<address type='pci' domain='0' bus='4' slot='0' function='2'/>
|
|
<address type='pci' domain='0' bus='4' slot='0' function='3'/>
|
|
</forward>
|
|
...
|
|
</pre>
|
|
|
|
Alternatively the interface pool can also be defined using a
|
|
single physical function <code><pf></code> subelement to
|
|
call out the corresponding physical interface associated with
|
|
multiple virtual interfaces (similar to passthrough mode):
|
|
|
|
<pre>
|
|
...
|
|
<forward mode='hostdev' managed='yes'>
|
|
<pf dev='eth0'/>
|
|
</forward>
|
|
...
|
|
</pre>
|
|
|
|
</dd>
|
|
</dl>
|
|
<h5><a name="elementQoS">Quality of service</a></h5>
|
|
|
|
<pre>
|
|
...
|
|
<forward mode='nat' dev='eth0'/>
|
|
<b><bandwidth>
|
|
<inbound average='1000' peak='5000' burst='5120'/>
|
|
<outbound average='128' peak='256' burst='256'/>
|
|
</bandwidth></b>
|
|
...</pre>
|
|
|
|
<p>
|
|
This part of network XML provides setting quality of service. Incoming
|
|
and outgoing traffic can be shaped independently. The
|
|
<code>bandwidth</code> element can have at most one <code>inbound</code>
|
|
and at most one <code>outbound</code> child elements. Leaving any of these
|
|
children element out result in no QoS applied on that traffic direction.
|
|
So, when you want to shape only network's incoming traffic, use
|
|
<code>inbound</code> only, and vice versa. Each of these elements have one
|
|
mandatory attribute <code>average</code>. It specifies average bit rate on
|
|
interface being shaped. Then there are two optional attributes:
|
|
<code>peak</code>, which specifies maximum rate at which bridge can send
|
|
data, and <code>burst</code>, amount of bytes that can be burst at
|
|
<code>peak</code> speed. Accepted values for attributes are integer
|
|
numbers, The units for <code>average</code> and <code>peak</code> attributes
|
|
are kilobytes per second, and for the <code>burst</code> just kilobytes.
|
|
The rate is shared equally within domains connected to the network.
|
|
Moreover, <code>bandwidth</code> element can be included in
|
|
<code>portgroup</code> element.
|
|
<span class="since">Since 0.9.4</span>
|
|
</p>
|
|
|
|
<h5><a name="elementVlanTag">Setting VLAN tag (on supported network types only)</a></h5>
|
|
|
|
<pre>
|
|
...
|
|
<devices>
|
|
<interface type='bridge'>
|
|
<b><vlan trunk='yes'></b>
|
|
<b><tag id='42'/></b>
|
|
<b><tag id='47'/></b>
|
|
<b></vlan></b>
|
|
<source bridge='ovsbr0'/>
|
|
<virtualport type='openvswitch'>
|
|
<parameters interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/>
|
|
</virtualport>
|
|
</interface>
|
|
<devices>
|
|
...</pre>
|
|
|
|
<p>
|
|
If (and only if) the network type supports vlan tagging
|
|
transparent to the guest, an optional <code><vlan></code>
|
|
element can specify one or more vlan tags to apply to the
|
|
traffic of all guests using this
|
|
network <span class="since">Since 0.10.0</span>. (openvswitch
|
|
and type='hostdev' SR-IOV networks do support transparent vlan
|
|
tagging of guest traffic; everything else, including standard
|
|
linux bridges and libvirt's own virtual networks, <b>do not</b>
|
|
support it. 802.1Qbh (vn-link) and 802.1Qbg (VEPA) switches
|
|
provide their own way (outside of libvirt) to tag guest traffic
|
|
onto specific vlans.) As expected, the <code>tag</code>
|
|
attribute specifies which vlan tag to use. If a network has more
|
|
than one <code><vlan></code> element defined, it is
|
|
assumed that the user wants to do VLAN trunking using all the
|
|
specified tags. In the case that vlan trunking with a single tag
|
|
is desired, the optional attribute <code>trunk='yes'</code> can
|
|
be added to the vlan element.
|
|
</p>
|
|
<p>
|
|
<code><vlan></code> elements can also be specified in
|
|
a <code><portgroup></code> element, as well as directly in
|
|
a domain's <code><interface></code> element. In the case
|
|
that a vlan tag is specified in multiple locations, the setting
|
|
in <code><interface></code> takes precedence, followed by
|
|
the setting in the <code><portgroup></code> selected by
|
|
the interface config. The <code><vlan></code>
|
|
in <code><network></code> will be selected only if none is
|
|
given in <code><portgroup></code>
|
|
or <code><interface></code>.
|
|
</p>
|
|
|
|
<h5><a name="elementsPortgroup">Portgroups</a></h5>
|
|
|
|
<pre>
|
|
...
|
|
<forward mode='private'/>
|
|
<interface dev="eth20"/>
|
|
<interface dev="eth21"/>
|
|
<interface dev="eth22"/>
|
|
<interface dev="eth23"/>
|
|
<interface dev="eth24"/>
|
|
</forward>
|
|
<b><portgroup name='engineering' default='yes'>
|
|
<virtualport type='802.1Qbh'>
|
|
<parameters profileid='test'/>
|
|
</virtualport>
|
|
<bandwidth>
|
|
<inbound average='1000' peak='5000' burst='5120'/>
|
|
<outbound average='1000' peak='5000' burst='5120'/>
|
|
</bandwidth>
|
|
</portgroup></b>
|
|
<b><portgroup name='sales'>
|
|
<virtualport type='802.1Qbh'>
|
|
<parameters profileid='salestest'/>
|
|
</virtualport>
|
|
<bandwidth>
|
|
<inbound average='500' peak='2000' burst='2560'/>
|
|
<outbound average='128' peak='256' burst='256'/>
|
|
</bandwidth>
|
|
</portgroup></b>
|
|
...</pre>
|
|
|
|
<p>
|
|
<span class="since">Since 0.9.4</span>
|
|
A portgroup provides a method of easily putting guest
|
|
connections to the network into different classes, with each
|
|
class potentially having a different level/type of service.
|
|
<span class="since">Since 0.9.4</span> Each
|
|
network can have multiple portgroup elements (and one of those
|
|
can optionally be designated as the 'default' portgroup for the
|
|
network), and each portgroup has a name, as well as various
|
|
subelements associated with it. The currently supported
|
|
subelements are <code><bandwidth></code>
|
|
(documented <a href="formatdomain.html#elementQoS">here</a>)
|
|
and <code><virtualport></code>
|
|
(documented <a href="formatdomain.html#elementsNICSDirect">here</a>).
|
|
If a domain interface definition specifies a portgroup (by
|
|
adding a <code>portgroup</code> attribute to
|
|
the <code><source></code> subelement), that portgroup's
|
|
info will be merged into the interface's configuration. If no
|
|
portgroup is given in the interface definition, and one of the
|
|
network's portgroups has <code>default='yes'</code>, that
|
|
default portgroup will be used. If no portgroup is given in the
|
|
interface definition, and there is no default portgroup, then
|
|
none will be used. Any <code><bandwidth></code>
|
|
|
|
specified directly in the domain XML will take precedence over
|
|
any setting in the chosen portgroup. if
|
|
a <code><virtualport></code> is specified in the portgroup
|
|
(and/or directly in the network definition), the multiple
|
|
virtualports will be merged, and any parameter that is specified
|
|
in more than one virtualport, and is not identical, will be
|
|
considered an error, and will prevent the interface from
|
|
starting.
|
|
</p>
|
|
|
|
<h3><a name="elementsAddress">Addressing</a></h3>
|
|
|
|
<p>
|
|
The final set of elements define the addresses (IPv4 and/or
|
|
IPv6, as well as MAC) to be assigned to the bridge device
|
|
associated with the virtual network, and optionally enable DHCP
|
|
services. These elements are only valid for isolated networks
|
|
(no <code>forward</code> element specified), and for those with
|
|
a forward mode of 'route' or 'nat'.
|
|
</p>
|
|
|
|
<pre>
|
|
...
|
|
<mac address='00:16:3E:5D:C7:9E'/>
|
|
<domain name="example.com"/>
|
|
<dns>
|
|
<txt name="example" value="example value" />
|
|
<srv service='name' protocol='tcp' domain='test-domain-name' target='.' port='1024' priority='10' weight='10'/>
|
|
<host ip='192.168.122.2'>
|
|
<hostname>myhost</hostname>
|
|
<hostname>myhostalias</hostname>
|
|
</host>
|
|
</dns>
|
|
<ip address="192.168.122.1" netmask="255.255.255.0">
|
|
<dhcp>
|
|
<range start="192.168.122.100" end="192.168.122.254" />
|
|
<host mac="00:16:3e:77:e2:ed" name="foo.example.com" ip="192.168.122.10" />
|
|
<host mac="00:16:3e:3e:a9:1a" name="bar.example.com" ip="192.168.122.11" />
|
|
</dhcp>
|
|
</ip>
|
|
<ip family="ipv6" address="2001:db8:ca2:2::1" prefix="64" />
|
|
</network></pre>
|
|
|
|
<dl>
|
|
<dt><code>mac</code></dt>
|
|
<dd>The <code>address</code> attribute defines a MAC
|
|
(hardware) address formatted as 6 groups of 2-digit
|
|
hexadecimal numbers, the groups separated by colons
|
|
(eg, <code>"52:54:00:1C:DA:2F"</code>). This MAC address is
|
|
assigned to the bridge device when it is created. Generally
|
|
it is best to not specify a MAC address when creating a
|
|
network - in this case, if a defined MAC address is needed for
|
|
proper operation, libvirt will automatically generate a random
|
|
MAC address and save it in the config. Allowing libvirt to
|
|
generate the MAC address will assure that it is compatible
|
|
with the idiosyncrasies of the platform where libvirt is
|
|
running. <span class="since">Since 0.8.8</span>
|
|
</dd>
|
|
<dt><code>dns</code></dt><dd>
|
|
The dns element of a network contains configuration information for the
|
|
virtual network's DNS server. <span class="since">Since 0.9.3</span>
|
|
Currently supported elements are:
|
|
<dl>
|
|
<dt><code>txt</code></dt>
|
|
<dd>A <code>dns</code> element can have 0 or more <code>txt</code> elements.
|
|
Each txt element defines a DNS TXT record and has two attributes, both
|
|
required: a name that can be queried via dns, and a value that will be
|
|
returned when that name is queried. names cannot contain embedded spaces
|
|
or commas. value is a single string that can contain multiple values
|
|
separated by commas. <span class="since">Since 0.9.3</span>
|
|
</dd>
|
|
<dt><code>host</code></dt>
|
|
<dd>The <code>host</code> element within <code>dns</code> is the
|
|
definition of DNS hosts to be passed to the DNS service. The IP
|
|
address is identified by the <code>ip</code> attribute and the names
|
|
for that IP address are identified in the <code>hostname</code>
|
|
sub-elements of the <code>host</code> element.
|
|
<span class="since">Since 0.9.3</span>
|
|
</dd>
|
|
</dl>
|
|
<dl>
|
|
<dt><code>srv</code></dt>
|
|
<dd>The <code>dns</code> element can have also 0 or more <code>srv</code>
|
|
record elements. Each <code>srv</code> record element defines a DNS SRV record
|
|
and has 2 mandatory and 5 optional attributes. The mandatory attributes
|
|
are service name and protocol (tcp, udp) and the optional attributes are
|
|
target, port, priority, weight and domain as defined in DNS server SRV
|
|
RFC (RFC 2782).
|
|
<span class="since">Since 0.9.9</span>
|
|
</dd>
|
|
</dl>
|
|
</dd>
|
|
<dt><code>ip</code></dt>
|
|
<dd>The <code>address</code> attribute defines an IPv4 address in
|
|
dotted-decimal format, or an IPv6 address in standard
|
|
colon-separated hexadecimal format, that will be configured on
|
|
the bridge
|
|
device associated with the virtual network. To the guests this
|
|
address will be their default route. For IPv4 addresses, the <code>netmask</code>
|
|
attribute defines the significant bits of the network address,
|
|
again specified in dotted-decimal format. For IPv6 addresses,
|
|
and as an alternate method for IPv4 addresses, you can specify
|
|
the significant bits of the network address with the <code>prefix</code>
|
|
attribute, which is an integer (for example, <code>netmask='255.255.255.0'</code>
|
|
could also be given as <code>prefix='24'</code>. The <code>family</code>
|
|
attribute is used to specify the type of address - 'ipv4' or 'ipv6'; if no
|
|
<code>family</code> is given, 'ipv4' is assumed. A network can have more than
|
|
one of each family of address defined, but only a single address can have a
|
|
<code>dhcp</code> or <code>tftp</code> element. <span class="since">Since 0.3.0;
|
|
IPv6, multiple addresses on a single network, <code>family</code>, and
|
|
<code>prefix</code> since 0.8.7</span>
|
|
<dl>
|
|
<dt><code>tftp</code></dt>
|
|
<dd>Immediately within
|
|
the <code>ip</code> element there is an optional <code>tftp</code>
|
|
element. The presence of this element and of its attribute
|
|
<code>root</code> enables TFTP services. The attribute specifies
|
|
the path to the root directory served via TFTP. <code>tftp</code> is not
|
|
supported for IPv6 addresses, and can only be specified on a single IPv4 address
|
|
per network.
|
|
<span class="since">Since 0.7.1</span>
|
|
</dd>
|
|
|
|
<dt><code>dhcp</code></dt>
|
|
<dd>Also within the <code>ip</code> element there is an
|
|
optional <code>dhcp</code> element. The presence of this element
|
|
enables DHCP services on the virtual network. It will further
|
|
contain one or more <code>range</code> elements. The
|
|
<code>dhcp</code> element is not supported for IPv6, and
|
|
is only supported on a single IP address per network for IPv4.
|
|
<span class="since">Since 0.3.0</span>
|
|
<dl>
|
|
<dt><code>range</code></dt>
|
|
<dd>The <code>start</code> and <code>end</code> attributes on the
|
|
<code>range</code> element specify the boundaries of a pool of
|
|
IPv4 addresses to be provided to DHCP clients. These two addresses
|
|
must lie within the scope of the network defined on the parent
|
|
<code>ip</code> element. <span class="since">Since 0.3.0</span>
|
|
</dd>
|
|
<dt><code>host</code></dt>
|
|
<dd>Within the <code>dhcp</code> element there may be zero or more
|
|
<code>host</code> elements; these specify hosts which will be given
|
|
names and predefined IP addresses by the built-in DHCP server. Any
|
|
such element must specify the MAC address of the host to be assigned
|
|
a given name (via the <code>mac</code> attribute), the IP to be
|
|
assigned to that host (via the <code>ip</code> attribute), and the
|
|
name to be given that host by the DHCP server (via the
|
|
<code>name</code> attribute). <span class="since">Since 0.4.5</span>
|
|
</dd>
|
|
<dt><code>bootp</code></dt>
|
|
<dd>The optional <code>bootp</code>
|
|
element specifies BOOTP options to be provided by the DHCP server.
|
|
Two attributes are supported: <code>file</code> is mandatory and
|
|
gives the file to be used for the boot image; <code>server</code> is
|
|
optional and gives the address of the TFTP server from which the boot
|
|
image will be fetched. <code>server</code> defaults to the same host
|
|
that runs the DHCP server, as is the case when the <code>tftp</code>
|
|
element is used. The BOOTP options currently have to be the same
|
|
for all address ranges and statically assigned addresses.<span
|
|
class="since">Since 0.7.1 (<code>server</code> since 0.7.3).</span>
|
|
</dd>
|
|
</dl>
|
|
</dd>
|
|
</dl>
|
|
</dd>
|
|
</dl>
|
|
|
|
<h2><a name="examples">Example configuration</a></h2>
|
|
|
|
<h3><a name="examplesNAT">NAT based network</a></h3>
|
|
|
|
<p>
|
|
This example is the so called "default" virtual network. It is
|
|
provided and enabled out-of-the-box for all libvirt installations.
|
|
This is a configuration that allows guest OS to get outbound
|
|
connectivity regardless of whether the host uses ethernet, wireless,
|
|
dialup, or VPN networking without requiring any specific admin
|
|
configuration. In the absence of host networking, it at least allows
|
|
guests to talk directly to each other.
|
|
</p>
|
|
|
|
<pre>
|
|
<network>
|
|
<name>default</name>
|
|
<bridge name="virbr0" />
|
|
<forward mode="nat"/>
|
|
<ip address="192.168.122.1" netmask="255.255.255.0">
|
|
<dhcp>
|
|
<range start="192.168.122.2" end="192.168.122.254" />
|
|
</dhcp>
|
|
</ip>
|
|
<ip family="ipv6" address="2001:db8:ca2:2::1" prefix="64" />
|
|
</network></pre>
|
|
|
|
<h3><a name="examplesRoute">Routed network config</a></h3>
|
|
|
|
<p>
|
|
This is a variant on the default network which routes traffic
|
|
from the virtual network to the LAN without applying any NAT.
|
|
It requires that the IP address range be pre-configured in the
|
|
routing tables of the router on the host network. This example
|
|
further specifies that guest traffic may only go out via the
|
|
<code>eth1</code> host network device.
|
|
</p>
|
|
|
|
<pre>
|
|
<network>
|
|
<name>local</name>
|
|
<bridge name="virbr1" />
|
|
<forward mode="route" dev="eth1"/>
|
|
<ip address="192.168.122.1" netmask="255.255.255.0">
|
|
<dhcp>
|
|
<range start="192.168.122.2" end="192.168.122.254" />
|
|
</dhcp>
|
|
</ip>
|
|
<ip family="ipv6" address="2001:db8:ca2:2::1" prefix="64" />
|
|
</network></pre>
|
|
|
|
<h3><a name="examplesPrivate">Isolated network config</a></h3>
|
|
|
|
<p>
|
|
This variant provides a completely isolated private network
|
|
for guests. The guests can talk to each other, and the host
|
|
OS, but cannot reach any other machines on the LAN, due to
|
|
the omission of the <code>forward</code> element in the XML
|
|
description.
|
|
</p>
|
|
|
|
<pre>
|
|
<network>
|
|
<name>private</name>
|
|
<bridge name="virbr2" />
|
|
<ip address="192.168.152.1" netmask="255.255.255.0">
|
|
<dhcp>
|
|
<range start="192.168.152.2" end="192.168.152.254" />
|
|
</dhcp>
|
|
</ip>
|
|
<ip family="ipv6" address="2001:db8:ca2:3::1" prefix="64" />
|
|
</network></pre>
|
|
|
|
<h3><a name="examplesBridge">Using an existing host bridge</a></h3>
|
|
|
|
<p>
|
|
<span class="since">Since 0.9.4</span>
|
|
This shows how to use a pre-existing host bridge "br0". The
|
|
guests will effectively be directly connected to the physical
|
|
network (i.e. their IP addresses will all be on the subnet of
|
|
the physical network, and there will be no restrictions on
|
|
inbound or outbound connections).
|
|
</p>
|
|
|
|
<pre>
|
|
<network>
|
|
<name>host-bridge</name>
|
|
<forward mode="bridge"/>
|
|
<bridge name="br0"/>
|
|
</network></pre>
|
|
|
|
<h3><a name="examplesDirect">Using a macvtap "direct" connection</a></h3>
|
|
|
|
<p>
|
|
<span class="since">Since 0.9.4, QEMU and KVM only, requires
|
|
Linux kernel 2.6.34 or newer</span>
|
|
This shows how to use macvtap to connect to the physical network
|
|
directly through one of a group of physical devices (without
|
|
using a host bridge device). As with the host bridge network,
|
|
the guests will effectively be directly connected to the
|
|
physical network so their IP addresses will all be on the subnet
|
|
of the physical network, and there will be no restrictions on
|
|
inbound or outbound connections. Note that, due to a limitation
|
|
in the implementation of macvtap, these connections do not allow
|
|
communication directly between the host and the guests - if you
|
|
require this you will either need the attached physical switch
|
|
to be operating in a mirroring mode (so that all traffic coming
|
|
to the switch is reflected back to the host's interface), or
|
|
provide alternate means for this communication (e.g. a second
|
|
interface on each guest that is connected to an isolated
|
|
network). The other forward modes that use macvtap (private,
|
|
vepa, and passthrough) would be used in a similar fashion.
|
|
</p>
|
|
|
|
<pre>
|
|
<network>
|
|
<name>direct-macvtap</name>
|
|
<forward mode="bridge">
|
|
<interface dev="eth20"/>
|
|
<interface dev="eth21"/>
|
|
<interface dev="eth22"/>
|
|
<interface dev="eth23"/>
|
|
<interface dev="eth24"/>
|
|
</forward>
|
|
</network></pre>
|
|
|
|
</body>
|
|
</html>
|