diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 552b5364f8..6c4096713a 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -5542,7 +5542,7 @@ Quality of service
This part of interface XML provides setting quality of service. Incoming and
outgoing traffic can be shaped independently. The ``bandwidth`` element and its
-child elements are described in the `QoS
- This page provides an introduction to the network XML format. For
- background information on the concepts referred to here, consult the
- relevant wiki page.
-
- The root element required for all virtual networks is
- named
- The first elements provide basic metadata about the virtual
- network.
-
- The next set of elements control how a virtual network is
- provided connectivity to the physical LAN (if at all).
-
- The
- The optional
- If the optional Since 1.0.3 it is possible to
- specify a public IPv4 address and port range to be used for
- the NAT by using the
- A single IPv4 address can be set by setting
-
- The port range to be used for the
- Since 6.5.0 it is possible to
- enable NAT with IPv6 networking. As noted above, IPv6
- has historically done plain forwarding and thus to avoid
- breaking historical compatibility, IPv6 NAT must be
- explicitly requested.
-
- To force use of a particular type of device assignment,
- a <forward type='hostdev'> interface can have an
- optional Note that this "intelligent passthrough" of network
- devices is very similar to the functionality of a
- standard
- since 0.10.0,
-
- Additionally, since 0.9.10, libvirt
- allows a shorthand for specifying all virtual interfaces
- associated with a single physical function, by using
- the 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.
- since 0.10.0 When using forward
- mode 'hostdev', the interface pool is specified with a list
- of
- The
- The
- As a subelement of a domain's
- As a subelement of a
-
- Incoming and outgoing traffic can be shaped independently. The
-
- Attributes
- If (and only if) the network connection used by the guest
- supports VLAN tagging transparent to the guest, an
- optional
- For network connections using Open vSwitch it is also possible
- to configure 'native-tagged' and 'native-untagged' VLAN modes
- Since 1.1.0. This is done with the
- optional
-
- Since 6.1.0. The
- Since 0.9.4
- 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.
- Since 0.9.4 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
- attributes and subelements associated with it. The currently supported
- subelements are
- portgroups also support the optional
- parameter
- Static route definitions are used to provide routing information
- to the virtualization host for networks which are not directly
- reachable from the virtualization host, but *are* reachable from
- a guest domain that is itself reachable from the
- host since 1.0.6.
-
- As shown in this
- example, it is possible to define a virtual network
- interface with no IPv4 or IPv6 addresses. Such networks are
- useful to provide host connectivity to networks which are only
- reachable via a guest. A guest with connectivity both to the
- guest-only network and to another network that is directly
- reachable from the host can act as a gateway between the
- networks. A static route added to the "host-visible" network
- definition provides the routing information so that IP packets
- can be sent from the virtualization host to guests on the hidden
- network.
-
- Here is a fragment of a definition which shows the static
- route specification as well as the IPv4 and IPv6 definitions
- for network addresses which are referred to in the
-
- 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
- The dns element can have an optional
- The dns element
- can have an optional
- Optionally,
- A special XML namespace is available for passing options
- directly to the underlying dnsmasq configuration
- file since 5.6.0. Usage of XML
- namespaces comes with no support guarantees, so use at your own
- risk.
-
- This example XML will pass the option strings Network XML format
-
-
-
-
- Element and attribute overview
-
- network
and has no configurable attributes
- (although since 0.10.0 there is one
- optional read-only attribute - when examining the live
- configuration of a network, the
- attribute connections
, if present, specifies the
- number of guest interfaces currently connected via this
- network). The network XML format is
- available since 0.3.0
- General metadata
-
-
-<network ipv6='yes' trustGuestRxFilters='no'>
- <name>default</name>
- <uuid>3e3fce45-4f53-4fa7-bb32-11f34168b82b</uuid>
- <metadata>
- <app1:foo xmlns:app1="http://app1.org/app1/">..</app1:foo>
- <app2:bar xmlns:app2="http://app1.org/app2/">..</app2:bar>
- </metadata>
- ...
-
-
-
-
- name
name
element provides
- a short name for the virtual network. This name should
- consist only of alphanumeric 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. Since 0.3.0uuid
uuid
element provides
- a globally unique identifier for the virtual network.
- The format must be RFC 4122 compliant, eg 3e3fce45-4f53-4fa7-bb32-11f34168b82b
.
- If omitted when defining/creating a new network, a random
- UUID is generated. Since 0.3.0metadata
node can be used by applications to
- store custom metadata in the form of XML nodes/trees. Applications
- must use custom namespaces on their XML nodes/trees, with only
- one top-level element per namespace (if the application needs
- structure, they should have sub-elements to their namespace
- element). Since 2.1.0ipv6
yes
, the optional parameter
- ipv6
enables
- a network definition with no IPv6 gateway addresses specified
- to have guest-to-guest communications. For further information,
- see the example below for the example with no gateway addresses.
- Since 1.0.1trustGuestRxFilters
trustGuestRxFilters
can
- be used to set that attribute of the same name for each domain
- interface connected to this network (since
- 1.2.10). See
- the Network
- interfaces section of the domain XML documentation for
- more details. Note that an explicit setting of this attribute
- in a portgroup or the individual domain interface will
- override the setting in the network.Connectivity
-
-
-...
-<bridge name="virbr0" stp="on" delay="5" macTableManager="libvirt"/>
-<mtu size="9000"/>
-<domain name="example.com" localOnly="no"/>
-<forward mode="nat" dev="eth0"/>
-...
-
-
-
- bridge
name
attribute on the bridge
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. When defining
- a new network with a <forward>
mode of
-
- "nat", "route", or "open" (or an isolated network with
- no <forward>
element), libvirt will
- automatically generate a unique name for the bridge device if
- none is given, and this name will be permanently stored in the
- network configuration so that that the same name will be used
- every time the network is started. For these types of networks
- (nat, route, open, and isolated), a bridge name beginning with the
- prefix "virbr" is recommended (and that is what is
- auto-generated), but not enforced.
- Attribute stp
specifies if Spanning Tree Protocol
- is 'on' or 'off' (default is
- 'on'). Attribute delay
sets the bridge's forward
- delay value in seconds (default is 0).
- Since 0.3.0
-
- macTableManager
attribute of the bridge
- element is used to tell libvirt how the bridge's MAC address
- table (used to determine the correct egress port for packets
- based on destination MAC address) will be managed. In the
- default kernel
setting, the kernel
- automatically adds and removes entries, typically using
- learning, flooding, and promiscuous mode on the bridge's
- ports in order to determine the proper egress port for
- packets. When macTableManager
is set
- to libvirt
, libvirt disables kernel management
- of the MAC table (in the case of the Linux host bridge, this
- means enabling vlan_filtering on the bridge, and disabling
- learning and unicast_filter for all bridge ports), and
- explicitly adds/removes entries to the table according to
- the MAC addresses in the domain interface configurations.
- Allowing libvirt to manage the MAC table can improve
- performance - with a Linux host bridge, for example, turning
- off learning and unicast_flood on ports has its own
- performance advantage, and can also lead to an additional
- boost by permitting the kernel to automatically turn off
- promiscuous mode on some ports of the bridge (in particular,
- the port attaching the bridge to the physical
- network). However, it can also cause some networking setups
- to stop working (e.g. vlan tagging, multicast,
- guest-initiated changes to MAC address) and is not supported
- by older kernels.
- Since 1.2.11, requires kernel 3.17 or
- newer
- zone
attribute of
- the bridge
element is used to specify
- the firewalld
- zone for the bridge of a network with forward
- mode of "nat", "route", "open", or one with
- no forward
specified. By default, the bridges
- of all virtual networks with these forward modes are placed
- in the firewalld zone named "libvirt", which permits
- incoming DNS, DHCP, TFTP, and SSH to the host from guests on
- the network. This behavior can be changed either by
- modifying the libvirt zone (using firewalld management
- tools), or by placing the network in a different zone (which
- will also be managed using firewalld tools).
- Since 5.1.0
- mtu
size
attribute of the mtu>
- element specifies the Maximum Transmission Unit (MTU) for the
- network. Since 3.1.0. In the case
- of a libvirt-managed network (one with forward mode
- of nat
, route
, open
, or
- no forward
element (i.e. an isolated network),
- this will be the MTU assigned to the bridge device when
- libvirt creates it, and thereafter also assigned to all tap
- devices created to connect guest interfaces. Network types not
- specifically mentioned here don't support having an MTU set in
- the libvirt network config. If mtu size is unspecified, the
- default setting for the type of device being used is assumed
- (usually 1500).
- domain
name
attribute on the domain
- element defines the DNS domain of the DHCP server. This
- element is optional, and is only used for those networks with
- a <forward>
mode of "nat" or "route" (or an
- isolated network with no <forward>
- element). Since 0.4.5
-
- localOnly
attribute on the
- domain
element is "yes", then DNS requests under
- this domain will only be resolved by the virtual network's own
- DNS server - they will not be forwarded to the host's upstream
- DNS server. If localOnly
is "no", and by
- default, unresolved requests will be forwarded.
- Since 1.2.12
- forward
forward
element indicates that
- the virtual network is to be connected to the physical
- LAN.Since 0.3.0.
- The mode
attribute determines the method of
- forwarding. If there is no forward
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 mode
(if there is a forward
- element but mode is not specified, mode='nat'
is
- assumed):
-
-
- As mentioned above, a nat
dev
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.Since
- 0.4.2
-
- <nat>
subelement.
- Note that all addresses from the range are used, not just those
- that are in use on the host.
- The address range is set with the <address>
- subelements and start
and stop
- attributes:
-
-...
- <forward mode='nat'>
- <nat>
- <address start='1.2.3.4' end='1.2.3.10'/>
- </nat>
- </forward>
-...
- start
and end
attributes to
- the same value.
- <nat>
can
- be set via the subelement <port>
:
-
-...
- <forward mode='nat'>
- <nat>
- <port start='500' end='1000'/>
- </nat>
- </forward>
-...
-
-
-...
- <forward mode='nat'>
- <nat ipv6='yes'/>
- </forward>
-...
- route
dev
- 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 nwfilter rules
- on the guest's interfaces.)
- Since 0.4.2
- open
dev
attribute
- cannot be set (because the forward dev is enforced with
- firewall rules, and the purpose of forward='open' is to
- have a forwarding mode where libvirt doesn't add any
- firewall rules). This mode presumes that the local LAN
- router has suitable routing table entries to return
- traffic to this host, and that some other management
- system has been used to put in place any necessary
- firewall rules. Although no firewall rules will be added
- for the network, it is of course still possible to add
- restrictions for specific guests using
- nwfilter rules on the
- guests' interfaces.)
- Since 2.2.0
- bridge
<bridge name='xyz'/>
element has been
- specified, Since 0.9.4), 2) an
- existing Open vSwitch bridge that was configured outside of
- libvirt (if both a <bridge name='xyz'/>
- element and a <virtualport
- type='openvswitch'/>
have been
- specified Since 0.10.0) 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 <interface>
- subelements, Since 0.9.4)
- (see Direct
- attachment to physical interface for descriptions of
- the various macvtap modes). libvirt doesn't attempt to
- manage the bridge interface at all, thus
- the <bridge>
element's stp
- and delay
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.Since 0.9.4
- private
<interface>
subelements
- of the <forward>
element; when using
- 802.1Qbh mode (as indicated by
- the <virtualport>
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).Since
- 0.9.4
- vepa
<interface>
subelements of
- the <forward>
element; multiple guest
- interfaces can share each physical interface (libvirt will
- attempt to balance usage between all available
- interfaces).Since 0.9.4
- passthrough
<interface>
subelements of
- the <forward>
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).Since 0.9.4
- hostdev
<virtualport>
- 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 <hostdev>
device
- definition. Since 0.10.0
-
- driver
sub-element with
- a name
attribute set to either "vfio" (VFIO
- is a new method of device assignment that is compatible
- with UEFI Secure Boot) or "kvm" (the legacy device
- assignment handled directly by the KVM kernel module)
- Since 1.0.5 (QEMU and KVM only,
- requires kernel 3.6 or newer). When specified,
- device assignment will fail if the requested method of
- device assignment isn't available on the host. When not
- specified, the default is "vfio" on systems where the
- VFIO driver is available and loaded, and "kvm" on older
- systems, or those where the VFIO driver hasn't been
- loaded Since 1.1.3 (prior to
- that the default was always "kvm").
- <hostdev>
device, the
- difference being that this method allows specifying a MAC
- address, vlan tag, and <virtualport>
- 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
- <hostdev>
device definition in the
- domain's configuration to assign the device to the guest
- instead of defining an <interface
- type='network'>
pointing to a network
- with <forward mode='hostdev'/>
.
- <forward>
element can
- have multiple <interface>
subelements, each
- one giving the name of a physical interface that can be used
- for this network Since 0.9.4:
-
-...
- <forward mode='passthrough'>
- <interface dev='eth10'/>
- <interface dev='eth11'/>
- <interface dev='eth12'/>
- <interface dev='eth13'/>
- <interface dev='eth14'/>
- </forward>
-...
-
- <interface>
also has an optional read-only
- attribute - when examining the live configuration of a
- network, the attribute connections
, if present,
- specifies the number of guest interfaces currently connected
- via this physical interface.
- <pf>
subelement to call out the
- corresponding physical interface associated with multiple
- virtual interfaces:
-
-...
- <forward mode='passthrough'>
- <pf dev='eth0'/>
- </forward>
-...
-
-
- <address>
elements, each of which has
- <type>
(must always be 'pci'
),
- <domain>
, <bus>
,
- <slot>
and <function>
- attributes.
-
-...
- <forward mode='hostdev' managed='yes'>
- <driver name='vfio'/>
- <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>
-...
-
-
- Alternatively the interface pool can also be defined using a
- single physical function <pf>
subelement to
- call out the corresponding physical interface associated with
- multiple virtual interfaces (similar to passthrough mode):
-
-
-...
- <forward mode='hostdev' managed='yes'>
- <pf dev='eth0'/>
- </forward>
-...
-
-
- Quality of service
-
-
-...
- <forward mode='nat' dev='eth0'/>
- <bandwidth>
- <inbound average='1000' peak='5000' burst='5120'/>
- <outbound average='128' peak='256' burst='256'/>
- </bandwidth>
-...
-
- <bandwidth>
element allows setting
- quality of service for a particular network
- (since 0.9.4). Setting
- bandwidth
for a network is supported only
- for networks with a <forward>
mode
- of route
, nat
, bridge
,
- or no mode at all (i.e. an "isolated" network). Setting
- bandwidth
is not supported for forward modes
- passthrough
, private
,
- or hostdev
. Attempts to do this will lead to
- a failure to define the network or to create a transient network.
- <bandwidth>
element can only be a
- subelement of a domain's <interface>
, a
- subelement of a <network>
, or a subelement of
- a <portgroup>
in a <network>
.
- <interface>
,
- the bandwidth only applies to that one interface of the domain.
- As a subelement of a <network>
, the bandwidth
- is a total aggregate bandwidth to/from all guest interfaces attached
- to that network, not to each guest interface individually.
- If a domain's <interface>
has
- <bandwidth>
element values higher
- than the aggregate for the entire network, then the aggregate
- bandwidth for the <network>
takes precedence.
- This is because the two choke points are independent of each other
- where the domain's <interface>
bandwidth control
- is applied on the interface's tap device, while the
- <network>
bandwidth control is applied on the
- interface part of the bridge device created for that network.
- <portgroup>
in a <network>
,
- if a domain's <interface>
has a
- portgroup
attribute in its
- <source>
element and if the
- <interface>
- itself has no <bandwidth>
element, then the
- <bandwidth>
element of the portgroup will be
- applied individually to each guest interface defined to be a
- member of that portgroup. Any <bandwidth>
- element in the domain's <interface>
definition
- will override the setting in the portgroup
- (since 1.0.1).
- bandwidth
element can have at most one
- inbound
and at most one outbound
- child element. Leaving either of these children elements out
- results in no QoS applied for that traffic direction. So,
- when you want to shape only incoming traffic, use
- inbound
only, and vice versa. Each of these
- elements have one mandatory attribute - average
(or
- floor
as described below). The attributes are as follows,
- where accepted values for each attribute is an integer number.
-
-
-
- average
peak
outbound
element is ignored (as Linux ingress
- filters don't know it yet).
- burst
peak
speed.
- floor
inbound
- element. This attribute guarantees minimal throughput for
- shaped interfaces. This, however, requires that all traffic
- goes through one point where QoS decisions can take place, hence
- why this attribute works only for virtual networks for now
- (that is <interface type='network'/>
with a
- forward type of route, nat, open or no forward at all). Moreover, the
- virtual network the interface is connected to is required to have
- at least inbound QoS set (average
at least). If
- using the floor
attribute users don't need to specify
- average
. However, peak
and
- burst
attributes still require average
.
- Currently, the Linux kernel doesn't allow ingress qdiscs to have
- any classes therefore floor
can be applied only
- on inbound
and not outbound
.
- average
, peak
, and
- burst
are available
- since 0.9.4, while the
- floor
attribute is available
- since 1.0.1.
- Setting VLAN tag (on supported network types only)
-
-
-<network>
- <name>ovs-net</name>
- <forward mode='bridge'/>
- <bridge name='ovsbr0'/>
- <virtualport type='openvswitch'>
- <parameters interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/>
- </virtualport>
- <vlan trunk='yes'>
- <tag id='42' nativeMode='untagged'/>
- <tag id='47'/>
- </vlan>
- <portgroup name='dontpanic'>
- <vlan>
- <tag id='42'/>
- </vlan>
- </portgroup>
-</network>
-
-
- <vlan>
element can specify one or
- more VLAN tags to apply to the guest's network
- traffic Since 0.10.0. Network
- connections that support guest-transparent VLAN tagging include
- 1) type='bridge' interfaces connected to an Open vSwitch bridge
- Since 0.10.0, 2) SRIOV Virtual
- Functions (VF) used via type='hostdev' (direct device
- assignment) Since 0.10.0, and 3)
- SRIOV VFs used via type='direct' with mode='passthrough'
- (macvtap "passthru" mode) Since
- 1.3.5. All other connection types, including standard
- linux bridges and libvirt's own virtual networks, do not
- support it. 802.1Qbh (vn-link) and 802.1Qbg (VEPA) switches
- provide their own way (outside of libvirt) to tag guest traffic
- onto a specific VLAN. Each tag is given in a
- separate <tag>
subelement
- of <vlan>
(for example: <tag
- id='42'/>
). For VLAN trunking of multiple tags (which
- is supported only on Open vSwitch connections),
- multiple <tag>
subelements can be specified,
- which implies that the user wants to do VLAN trunking on the
- interface for all the specified tags. In the case that VLAN
- trunking of a single tag is desired, the optional
- attribute trunk='yes'
can be added to the toplevel
- <vlan>
element to differentiate trunking of a
- single tag from normal tagging.
- nativeMode
attribute on
- the <tag>
subelement: nativeMode
- may be set to 'tagged' or 'untagged'. The id
- attribute of the <tag>
subelement
- containing nativeMode
sets which VLAN is considered
- to be the "native" VLAN for this interface, and
- the nativeMode
attribute determines whether or not
- traffic for that VLAN will be tagged.
- <vlan>
elements can also be specified in
- a <portgroup>
element, as well as directly in
- a domain's <interface>
element. In the case
- that a vlan tag is specified in multiple locations, the setting
- in <interface>
takes precedence, followed by
- the setting in the <portgroup>
selected by
- the interface config. The <vlan>
- in <network>
will be selected only if none is
- given in <portgroup>
- or <interface>
.
- Isolating ports from one another
-
-
-<network>
- <name>isolated-ports</name>
- <forward mode='bridge'/>
- <bridge name='br0'/>
- <port isolated='yes'/>
-</network>
-
-
- port
- element property isolated
, when set
- to yes
(default setting is no
) is used
- to isolate the network traffic of each guest on the network from
- all other guests connected to the network; it does not have an
- effect on communication between the guests and the host, or
- between the guests and destinations beyond this network. This
- setting is only supported for networks that use a Linux host
- bridge to connect guest interfaces via a standard tap device
- (i.e. those with a forward mode of nat, route, open, bridge, or
- no forward mode).
- Portgroups
-
-
-...
- <forward mode='private'/>
- <interface dev="eth20"/>
- <interface dev="eth21"/>
- <interface dev="eth22"/>
- <interface dev="eth23"/>
- <interface dev="eth24"/>
- </forward>
- <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>
- <portgroup name='sales' trustGuestRxFilters='no'>
- <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>
-...
-
- <bandwidth>
- (described here)
- and <virtualport>
- (documented here).
- If a domain interface definition specifies a portgroup (by
- adding a portgroup
attribute to
- the <source>
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 default='yes'
, 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 <bandwidth>
-
- specified directly in the domain XML will take precedence over
- any setting in the chosen portgroup. if
- a <virtualport>
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.
- trustGuestRxFilters
which can be used to
- set that attribute of the same name for each domain interface
- using this portgroup (since
- 1.2.10). See
- the Network
- interfaces section of the domain XML documentation for more
- details. Note that an explicit setting of this attribute in the
- portgroup overrides the network-wide setting, and an explicit
- setting in the individual domain interface will override the
- setting in the portgroup.
- Static Routes
- gateway
gateway address specifications. Note
- that the third static route specification includes the
- metric
attribute specification with a value of 2.
- This particular route would *not* be preferred if there was
- another existing rout on the system with the same address and
- prefix but with a lower value for the metric. If there is a
- route in the host system configuration that should be overridden
- by a route in a virtual network whenever the virtual network is
- running, the configuration for the system-defined route should
- be modified to have a higher metric, and the route on the
- virtual network given a lower metric (for example, the default
- metric of "1").
-
-...
- <ip address="192.168.122.1" netmask="255.255.255.0">
- <dhcp>
- <range start="192.168.122.128" end="192.168.122.254"/>
- </dhcp>
- </ip>
- <route address="192.168.222.0" prefix="24" gateway="192.168.122.2"/>
- <ip family="ipv6" address="2001:db8:ca2:2::1" prefix="64"/>
- <route family="ipv6" address="2001:db8:ca2:3::" prefix="64" gateway="2001:db8:ca2:2::2"/>
- <route family="ipv6" address="2001:db9:4:1::" prefix="64" gateway="2001:db8:ca2:2::3" metric='2'/>
-...
-
-
- Addressing
-
- forward
element specified), and for those with
- a forward mode of 'route' or 'nat'.
-
-...
-<mac address='00:16:3E:5D:C7:9E'/>
-<domain name="example.com"/>
-<dns>
- <txt name="example" value="example value"/>
- <forwarder addr="8.8.8.8"/>
- <forwarder domain='example.com' addr="8.8.4.4"/>
- <forwarder domain='www.example.com'/>
- <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" localPtr="yes">
- <dhcp>
- <range start="192.168.122.100" end="192.168.122.254">
- <lease expiry='1' unit='hours'/>
- </range>
- <host mac="00:16:3e:77:e2:ed" name="foo.example.com" ip="192.168.122.10">
- <lease expiry='30' unit='minutes'/>
- </host>
- <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" localPtr="yes"/>
-<route family="ipv6" address="2001:db9:ca1:1::" prefix="64" gateway="2001:db8:ca2:2::2"/>
-
-
-
-
-
- mac
address
attribute defines a MAC
- (hardware) address formatted as 6 groups of 2-digit
- hexadecimal numbers, the groups separated by colons
- (eg, "52:54:00:1C:DA:2F"
). 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. Since 0.8.8
- dns
enable
- attribute Since 2.2.0.
- If enable
is "no", then no DNS server will be
- setup by libvirt for this network (and any other
- configuration in <dns>
will be ignored).
- If enable
is "yes" or unspecified (including
- the complete absence of any <dns>
- element) then a DNS server will be setup by libvirt to
- listen on all IP addresses specified in the network's
- configuration.
- forwardPlainNames
- attribute Since 1.1.2.
- If forwardPlainNames
is "no", then DNS resolution
- requests for names that are not qualified with a domain
- (i.e. names with no "." character) will not be forwarded to
- the host's upstream DNS server - they will only be resolved if
- they are known locally within the virtual network's own DNS
- server. If forwardPlainNames
is "yes",
- unqualified names will be forwarded to the upstream DNS
- server if they can't be resolved by the virtual network's own
- DNS server.
- <dns>
are:
-
-
- forwarder
<forwarder>
elements. Each
- forwarder element defines an alternate DNS server to use
- for some, or all, DNS requests sent to this network's DNS
- server. There are two attributes - domain
,
- and addr
; at least one of these must be
- specified in any <forwarder>
- element. If both domain
and addr
- are specified, then all requests that match the given
- domain will be forwarded to the DNS server at addr. If
- only domain
is specified, then all matching
- domains will be resolved locally (or via the host's
- standard DNS forwarding if they can't be resolved
- locally). If an addr
is specified by itself,
- then all DNS requests to the network's DNS server will be
- forwarded to the DNS server at that address with no
- exceptions. addr
Since
- 1.1.3, domain
Since
- 2.2.0.
- txt
dns
element can have 0 or more txt
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. Since 0.9.3
- host
host
element within dns
is the
- definition of DNS hosts to be passed to the DNS service. The IP
- address is identified by the ip
attribute and the names
- for that IP address are identified in the hostname
- sub-elements of the host
element.
- Since 0.9.3
-
-
- srv
dns
element can have also 0 or more srv
- record elements. Each srv
record element defines a DNS SRV record
- and has 2 mandatory and 5 optional attributes. The mandatory attributes
- are service
and protocol
(tcp, udp)
- and the optional attributes are target
,
- port
, priority
, weight
and
- domain
as defined in DNS server SRV RFC (RFC 2782).
- Since 0.9.9
- ip
address
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 IPv4 address
- will be their IPv4 default route. For IPv6, the default route is
- established via Router Advertisement. For IPv4 addresses, the
- netmask
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, the
- significant bits of the network address can be specified with the
- prefix
attribute, which is an integer (for example,
- netmask='255.255.255.0'
could also be given as
- prefix='24'
). The family
attribute is used
- to specify the type of address - ipv4
or
- ipv6
; if no family
is given,
- ipv4
is assumed. More than one address of each family can
- be defined for a network. The optional localPtr
attribute
- (since 3.0.0) configures the DNS server to
- not forward any reverse DNS requests for IP addresses from the network
- configured by the address
and
- netmask
/prefix
attributes. For some unusual
- network prefixes (not divisible by 8 for IPv4 or not divisible by 4 for
- IPv6) libvirt may be unable to compute the PTR domain automatically.
- The ip
element is supported since
- 0.3.0. IPv6, multiple addresses on a single network,
- family
, and prefix
are supported
- since 0.8.7. The ip
element may
- contain the following elements:
-
-
-
- tftp
tftp
element and its mandatory
- root
attribute enable TFTP services. The attribute
- specifies the path to the root directory served via TFTP. The
- tftp
element is not supported for IPv6 addresses,
- and can only be specified on a single IPv4 address per network.
- Since 0.7.1
- dhcp
dhcp
element is supported for
- both IPv4 (since 0.3.0) and IPv6
- (since 1.0.1), but only for one IP
- address of each type per network. The following sub-elements are
- supported:
-
-
-
- range
start
and end
attributes on the
- range
element specify the boundaries of a pool of
- addresses to be provided to DHCP clients. These two addresses
- must lie within the scope of the network defined on the parent
- ip
element. There may be zero or more
- range
elements specified.
- Since 0.3.0
- host
dhcp
element there may be zero or
- more host
elements. These specify hosts which will
- be given names and predefined IP addresses by the built-in DHCP
- server. Any IPv4 host
element must specify the MAC
- address of the host to be assigned a given name (via the
- mac
attribute), the IP to be assigned to that host
- (via the ip
attribute), and the name itself (the
- name
attribute). The IPv6 host
- element differs slightly from that for IPv4: there is no
- mac
attribute since a MAC address has no defined
- meaning in IPv6. Instead, the name
attribute is
- used to identify the host to be assigned the IPv6 address. For
- DHCPv6, the name is the plain name of the client host sent by the
- client to the server. Note that this method of assigning a
- specific IP address can also be used for IPv4 instead of the
- mac
attribute.
- Since 0.4.5
- bootp
bootp
element specifies BOOTP
- options to be provided by the DHCP server for IPv4 only. Two
- attributes are supported: file
is mandatory and
- gives the file to be used for the boot image;
- server
is optional and gives the address of the
- TFTP server from which the boot image will be fetched.
- server
defaults to the same host that runs the
- DHCP server, as is the case when the tftp
element
- is used. The BOOTP options currently have to be the same for
- all address ranges and statically assigned addresses. Since 0.7.1 (server
- since 0.7.3)
- range
and host
elements can
- have lease
child element which specifies the lease
- time through it's attributes expiry
and
- unit
(which accepts seconds
,
- minutes
and hours
and defaults to
- minutes
if omitted). The minimal lease time is 2
- minutes, except when setting an infinite lease time
- (expiry='0'
).
- Since 6.3.0
- Network namespaces
-
- foo=bar
and
- cname=*.foo.example.com,master.example.com
directly to the
- underlying dnsmasq instance.
-
-<network xmlns:dnsmasq='http://libvirt.org/schemas/network/dnsmasq/1.0'>
- ...
- <dnsmasq:options>
- <dnsmasq:option value="foo=bar"/>
- <dnsmasq:option value="cname=*.foo.example.com,master.example.com"/>
- </dnsmasq:options>
-</network>
-
- 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. -
- --<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>- - -
- Below is a variation of the above example which adds an IPv6 - dhcp range definition. -
- --<network> - <name>default6</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"> - <dhcp> - <range start="2001:db8:ca2:2:1::10" end="2001:db8:ca2:2:1::ff"/> - </dhcp> - </ip> -</network>- -
- Below is a variation for also providing IPv6 NAT. This can be - especially useful when using multiple interfaces where some, - such as WiFi cards, can not be bridged (usually on a laptop), - making it difficult to provide end-to-end IPv6 routing. -
- --<network> - <name>default6</name> - <bridge name="virbr0"/> - <forward mode="nat"> - <nat ipv6='yes'> - <port start='1024' end='65535'/> - </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="fdXX:XXXX:XXXX:NNNN:: prefix="64"/> -</network>- -
IPv6 NAT addressing has some caveats over the more straight - forward IPv4 case. - RFC 4193 - defines the address range fd00::/8 for /48 IPv6 - private networks. It should be concatenated with a random 40-bit - string (i.e. 10 random hexadecimal digits replacing the X - values above, RFC 4193 provides - an algorithm - if you do not have a source of sufficient randomness). This - leaves 0 through ffff for subnets (N - above) which you can use at will.
- -Many operating systems will not consider these addresses as - preferential to IPv4, due to some practical history of these - addresses being present but unroutable and causing networking - issues. On many Linux distributions, you may need to - override /etc/gai.conf with values - from RFC 3484 - to have your IPv6 NAT network correctly preferenced over IPv4.
- -
- 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
- eth1
host network device.
-
-<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>- -
- Below is another IPv6 variation. Instead of a dhcp range being - specified, this example has a couple of IPv6 host definitions. - Note that most of the dhcp host definitions use an "id" (client - id or DUID) since this has proven to be a more reliable way - of specifying the interface and its association with an IPv6 - address. The first is a DUID-LLT, the second a DUID-LL, and - the third a DUID-UUID. Since 1.0.3 -
- --<network> - <name>local6</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"> - <dhcp> - <host name="paul" ip="2001:db8:ca2:2:3::1"/> - <host id="0:1:0:1:18:aa:62:fe:0:16:3e:44:55:66" ip="2001:db8:ca2:2:3::2"/> - <host id="0:3:0:1:0:16:3e:11:22:33" name="ralph" ip="2001:db8:ca2:2:3::3"/> - <host id="0:4:7e:7d:f0:7d:a8:bc:c5:d2:13:32:11:ed:16:ea:84:63" - name="badbob" ip="2001:db8:ca2:2:3::4"/> - </dhcp> - </ip> -</network>- -
- Below is yet another IPv6 variation. This variation has only - IPv6 defined with DHCPv6 on the primary IPv6 network. A static - link if defined for a second IPv6 network which will not be - directly visible on the bridge interface but there will be a - static route defined for this network via the specified - gateway. Note that the gateway address must be directly - reachable via (on the same subnet as) one of the <ip> - addresses defined for this <network>. - Since 1.0.6 -
- --<network> - <name>net7</name> - <bridge name="virbr7"/> - <forward mode="route"/> - <ip family="ipv6" address="2001:db8:ca2:7::1" prefix="64"> - <dhcp> - <range start="2001:db8:ca2:7::100" end="2001:db8:ca2::1ff"/> - <host id="0:4:7e:7d:f0:7d:a8:bc:c5:d2:13:32:11:ed:16:ea:84:63" - name="lucas" ip="2001:db8:ca2:2:3::4"/> - </dhcp> - </ip> - <route family="ipv6" address="2001:db8:ca2:8::" prefix="64" gateway="2001:db8:ca2:7::4"/> -</network>- -
- 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 forward
element in the XML
- description.
-
-<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>- -
- This variation of an isolated network defines only IPv6. - Note that most of the dhcp host definitions use an "id" (client - id or DUID) since this has proven to be a more reliable way - of specifying the interface and its association with an IPv6 - address. The first is a DUID-LLT, the second a DUID-LL, and - the third a DUID-UUID. Since 1.0.3 -
- --<network> - <name>sixnet</name> - <bridge name="virbr6"/> - <ip family="ipv6" address="2001:db8:ca2:6::1" prefix="64"> - <dhcp> - <host name="peter" ip="2001:db8:ca2:6:6::1"/> - <host id="0:1:0:1:18:aa:62:fe:0:16:3e:44:55:66" ip="2001:db8:ca2:6:6::2"/> - <host id="0:3:0:1:0:16:3e:11:22:33" name="dariusz" ip="2001:db8:ca2:6:6::3"/> - <host id="0:4:7e:7d:f0:7d:a8:bc:c5:d2:13:32:11:ed:16:ea:84:63" - name="anita" ip="2001:db8:ca2:6:6::4"/> - </dhcp> - </ip> -</network>- -
- Since 0.9.4 - 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). -
- --<network> - <name>host-bridge</name> - <forward mode="bridge"/> - <bridge name="br0"/> -</network>- -
- Since 0.9.4, QEMU and KVM only, requires - Linux kernel 2.6.34 or newer - 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. -
- --<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>- -
- A valid network definition can contain no IPv4 or IPv6 addresses. Such a definition - can be used for a "very private" or "very isolated" network since it will not be - possible to communicate with the virtualization host via this network. However, - this virtual network interface can be used for communication between virtual guest - systems. This works for IPv4 and (Since 1.0.1) IPv6. - However, the new ipv6='yes' must be added for guest-to-guest IPv6 - communication. -
- --<network ipv6='yes'> - <name>nogw</name> - <uuid>7a3b7497-1ec7-8aef-6d5c-38dff9109e93</uuid> - <bridge name="virbr2" stp="on" delay="0"/> - <mac address='00:16:3E:5D:C7:9E'/> -</network>- - - diff --git a/docs/formatnetwork.rst b/docs/formatnetwork.rst new file mode 100644 index 0000000000..d6550f6df9 --- /dev/null +++ b/docs/formatnetwork.rst @@ -0,0 +1,1144 @@ +.. role:: since + +================== +Network XML format +================== + +.. contents:: + +This page provides an introduction to the network XML format. For background +information on the concepts referred to here, consult the `relevant wiki +page