mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-22 13:45:38 +00:00
docs: correct invalid xml
* docs/internals.html.in: Fix xml errors. * docs/formatstorageencryption.html.in: Likewise. * docs/drvesx.html.in: Likewise. * docs/archnetwork.html.in: Likewise. * docs/logging.html.in: Likewise. * docs/drvvmware.html.in: Likewise. * docs/api.html.in: Likewise. * docs/formatnwfilter.html.in: Likewise. * docs/formatdomain.html.in: Likewise. * docs/windows.html.in: Likewise.
This commit is contained in:
parent
da3c471467
commit
b5ec89d955
@ -4,7 +4,7 @@
|
||||
<h1>The libvirt API concepts</h1>
|
||||
|
||||
<p> This page describes the main principles and architecture choices
|
||||
behind the definition of the libvirt API:
|
||||
behind the definition of the libvirt API:</p>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
@ -22,7 +22,7 @@
|
||||
possible to use both KVM and LinuxContainers on the same node). A NULL
|
||||
name will default to a preselected hypervisor but it's probably not a
|
||||
wise thing to do in most cases. See the <a href="uri.html">connection
|
||||
URI</a> page for a full descriptions of the values allowed.<p>
|
||||
URI</a> page for a full descriptions of the values allowed.</p>
|
||||
<p> Once the application obtained a <code class='docref'>virConnectPtr</code>
|
||||
connection to the
|
||||
hypervisor it can then use it to manage domains and related resources
|
||||
@ -61,7 +61,7 @@
|
||||
<code>defined</code> in which case they are inactive but there is
|
||||
a permanent definition available in the system for them. Based on this
|
||||
thay can be activated dynamically in order to be used.</p>
|
||||
<p> Most kind of object can also be named in various ways:<p>
|
||||
<p> Most kind of object can also be named in various ways:</p>
|
||||
<ul>
|
||||
<li>by their <code>name</code>, an user friendly identifier but
|
||||
whose unicity cannot be garanteed between two nodes.</li>
|
||||
@ -82,7 +82,7 @@
|
||||
<p> For each first class object you will find apis
|
||||
for the following actions:</p>
|
||||
<ul>
|
||||
<li><b>Lookup</b>:...LookupByName,
|
||||
<li><b>Lookup</b>:...LookupByName,</li>
|
||||
<li><b>Enumeration</b>:virConnectList... and virConnectNumOf...:
|
||||
those are used to enumerate a set of object available to an given
|
||||
hypervisor connection like:
|
||||
@ -108,7 +108,8 @@
|
||||
<li><b>Destruction</b>: ... </li>
|
||||
</ul>
|
||||
<p> For more in-depth details of the storage related APIs see
|
||||
<a href="storage.html">the storage management page</a>,
|
||||
<a href="storage.html">the storage management page</a>.
|
||||
</p>
|
||||
<h2><a name="Driver">The libvirt drivers</a></h2>
|
||||
<p></p>
|
||||
<p class="image">
|
||||
|
@ -32,7 +32,7 @@
|
||||
</li>
|
||||
<li><strong>Guest C</strong>. The only network interface is connected
|
||||
to a virtual network <code>VLAN 2</code>. It has no direct connectivity
|
||||
to a physical LAN, relying on <code>Guest B</codE> to route traffic
|
||||
to a physical LAN, relying on <code>Guest B</code> to route traffic
|
||||
on its behalf.
|
||||
</li>
|
||||
</ul>
|
||||
|
@ -74,7 +74,7 @@ vpx://example-vcenter.com/dc1/cluster1/example-esx.com
|
||||
</pre>
|
||||
|
||||
|
||||
<h4><a name="extraparams">Extra parameters</h4>
|
||||
<h4><a name="extraparams">Extra parameters</a></h4>
|
||||
<p>
|
||||
Extra parameters can be added to a URI as part of the query string
|
||||
(the part following <code>?</code>). A single parameter is formed by a
|
||||
@ -308,7 +308,7 @@ error: invalid argument in libvirt was built without the 'esx' driver
|
||||
There are several specialties in the domain XML config for ESX domains.
|
||||
</p>
|
||||
|
||||
<h3><a name="restrictions">Restrictions</h3>
|
||||
<h3><a name="restrictions">Restrictions</a></h3>
|
||||
<p>
|
||||
There are some restrictions for some values of the domain XML config.
|
||||
The driver will complain if this restrictions are violated.
|
||||
@ -328,7 +328,7 @@ error: invalid argument in libvirt was built without the 'esx' driver
|
||||
</ul>
|
||||
|
||||
|
||||
<h3><a name="datastore">Datastore references</h3>
|
||||
<h3><a name="datastore">Datastore references</a></h3>
|
||||
<p>
|
||||
Storage is managed in datastores. VMware uses a special path format to
|
||||
reference files in a datastore. Basically, the datastore name is put
|
||||
@ -347,7 +347,7 @@ error: invalid argument in libvirt was built without the 'esx' driver
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a name="macaddresses">MAC addresses</h3>
|
||||
<h3><a name="macaddresses">MAC addresses</a></h3>
|
||||
<p>
|
||||
VMware has registered two MAC address prefixes for domains:
|
||||
<code>00:0c:29</code> and <code>00:50:56</code>. These prefixes are
|
||||
@ -408,7 +408,7 @@ ethernet0.checkMACAddress = "false"
|
||||
</pre>
|
||||
|
||||
|
||||
<h3><a name="hardware">Available hardware</h3>
|
||||
<h3><a name="hardware">Available hardware</a></h3>
|
||||
<p>
|
||||
VMware ESX supports different models of SCSI controllers and network
|
||||
cards.
|
||||
|
@ -8,7 +8,9 @@
|
||||
</p>
|
||||
<p>
|
||||
This driver uses the "vmrun" utility which is distributed with the VMware VIX API.
|
||||
You can download the VIX API from <a href="http://www.vmware.com/support/developer/vix-api/">here</a>.
|
||||
You can download the VIX API
|
||||
from <a href="http://www.vmware.com/support/developer/vix-api/">here</a>.
|
||||
</p>
|
||||
|
||||
<h2>Connections to VMware driver</h2>
|
||||
|
||||
|
@ -1277,7 +1277,7 @@
|
||||
<p>
|
||||
Provides direct attachment of the virtual machine's NIC to the given
|
||||
physial interface of the host.
|
||||
<span class="since">Since 0.7.7 (QEMU and KVM only)</span><br>
|
||||
<span class="since">Since 0.7.7 (QEMU and KVM only)</span><br/>
|
||||
This setup requires the Linux macvtap
|
||||
driver to be available. <span class="since">(Since Linux 2.6.34.)</span>
|
||||
One of the modes 'vepa'
|
||||
@ -1299,7 +1299,7 @@
|
||||
originate from are directly delivered to the target macvtap device.
|
||||
Both origin and destination devices need to be in bridge mode
|
||||
for direct delivery. If either one of them is in <code>vepa</code> mode,
|
||||
a VEPA capable bridge is required.
|
||||
a VEPA capable bridge is required.</dd>
|
||||
<dt><code>private</code></dt>
|
||||
<dd>All packets are sent to the external bridge and will only be
|
||||
delivered to a target VM on the same host if they are sent through an
|
||||
@ -1488,23 +1488,23 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
The <code>txmode</code> attribute specifies how to handle
|
||||
transmission of packets when the transmit buffer is full. The
|
||||
value can be either 'iothread' or 'timer'.
|
||||
<span class="since">Since 0.8.8 (QEMU and KVM only)</span><br><br>
|
||||
<span class="since">Since 0.8.8 (QEMU and KVM only)</span><br/><br/>
|
||||
|
||||
If set to 'iothread', packet tx is all done in an iothread in
|
||||
the bottom half of the driver (this option translates into
|
||||
adding "tx=bh" to the qemu commandline -device virtio-net-pci
|
||||
option).<br><br>
|
||||
option).<br/><br/>
|
||||
|
||||
If set to 'timer', tx work is done in qemu, and if there is
|
||||
more tx data than can be sent at the present time, a timer is
|
||||
set before qemu moves on to do other things; when the timer
|
||||
fires, another attempt is made to send more data.<br><br>
|
||||
fires, another attempt is made to send more data.<br/><br/>
|
||||
|
||||
The resulting difference, according to the qemu developer who
|
||||
added the option is: "bh makes tx more asynchronous and reduces
|
||||
latency, but potentially causes more processor bandwidth
|
||||
contention since the cpu doing the tx isn't necessarily the
|
||||
cpu where the guest generated the packets."<br><br>
|
||||
cpu where the guest generated the packets."<br/><br/>
|
||||
|
||||
<b>In general you should leave this option alone, unless you
|
||||
are very certain you know what you are doing.</b>
|
||||
@ -1628,8 +1628,8 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
in clear text. The <code>keymap</code> attribute specifies the keymap
|
||||
to use. It is possible to set a limit on the validity of the password
|
||||
be giving an timestamp <code>passwdValidTo='2010-04-09T15:51:00'</code>
|
||||
assumed to be in UTC. NB, this may not be supported by all hypervisors.<br>
|
||||
<br>
|
||||
assumed to be in UTC. NB, this may not be supported by all hypervisors.<br/>
|
||||
<br/>
|
||||
Rather than using listen/port, QEMU supports a <code>socket</code>
|
||||
attribute for listening on a unix domain socket path.
|
||||
<span class="since">Since 0.8.8</span>
|
||||
@ -2103,7 +2103,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
Alternatively you can use <code>telnet</code> instead of <code>raw</code> TCP.
|
||||
<span class="since">Since 0.8.5</span> you can also use <code>telnets</code>
|
||||
(secure telnet) and <code>tls</code>.
|
||||
<p>
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
...
|
||||
|
@ -25,18 +25,18 @@
|
||||
cannot be circumvented from within
|
||||
the virtual machine, it makes them mandatory from the point of
|
||||
view of a virtual machine user.
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
The network filter subsystem allows each virtual machine's network
|
||||
traffic filtering rules to be configured individually on a per
|
||||
interface basis. The rules are
|
||||
applied on the host when the virtual machine is started and can be modified
|
||||
while the virtual machine is running. The latter can be achieved by
|
||||
modifying the XML description of a network filter.
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
Multiple virtual machines can make use of the same generic network filter.
|
||||
When such a filter is modified, the network traffic filtering rules
|
||||
of all running virtual machines that reference this filter are updated.
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
Network filtering support is available <span class="since">since 0.8.1
|
||||
(Qemu, KVM)</span>
|
||||
</p>
|
||||
@ -79,7 +79,7 @@
|
||||
other filters can be used, a <i>tree</i> of filters can be built.
|
||||
The <code>clean-traffic</code> filter can be viewed using the
|
||||
command <code>virsh nwfilter-dumpxml clean-traffic</code>.
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
As previously mentioned, a single network filter can be referenced
|
||||
by multiple virtual machines. Since interfaces will typically
|
||||
have individual parameters associated with their respective traffic
|
||||
@ -108,7 +108,7 @@
|
||||
10.0.0.1 and enforce that the traffic from this interface will
|
||||
always be using 10.0.0.1 as the source IP address, which is
|
||||
one of the purposes of this particular filter.
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
</p>
|
||||
|
||||
<h3><a name="nwfconceptsvars">Usage of variables in filters</a></h3>
|
||||
@ -117,7 +117,7 @@
|
||||
Two variables names have so far been reserved for usage by the
|
||||
network traffic filtering subsystem: <code>MAC</code> and
|
||||
<code>IP</code>.
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
<code>MAC</code> is the MAC address of the
|
||||
network interface. A filtering rule that references this variable
|
||||
will automatically be instantiated with the MAC address of the
|
||||
@ -125,7 +125,7 @@
|
||||
the MAC parameter. Even though it is possible to specify the MAC
|
||||
parameter similar to the IP parameter above, it is discouraged
|
||||
since libvirt knows what MAC address an interface will be using.
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
The parameter <code>IP</code> represents the IP address
|
||||
that the operating system inside the virtual machine is expected
|
||||
to use on the given interface. The <code>IP</code> parameter
|
||||
@ -136,7 +136,7 @@
|
||||
For current limitations on IP address detection, consult the
|
||||
<a href="#nwflimits">section on limitations</a> on how to use this
|
||||
feature and what to expect when using it.
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
The following is the XML description of the network filer
|
||||
<code>no-arp-spoofing</code>. It serves as an example for
|
||||
a network filter XML referencing the <code>MAC</code> and
|
||||
@ -205,7 +205,7 @@
|
||||
filters may be referenced multiple times in a filter tree but
|
||||
references between filters must not introduce loops (directed
|
||||
acyclic graph).
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
The following shows the XML of the <code>clean-traffic</code>
|
||||
network filter referencing several other filters.
|
||||
</p>
|
||||
@ -226,7 +226,7 @@
|
||||
needs to be provided inside a <code>filter</code> node. This
|
||||
node must have the attribute <code>filter</code> whose value contains
|
||||
the name of the filter to be referenced.
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
New network filters can be defined at any time and
|
||||
may contain references to network filters that are
|
||||
not known to libvirt, yet. However, once a virtual machine
|
||||
@ -282,7 +282,7 @@
|
||||
<li>
|
||||
statematch -- optional; possible values are '0' or 'false' to
|
||||
turn the underlying connection state matching off; default is 'true'
|
||||
<br>
|
||||
<br/>
|
||||
Also read the section on <a href="#nwfelemsRulesAdv">advanced configuration</a>
|
||||
topics.
|
||||
</li>
|
||||
@ -294,7 +294,7 @@
|
||||
traffic of type <code>ip</code> is also associated with the chain
|
||||
'ipv4' then that filter's rules will be ordered relative to the priority
|
||||
500 of the shown rule.
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
A rule may contain a single rule for filtering of traffic. The
|
||||
above example shows that traffic of type <code>ip</code> is to be
|
||||
filtered.
|
||||
@ -325,7 +325,7 @@
|
||||
<li>STRING: A string</li>
|
||||
</ul>
|
||||
<p>
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
Every attribute except for those of type IP_MASK or IPV6_MASK can
|
||||
be negated using the <code>match</code>
|
||||
attribute with value <code>no</code>. Multiple negated attributes
|
||||
@ -349,14 +349,14 @@
|
||||
the protocol property attribute1 does not match value1 AND
|
||||
the protocol property attribute2 does not match value2 AND
|
||||
the protocol property attribute3 matches value3.
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
</p>
|
||||
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoMAC">MAC (Ethernet)</a></h5>
|
||||
<p>
|
||||
Protocol ID: <code>mac</code>
|
||||
<br>
|
||||
<br/>
|
||||
Note: Rules of this type should go into the <code>root</code> chain.
|
||||
</p>
|
||||
<table class="top_table">
|
||||
@ -408,7 +408,7 @@
|
||||
<h5><a name="nwfelemsRulesProtoARP">ARP/RARP</a></h5>
|
||||
<p>
|
||||
Protocol ID: <code>arp</code> or <code>rarp</code>
|
||||
<br>
|
||||
<br/>
|
||||
Note: Rules of this type should either go into the
|
||||
<code>root</code> or <code>arp/rarp</code> chain.
|
||||
</p>
|
||||
@ -483,7 +483,7 @@
|
||||
Valid strings for the <code>Opcode</code> field are:
|
||||
Request, Reply, Request_Reverse, Reply_Reverse, DRARP_Request,
|
||||
DRARP_Reply, DRARP_Error, InARP_Request, ARP_NAK
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
</p>
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoIP">IPv4</a></h5>
|
||||
@ -572,7 +572,7 @@
|
||||
<p>
|
||||
Valid strings for <code>protocol</code> are:
|
||||
tcp, udp, udplite, esp, ah, icmp, igmp, sctp
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
</p>
|
||||
|
||||
|
||||
@ -662,13 +662,13 @@
|
||||
<p>
|
||||
Valid strings for <code>protocol</code> are:
|
||||
tcp, udp, udplite, esp, ah, icmpv6, sctp
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
</p>
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoTCP-ipv4">TCP/UDP/SCTP</a></h5>
|
||||
<p>
|
||||
Protocol ID: <code>tcp</code>, <code>udp</code>, <code>sctp</code>
|
||||
<br>
|
||||
<br/>
|
||||
Note: The chain parameter is ignored for this type of traffic
|
||||
and should either be omitted or set to <code>root</code>.
|
||||
</p>
|
||||
@ -757,14 +757,14 @@
|
||||
</tr>
|
||||
</table>
|
||||
<p>
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
</p>
|
||||
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoICMP">ICMP</a></h5>
|
||||
<p>
|
||||
Protocol ID: <code>icmp</code>
|
||||
<br>
|
||||
<br/>
|
||||
Note: The chain parameter is ignored for this type of traffic
|
||||
and should either be omitted or set to <code>root</code>.
|
||||
</p>
|
||||
@ -857,13 +857,13 @@
|
||||
</tr>
|
||||
</table>
|
||||
<p>
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
</p>
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoMisc">IGMP, ESP, AH, UDPLITE, 'ALL'</a></h5>
|
||||
<p>
|
||||
Protocol ID: <code>igmp</code>, <code>esp</code>, <code>ah</code>, <code>udplite</code>, <code>all</code>
|
||||
<br>
|
||||
<br/>
|
||||
Note: The chain parameter is ignored for this type of traffic
|
||||
and should either be omitted or set to <code>root</code>.
|
||||
</p>
|
||||
@ -946,14 +946,14 @@
|
||||
</tr>
|
||||
</table>
|
||||
<p>
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
</p>
|
||||
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoTCP-ipv6">TCP/UDP/SCTP over IPV6</a></h5>
|
||||
<p>
|
||||
Protocol ID: <code>tcp-ipv6</code>, <code>udp-ipv6</code>, <code>sctp-ipv6</code>
|
||||
<br>
|
||||
<br/>
|
||||
Note: The chain parameter is ignored for this type of traffic
|
||||
and should either be omitted or set to <code>root</code>.
|
||||
</p>
|
||||
@ -1042,14 +1042,14 @@
|
||||
</tr>
|
||||
</table>
|
||||
<p>
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
</p>
|
||||
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoICMPv6">ICMPv6</a></h5>
|
||||
<p>
|
||||
Protocol ID: <code>icmpv6</code>
|
||||
<br>
|
||||
<br/>
|
||||
Note: The chain parameter is ignored for this type of traffic
|
||||
and should either be omitted or set to <code>root</code>.
|
||||
</p>
|
||||
@ -1128,13 +1128,13 @@
|
||||
</tr>
|
||||
</table>
|
||||
<p>
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
</p>
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoMiscv6">IGMP, ESP, AH, UDPLITE, 'ALL' over IPv6</a></h5>
|
||||
<p>
|
||||
Protocol ID: <code>igmp-ipv6</code>, <code>esp-ipv6</code>, <code>ah-ipv6</code>, <code>udplite-ipv6</code>, <code>all-ipv6</code>
|
||||
<br>
|
||||
<br/>
|
||||
Note: The chain parameter is ignored for this type of traffic
|
||||
and should either be omitted or set to <code>root</code>.
|
||||
</p>
|
||||
@ -1202,7 +1202,7 @@
|
||||
</tr>
|
||||
</table>
|
||||
<p>
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
</p>
|
||||
|
||||
<h3><a name="nwfelemsRulesAdv">Advanced Filter Configuration Topics</a></h3>
|
||||
@ -1227,7 +1227,7 @@
|
||||
port 80 on an attacker site, then the attacker will not be able to
|
||||
initiate a connection from TCP port 80 back towards the VM.
|
||||
By default the connection state match that enables connection tracking
|
||||
and then enforcement of directionality of traffic is turned on. <br>
|
||||
and then enforcement of directionality of traffic is turned on. <br/>
|
||||
The following shows an example XML fragement where this feature has been
|
||||
turned off for incoming connections to TCP port 12345.
|
||||
</p>
|
||||
@ -1277,14 +1277,14 @@
|
||||
</pre>
|
||||
<p>
|
||||
Note that the rule for the limit has to logically appear
|
||||
before the rule for accepting the traffic.<br>
|
||||
before the rule for accepting the traffic.<br/>
|
||||
An additional rule for letting DNS traffic to port 22
|
||||
go out the VM has been added to avoid ssh sessions not
|
||||
getting established for reasons related to DNS lookup failures
|
||||
by the ssh daemon. Leaving this rule out may otherwise lead to
|
||||
fun-filled debugging joy (symptom: ssh client seems to hang
|
||||
while trying to connect).
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
Lot of care must be taken with timeouts related
|
||||
to tracking of traffic. An ICMP ping that
|
||||
the user may have terminated inside the VM may have a long
|
||||
@ -1299,7 +1299,7 @@
|
||||
<p>
|
||||
sets the ICMP connection tracking timeout to 3 seconds. The
|
||||
effect of this is that once one ping is terminated, another
|
||||
one can start after 3 seconds.<br>
|
||||
one can start after 3 seconds.<br/>
|
||||
Further, we want to point out that a client that for whatever
|
||||
reason has not properly closed a TCP connection may cause a
|
||||
connection to be held open for a longer period of time,
|
||||
@ -1323,7 +1323,7 @@
|
||||
with life-cycle support for network filters. All commands related
|
||||
to the network filtering subsystem start with the prefix
|
||||
<code>nwfilter</code>. The following commands are available:
|
||||
<p>
|
||||
</p>
|
||||
<ul>
|
||||
<li>nwfilter-list : list UUIDs and names of all network filters</li>
|
||||
<li>nwfilter-define : define a new network filter or update an existing one</li>
|
||||
@ -1398,7 +1398,7 @@
|
||||
the protocols very well that you want to be filtering on so that
|
||||
no further traffic than what you want can pass and that in fact the
|
||||
traffic you want to allow does pass.
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
The network filtering subsystem is currently only available on
|
||||
Linux hosts and only works for Qemu and KVM type of virtual machines.
|
||||
On Linux
|
||||
@ -1412,19 +1412,19 @@
|
||||
<li>arp, rarp</li>
|
||||
<li>ip</li>
|
||||
<li>ipv6</li>
|
||||
</uL>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
All other protocols over IPv4 are supported using iptables, those over
|
||||
IPv6 are implemented using ip6tables.
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
On a Linux host, all traffic filtering instantiated by libvirt's network
|
||||
filter subsystem first passes through the filtering support implemented
|
||||
by ebtables and only then through iptables or ip6tables filters. If
|
||||
a filter tree has rules with the protocols <code>mac</code>,
|
||||
<code>arp</code>, <code>rarp</code>, <code>ip</code>, or <code>ipv6</code>
|
||||
ebtables rules will automatically be instantiated.
|
||||
<br>
|
||||
<br/>
|
||||
The role of the <code>chain</code> attribute in the network filter
|
||||
XML is that internally a new user-defined ebtables table is created
|
||||
that then for example receives all <code>arp</code> traffic coming
|
||||
@ -1435,7 +1435,7 @@
|
||||
placed into filters specifying this chain. This type of branching
|
||||
into user-defined tables is only supported with filtering on the ebtables
|
||||
layer.
|
||||
<br>
|
||||
<br/>
|
||||
As an example, it is
|
||||
possible to filter on UDP traffic by source and destination ports using
|
||||
the <code>ip</code> protocol filter and specifying attributes for the
|
||||
@ -1467,7 +1467,7 @@
|
||||
The requirement to prevent spoofing is fulfilled by the existing
|
||||
<code>clean-traffic</code> network filter, thus we will reference this
|
||||
filter from our custom filter.
|
||||
<br>
|
||||
<br/>
|
||||
To enable traffic for TCP ports 22 and 80 we will add 2 rules to
|
||||
enable this type of traffic. To allow the VM to send ping traffic
|
||||
we will add a rule for ICMP traffic. For simplicity reasons
|
||||
@ -1523,7 +1523,7 @@
|
||||
per-interface basis and the rules are evaluated based on the knowledge
|
||||
about which (tap) interface has sent or will receive the packet rather
|
||||
than what their source or destination IP address may be.
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
An XML fragment for a possible network interface description inside
|
||||
the domain XML of the <code>test</code> VM could then look like this:
|
||||
</p>
|
||||
@ -1568,7 +1568,7 @@
|
||||
<li>allows the VM to send ping traffic from an interface
|
||||
but not let the VM be pinged on the interface</li>
|
||||
<li>allows the VM to do DNS lookups (UDP towards port 53)</li>
|
||||
<li>enable an ftp server (in active mode) to be run inside the VM
|
||||
<li>enable an ftp server (in active mode) to be run inside the VM</li>
|
||||
</ul>
|
||||
<p>
|
||||
The additional requirement of allowing an ftp server to be run inside
|
||||
@ -1577,7 +1577,7 @@
|
||||
outgoing tcp connection originating from the VM's TCP port 20 back to
|
||||
the ftp client (ftp active mode). There are several ways of how this
|
||||
filter can be written and we present 2 solutions.
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
The 1st solution makes use of the <code>state</code> attribute of
|
||||
the TCP protocol that gives us a hook into the connection tracking
|
||||
framework of the Linux host. For the VM-initiated ftp data connection
|
||||
@ -1752,13 +1752,13 @@
|
||||
to be using.
|
||||
Different IP addresses in use by multiple interfaces of a VM
|
||||
(one IP address each) will be independently detected.
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
Once a VM's IP address has been detected, its IP network traffic
|
||||
may be locked to that address, if for example IP address spoofing
|
||||
is prevented by one of its filters. In that case the user of the VM
|
||||
will not be able to change the IP address on the interface inside
|
||||
the VM, which would be considered IP address spoofing.
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
In case a VM is resumed after suspension or migrated, IP address
|
||||
detection will be restarted.
|
||||
</p>
|
||||
@ -1776,7 +1776,7 @@
|
||||
outside the scope of libvirt to ensure that referenced filters
|
||||
on the source system are equivalent to those on the target system
|
||||
and vice versa.
|
||||
<br><br>
|
||||
<br/><br/>
|
||||
Migration must occur between libvirt insallations of version
|
||||
0.8.1 or later in order not to lose the network traffic filters
|
||||
associated with an interface.
|
||||
|
@ -30,7 +30,7 @@
|
||||
by the particular volume format and driver, automatically generate a
|
||||
secret value at the time of volume creation, and store it using the
|
||||
specified <code>uuid</code>.
|
||||
<p>
|
||||
</p>
|
||||
<h3><a name="StorageEncryptionDefault">"default" format</a></h3>
|
||||
<p>
|
||||
<code><encryption type="default"/></code> can be specified only
|
||||
|
@ -9,9 +9,9 @@
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>Introduction to basic rules and guidelines for <a href="hacking.html">hacking<a>
|
||||
<li>Introduction to basic rules and guidelines for <a href="hacking.html">hacking</a>
|
||||
on libvirt code</li>
|
||||
<li>Guide to adding <a href="api_extension.html">public APIs<a></li>
|
||||
<li>Guide to adding <a href="api_extension.html">public APIs</a></li>
|
||||
<li>Approach for <a href="internals/command.html">spawning commands</a> from
|
||||
libvirt driver code</li>
|
||||
</ul>
|
||||
|
@ -82,7 +82,7 @@
|
||||
<a name="log_daemon">Logging in the daemon</a>
|
||||
</h3>
|
||||
<p>Similarly the daemon logging behaviour can be tuned using 3 config
|
||||
variables, stored in the configuration file:
|
||||
variables, stored in the configuration file:</p>
|
||||
<ul>
|
||||
<li>log_level: accepts the following values:
|
||||
<ul>
|
||||
@ -128,7 +128,7 @@
|
||||
<p>Multiple filters can be defined in a single string, they just need to be
|
||||
separated by spaces, e.g: <code>"3:remote 4:event"</code> to only get
|
||||
warning or errors from the remote layer and only errors from the event
|
||||
layer.<p>
|
||||
layer.</p>
|
||||
<p>If you specify a log priority in a filter that is below the default log
|
||||
priority level, messages that match that filter will still be logged,
|
||||
while others will not. In order to see those messages, you must also have
|
||||
|
@ -30,7 +30,7 @@
|
||||
and untested Python bindings.
|
||||
</p>
|
||||
|
||||
<h3><a name="caveats">Caveats</h3>
|
||||
<h3><a name="caveats">Caveats</a></h3>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
@ -47,7 +47,7 @@
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h3><a name="knowninstallerprobs">Existing problems with this installer we know about</a>
|
||||
<h3><a name="knowninstallerprobs">Existing problems with this installer we know about</a></h3>
|
||||
|
||||
<p>
|
||||
These are problems we know about, and need to be fixed in subsequent
|
||||
@ -72,7 +72,7 @@
|
||||
|
||||
</ul>
|
||||
|
||||
<h2><a name="conntypes">Connection types</h2>
|
||||
<h2><a name="conntypes">Connection types</a></h2>
|
||||
|
||||
<p>
|
||||
These connection types are known to work:
|
||||
@ -114,7 +114,7 @@
|
||||
be used in security sensitive environments.</b>
|
||||
</p>
|
||||
|
||||
<h2><a name="esx">Connecting to VMware ESX/vSphere</h2>
|
||||
<h2><a name="esx">Connecting to VMware ESX/vSphere</a></h2>
|
||||
|
||||
<p>
|
||||
Details on the capabilities, certificates, and connection string
|
||||
@ -124,7 +124,7 @@
|
||||
|
||||
<a href="http://libvirt.org/drvesx.html">http://libvirt.org/drvesx.html</a>
|
||||
|
||||
<h2><a name="tlscerts">TLS Certificates</h2>
|
||||
<h2><a name="tlscerts">TLS Certificates</a></h2>
|
||||
|
||||
<p>
|
||||
TLS certificates need to have been created and placed in the correct
|
||||
@ -184,7 +184,7 @@
|
||||
<li>C:\Users\someuser\AppData\Roaming\libvirt\pki\libvirt\private\clientkey.pem</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="feedback">Feedback</h2>
|
||||
<h2><a name="feedback">Feedback</a></h2>
|
||||
|
||||
<p>
|
||||
Feedback and suggestions on changes to make and what else to include
|
||||
|
Loading…
Reference in New Issue
Block a user