mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-23 06:05:27 +00:00
303133ee49
The sub-elements of <ip> had been placed at the same level of indentation as ip itself, implying that they were really elements of <network>. Within that, sub-elements of ip/dhcp were also at that same level. These have been double-indented. At the same time, I realized that the documentation for the new <dns> element had been placed right in the middle of the description of the sub-elements of <ip>. I moved it up out of the way.
318 lines
15 KiB
HTML
318 lines
15 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 attributes.
|
|
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"/>
|
|
<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.
|
|
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.
|
|
<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. the <code>mode</code> attribute determines the method of
|
|
forwarding; possible selections are 'nat' and 'route'. If mode
|
|
is not specified, NAT forwarding will be used for
|
|
connectivity. If a network has any IPv6 addresses defined,
|
|
even if <code>mode</code> is given as 'nat', the IPv6 traffic
|
|
will be forwarded using routing, since IPv6 has no concept of NAT.
|
|
Firewall rules will allow forwarding 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. If the <code>mode</code> attribute is set to <code>route</code>
|
|
then the traffic will not have NAT applied. This presumes that the
|
|
local LAN router has suitable routing table entries to return traffic
|
|
to this host. <span class="since">Since 0.3.0; 'mode' attribute since
|
|
0.4.2</span></dd>
|
|
</dl>
|
|
|
|
<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.
|
|
</p>
|
|
|
|
<pre>
|
|
...
|
|
<mac address='00:16:3E:5D:C7:9E'/>
|
|
<dns>
|
|
<txt name="example" value="example value" />
|
|
</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:8794: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>
|
|
</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:8794: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:8794: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:8794:ca2:3::1" prefix="64" />
|
|
</network></pre>
|
|
|
|
</body>
|
|
</html>
|