mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-22 13:45:38 +00:00
docs: switch to using 'id' attribute instead of 'name' for links
The 'name' attribute on <a...> elements is deprecated in favour of the 'id' attribute which is allowed on any element. HTML5 drops 'name' support entirely. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This commit is contained in:
parent
ba54acd3c7
commit
4e42ff6b7e
@ -12,7 +12,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="intro">Access control introduction</a></h2>
|
||||
<h2><a id="intro">Access control introduction</a></h2>
|
||||
|
||||
<p>
|
||||
In a default configuration, the libvirtd daemon has three levels
|
||||
@ -42,7 +42,7 @@
|
||||
<code>getattr</code> permission.
|
||||
</p>
|
||||
|
||||
<h2><a name="drivers">Access control drivers</a></h2>
|
||||
<h2><a id="drivers">Access control drivers</a></h2>
|
||||
|
||||
<p>
|
||||
The access control framework is designed as a pluggable
|
||||
@ -83,7 +83,7 @@
|
||||
the libvirtd daemon be restarted.
|
||||
</p>
|
||||
|
||||
<h2><a name="perms">Objects and permissions</a></h2>
|
||||
<h2><a id="perms">Objects and permissions</a></h2>
|
||||
|
||||
<p>
|
||||
Libvirt applies access control to all the main object
|
||||
|
@ -14,7 +14,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="intro">Introduction</a></h2>
|
||||
<h2><a id="intro">Introduction</a></h2>
|
||||
|
||||
<p>
|
||||
A default install of libvirt will typically use
|
||||
@ -27,7 +27,7 @@
|
||||
object.
|
||||
</p>
|
||||
|
||||
<h2><a name="perms">Permission names</a></h2>
|
||||
<h2><a id="perms">Permission names</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt <a href="acl.html#perms">object names and permission names</a>
|
||||
@ -53,7 +53,7 @@
|
||||
permissions default to deny access.
|
||||
</p>
|
||||
|
||||
<h2><a name="attrs">Object identity attributes</a></h2>
|
||||
<h2><a id="attrs">Object identity attributes</a></h2>
|
||||
|
||||
<p>
|
||||
To allow polkit authorization rules to be written to match
|
||||
@ -63,7 +63,7 @@
|
||||
of object being checked
|
||||
</p>
|
||||
|
||||
<h3><a name="object_connect">virConnectPtr</a></h3>
|
||||
<h3><a id="object_connect">virConnectPtr</a></h3>
|
||||
<table class="acl">
|
||||
<thead>
|
||||
<tr>
|
||||
@ -79,7 +79,7 @@
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3><a name="object_domain">virDomainPtr</a></h3>
|
||||
<h3><a id="object_domain">virDomainPtr</a></h3>
|
||||
<table class="acl">
|
||||
<thead>
|
||||
<tr>
|
||||
@ -103,7 +103,7 @@
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3><a name="object_interface">virInterfacePtr</a></h3>
|
||||
<h3><a id="object_interface">virInterfacePtr</a></h3>
|
||||
<table class="acl">
|
||||
<thead>
|
||||
<tr>
|
||||
@ -127,7 +127,7 @@
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3><a name="object_network">virNetworkPtr</a></h3>
|
||||
<h3><a id="object_network">virNetworkPtr</a></h3>
|
||||
<table class="acl">
|
||||
<thead>
|
||||
<tr>
|
||||
@ -151,7 +151,7 @@
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3><a name="object_node_device">virNodeDevicePtr</a></h3>
|
||||
<h3><a id="object_node_device">virNodeDevicePtr</a></h3>
|
||||
<table class="acl">
|
||||
<thead>
|
||||
<tr>
|
||||
@ -171,7 +171,7 @@
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3><a name="object_nwfilter">virNWFilterPtr</a></h3>
|
||||
<h3><a id="object_nwfilter">virNWFilterPtr</a></h3>
|
||||
<table class="acl">
|
||||
<thead>
|
||||
<tr>
|
||||
@ -195,7 +195,7 @@
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3><a name="object_secret">virSecretPtr</a></h3>
|
||||
<h3><a id="object_secret">virSecretPtr</a></h3>
|
||||
<table class="acl">
|
||||
<thead>
|
||||
<tr>
|
||||
@ -231,7 +231,7 @@
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3><a name="object_storage_pool">virStoragePoolPtr</a></h3>
|
||||
<h3><a id="object_storage_pool">virStoragePoolPtr</a></h3>
|
||||
<table class="acl">
|
||||
<thead>
|
||||
<tr>
|
||||
@ -255,7 +255,7 @@
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3><a name="object_storage_vol">virStorageVolPtr</a></h3>
|
||||
<h3><a id="object_storage_vol">virStorageVolPtr</a></h3>
|
||||
<table class="acl">
|
||||
<thead>
|
||||
<tr>
|
||||
@ -288,7 +288,7 @@
|
||||
</table>
|
||||
|
||||
|
||||
<h2><a name="user">User identity attributes</a></h2>
|
||||
<h2><a id="user">User identity attributes</a></h2>
|
||||
|
||||
<p>
|
||||
At this point in time, the only attribute provided by
|
||||
@ -307,7 +307,7 @@
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a name="checks">Writing access control policies</a></h2>
|
||||
<h2><a id="checks">Writing access control policies</a></h2>
|
||||
|
||||
<p>
|
||||
If using versions of polkit prior to 0.106 then it is only
|
||||
@ -358,7 +358,7 @@ polkit.addRule(function(action, subject) {
|
||||
for a more complex example.
|
||||
</p>
|
||||
|
||||
<h3><a name="exconnect">Example: restricting ability to connect to drivers</a></h3>
|
||||
<h3><a id="exconnect">Example: restricting ability to connect to drivers</a></h3>
|
||||
|
||||
<p>
|
||||
Consider a local user <code>berrange</code>
|
||||
@ -386,7 +386,7 @@ polkit.addRule(function(action, subject) {
|
||||
});
|
||||
</pre>
|
||||
|
||||
<h3><a name="exdomain">Example: restricting access to a single domain</a></h3>
|
||||
<h3><a id="exdomain">Example: restricting access to a single domain</a></h3>
|
||||
|
||||
<p>
|
||||
Consider a local user <code>berrange</code>
|
||||
|
@ -9,7 +9,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="Objects">Objects Exposed</a></h2>
|
||||
<h2><a id="Objects">Objects Exposed</a></h2>
|
||||
<p> As defined in the <a href="goals.html">goals section</a>, the libvirt
|
||||
API is designed to expose all the resources needed to manage the
|
||||
virtualization support of recent operating systems. The first object
|
||||
@ -121,7 +121,7 @@
|
||||
set of nodes.</p></li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="Functions">Functions and Naming Conventions</a></h2>
|
||||
<h2><a id="Functions">Functions and Naming Conventions</a></h2>
|
||||
<p> The naming of the functions present in the library is usually
|
||||
composed by a prefix describing the object associated to the function
|
||||
and a verb describing the action on that object.</p>
|
||||
@ -297,7 +297,7 @@
|
||||
<p> For more in-depth details of the storage related APIs see
|
||||
<a href="storage.html">the storage management page</a>.
|
||||
</p>
|
||||
<h2><a name="Drivers">The libvirt Drivers</a></h2>
|
||||
<h2><a id="Drivers">The libvirt Drivers</a></h2>
|
||||
<p>Drivers are the basic building block for libvirt functionality
|
||||
to support the capability to handle specific hypervisor driver calls.
|
||||
Drivers are discovered and registered during connection processing as
|
||||
@ -325,7 +325,7 @@
|
||||
the various functions and support found in each driver by the version
|
||||
support was added into libvirt.
|
||||
</p>
|
||||
<h2><a name="Remote">Daemon and Remote Access</a></h2>
|
||||
<h2><a id="Remote">Daemon and Remote Access</a></h2>
|
||||
<p>Access to libvirt drivers is primarily handled by the libvirtd
|
||||
daemon through the <a href="remote.html">remote</a> driver via an
|
||||
<a href="internals/rpc.html">RPC</a>. Some hypervisors do support
|
||||
|
@ -273,7 +273,7 @@
|
||||
<li>unlocks the remote driver.</li>
|
||||
</ol>
|
||||
|
||||
<h3><a name="serverdispatch">Implement the server side dispatcher</a></h3>
|
||||
<h3><a id="serverdispatch">Implement the server side dispatcher</a></h3>
|
||||
|
||||
<p>
|
||||
Implementing the server side of the remote function call is simply a
|
||||
@ -300,7 +300,7 @@
|
||||
|
||||
<p class="example">See <a href="api_extension/0005-implement-the-remote-protocol.patch">0005-implement-the-remote-protocol.patch</a></p>
|
||||
|
||||
<h2><a name="internaluseapi">Use the new API internally</a></h2>
|
||||
<h2><a id="internaluseapi">Use the new API internally</a></h2>
|
||||
|
||||
<p>
|
||||
Sometimes, a new API serves as a superset of existing API, by
|
||||
@ -314,7 +314,7 @@
|
||||
|
||||
<p class="example">See <a href="api_extension/0006-make-old-API-trivially-wrap-to-new-API.patch">0006-make-old-API-trivially-wrap-to-new-API.patch</a></p>
|
||||
|
||||
<h2><a name="virshuseapi">Expose the new API in virsh</a></h2>
|
||||
<h2><a id="virshuseapi">Expose the new API in virsh</a></h2>
|
||||
|
||||
<p>
|
||||
All new API should be manageable from the virsh command line
|
||||
@ -345,7 +345,7 @@
|
||||
|
||||
<p class="example">See <a href="api_extension/0007-add-virsh-support.patch">0007-add-virsh-support.patch</a></p>
|
||||
|
||||
<h2><a name="driverimpl">Implement the driver methods</a></h2>
|
||||
<h2><a id="driverimpl">Implement the driver methods</a></h2>
|
||||
|
||||
<p>
|
||||
So, after all that, we get to the fun part. All functionality in
|
||||
@ -356,7 +356,7 @@
|
||||
adding.
|
||||
</p>
|
||||
|
||||
<h3><a name="commonimpl">Implement common handling</a></h3>
|
||||
<h3><a id="commonimpl">Implement common handling</a></h3>
|
||||
|
||||
<p>
|
||||
If the new API is applicable to more than one driver, it may
|
||||
@ -373,7 +373,7 @@
|
||||
|
||||
<p class="example">See <a href="api_extension/0008-support-new-xml.patch">0008-support-new-xml.patch</a></p>
|
||||
|
||||
<h3><a name="drivercode">Implement driver handling</a></h3>
|
||||
<h3><a id="drivercode">Implement driver handling</a></h3>
|
||||
|
||||
<p>
|
||||
The remaining patches should only touch one driver at a time.
|
||||
|
@ -11,7 +11,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="add">Add an application</a></h2>
|
||||
<h2><a id="add">Add an application</a></h2>
|
||||
|
||||
<p>
|
||||
To add an application not listed on this page, send a message
|
||||
@ -30,7 +30,7 @@
|
||||
<img src="logos/logo-square-powered-256.png" alt="libvirt powered"/>
|
||||
</p>
|
||||
|
||||
<h2><a name="clientserver">Client/Server applications</a></h2>
|
||||
<h2><a id="clientserver">Client/Server applications</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://archipelproject.org">Archipel</a></dt>
|
||||
@ -50,7 +50,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a name="command">Command line tools</a></h2>
|
||||
<h2><a id="command">Command line tools</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://libguestfs.org">guestfish</a></dt>
|
||||
@ -121,7 +121,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a name="configmgmt">Configuration Management</a></h2>
|
||||
<h2><a id="configmgmt">Configuration Management</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="https://wiki.lcfg.org/bin/view/LCFG/LcfgLibvirt">LCFG</a></dt>
|
||||
@ -139,7 +139,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a name="continuousintegration">Continuous Integration</a></h2>
|
||||
<h2><a id="continuousintegration">Continuous Integration</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://buildbot.net/buildbot/docs/current/Libvirt.html">BuildBot</a></dt>
|
||||
@ -163,7 +163,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a name="conversion">Conversion</a></h2>
|
||||
<h2><a id="conversion">Conversion</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://libguestfs.org/virt-p2v.1.html">virt-p2v</a></dt>
|
||||
@ -194,7 +194,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a name="desktop">Desktop applications</a></h2>
|
||||
<h2><a id="desktop">Desktop applications</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://virt-manager.org/">virt-manager</a></dt>
|
||||
@ -224,7 +224,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a name="iaas">Infrastructure as a Service (IaaS)</a></h2>
|
||||
<h2><a id="iaas">Infrastructure as a Service (IaaS)</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://cc1.ifj.edu.pl">Cracow Cloud One</a></dt>
|
||||
@ -288,7 +288,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a name="libraries">Libraries</a></h2>
|
||||
<h2><a id="libraries">Libraries</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://libguestfs.org">libguestfs</a></dt>
|
||||
@ -321,7 +321,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a name="livecd">LiveCD / Appliances</a></h2>
|
||||
<h2><a id="livecd">LiveCD / Appliances</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://et.redhat.com/~rjones/virt-p2v/">virt-p2v</a></dt>
|
||||
@ -334,7 +334,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a name="monitoring">Monitoring</a></h2>
|
||||
<h2><a id="monitoring">Monitoring</a></h2>
|
||||
<dl>
|
||||
<dt><a href="http://collectd.org/plugins/libvirt.shtml">collectd</a></dt>
|
||||
<dd>
|
||||
@ -381,7 +381,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a name="provisioning">Provisioning</a></h2>
|
||||
<h2><a id="provisioning">Provisioning</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://www.ibm.com/software/tivoli/products/prov-mgr/">Tivoli Provisioning Manager</a></dt>
|
||||
@ -415,7 +415,7 @@
|
||||
</dl>
|
||||
|
||||
|
||||
<h2><a name="web">Web applications</a></h2>
|
||||
<h2><a id="web">Web applications</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://community.abiquo.com/display/AbiCloud">AbiCloud</a></dt>
|
||||
@ -468,7 +468,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a name="mobile">Mobile applications</a></h2>
|
||||
<h2><a id="mobile">Mobile applications</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="https://market.android.com/details?id=vm.manager">VM Manager</a></dt>
|
||||
@ -479,7 +479,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a name="other">Other</a></h2>
|
||||
<h2><a id="other">Other</a></h2>
|
||||
|
||||
<dl>
|
||||
<dt><a href="http://cuckoosandbox.org/">Cuckoo Sandbox</a></dt>
|
||||
|
@ -13,7 +13,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="Xen">Xen support</a></h2>
|
||||
<h2><a id="Xen">Xen support</a></h2>
|
||||
|
||||
<p>When running in a Xen environment, programs using libvirt have to execute
|
||||
in "Domain 0", which is the primary Linux OS loaded on the machine. That OS
|
||||
@ -46,7 +46,7 @@ connect to initialize the library. It will then fork a libvirt_proxy
|
||||
program running as root and providing read_only access to the API, this is
|
||||
then only useful for reporting and monitoring.</p>
|
||||
|
||||
<h2><a name="QEmu">QEmu and KVM support</a></h2>
|
||||
<h2><a id="QEmu">QEmu and KVM support</a></h2>
|
||||
|
||||
<p>The model for QEmu and KVM is completely similar, basically KVM is based
|
||||
on QEmu for the process controlling a new domain, only small details differs
|
||||
@ -60,7 +60,7 @@ domain, by specifying the architecture and machine type targeted.</p>
|
||||
<p>The code controlling the QEmu process is available in the
|
||||
<code>qemud/</code> directory.</p>
|
||||
|
||||
<h2><a name="drivers">Driver based architecture</a></h2>
|
||||
<h2><a id="drivers">Driver based architecture</a></h2>
|
||||
|
||||
<p>As the previous section explains, libvirt can communicate using different
|
||||
channels with the current hypervisor, and should also be able to use
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="intro">Introduction</a></h2>
|
||||
<h2><a id="intro">Introduction</a></h2>
|
||||
|
||||
<p>
|
||||
A number of the libvirt virtualization drivers (QEMU/KVM and LXC) include
|
||||
@ -17,7 +17,7 @@
|
||||
the logs will usually end up in <code>/var/log/audit/audit.log</code>
|
||||
</p>
|
||||
|
||||
<h2><a name="config">Configuration</a></h2>
|
||||
<h2><a id="config">Configuration</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt audit integration is enabled by default on any host which has
|
||||
@ -48,7 +48,7 @@
|
||||
mentioned above.
|
||||
</p>
|
||||
|
||||
<h2><a name="types">Message types</a></h2>
|
||||
<h2><a id="types">Message types</a></h2>
|
||||
|
||||
<p>
|
||||
Libvirt defines three core audit message types each of which will
|
||||
@ -90,7 +90,7 @@
|
||||
<dd>Result of the action, either <code>success</code> or <code>failed</code></dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="typecontrol">VIRT_CONTROL</a></h3>
|
||||
<h3><a id="typecontrol">VIRT_CONTROL</a></h3>
|
||||
|
||||
<p>
|
||||
Reports change in the lifecycle state of a virtual machine. The <code>msg</code>
|
||||
@ -110,7 +110,7 @@
|
||||
<dd>Namespace ID of the <code>init</code> process in a container. Only if <code>op=init</code> and <code>virt=lxc</code></dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="typemachine">VIRT_MACHINE_ID</a></h3>
|
||||
<h3><a id="typemachine">VIRT_MACHINE_ID</a></h3>
|
||||
|
||||
<p>
|
||||
Reports the association of a security context with a guest. The <code>msg</code>
|
||||
@ -126,7 +126,7 @@
|
||||
<dd>Security context for the guest disk images and other assigned host resources</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="typeresource">VIRT_RESOURCE</a></h3>
|
||||
<h3><a id="typeresource">VIRT_RESOURCE</a></h3>
|
||||
|
||||
<p>
|
||||
Reports the usage of a host resource by a guest. The fields include will
|
||||
@ -137,7 +137,7 @@
|
||||
be generated.
|
||||
</p>
|
||||
|
||||
<h4><a name="typeresourcevcpu">Virtual CPU</a></h4>
|
||||
<h4><a id="typeresourcevcpu">Virtual CPU</a></h4>
|
||||
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
@ -155,7 +155,7 @@
|
||||
</dl>
|
||||
|
||||
|
||||
<h4><a name="typeresourcemem">Memory</a></h4>
|
||||
<h4><a id="typeresourcemem">Memory</a></h4>
|
||||
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
@ -172,7 +172,7 @@
|
||||
<dd>Updated memory size in bytes</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="typeresourcedisk">Disk</a></h4>
|
||||
<h4><a id="typeresourcedisk">Disk</a></h4>
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
@ -188,7 +188,7 @@
|
||||
<dd>Updated host file or device path acting as the disk backing file</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="typeresourcenic">Network interface</a></h4>
|
||||
<h4><a id="typeresourcenic">Network interface</a></h4>
|
||||
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
@ -221,7 +221,7 @@
|
||||
<dd>Name of the host network interface</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="typeresourcefs">Filesystem</a></h4>
|
||||
<h4><a id="typeresourcefs">Filesystem</a></h4>
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
@ -237,7 +237,7 @@
|
||||
<dd>Updated host directory, file or device path backing the filesystem</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="typeresourcehost">Host device</a></h4>
|
||||
<h4><a id="typeresourcehost">Host device</a></h4>
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
@ -255,7 +255,7 @@
|
||||
<dd>The path of the character device assigned to the guest, if <code>resrc=hostdev</code></dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="typeresourcetpm">TPM</a></h4>
|
||||
<h4><a id="typeresourcetpm">TPM</a></h4>
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
@ -269,7 +269,7 @@
|
||||
<dd>The path of the host TPM device assigned to the guest</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="typeresourcerng">RNG</a></h4>
|
||||
<h4><a id="typeresourcerng">RNG</a></h4>
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
@ -285,7 +285,7 @@
|
||||
<dd>Updated path of the host entropy source for the RNG</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="typeresourcechardev">console/serial/parallel/channel</a></h4>
|
||||
<h4><a id="typeresourcechardev">console/serial/parallel/channel</a></h4>
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
@ -301,7 +301,7 @@
|
||||
<dd>Updated path of the backing character device for given emulated device</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="typeresourcesmartcard">smartcard</a></h4>
|
||||
<h4><a id="typeresourcesmartcard">smartcard</a></h4>
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
@ -321,7 +321,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="typeresourceredir">Redirected device</a></h4>
|
||||
<h4><a id="typeresourceredir">Redirected device</a></h4>
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
@ -337,7 +337,7 @@
|
||||
<dd>The device type, only <code>USB redir</code> allowed</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="typeresourcecgroup">Control group</a></h4>
|
||||
<h4><a id="typeresourcecgroup">Control group</a></h4>
|
||||
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
@ -353,7 +353,7 @@
|
||||
</dl>
|
||||
|
||||
|
||||
<h4><a name="typeresourceshmem">Shared memory</a></h4>
|
||||
<h4><a id="typeresourceshmem">Shared memory</a></h4>
|
||||
<p>
|
||||
The <code>msg</code> field will include the following sub-fields
|
||||
</p>
|
||||
|
@ -14,7 +14,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="Auth_client_config">Client configuration</a></h2>
|
||||
<h2><a id="Auth_client_config">Client configuration</a></h2>
|
||||
|
||||
<p>
|
||||
When connecting to a remote hypervisor which requires authentication,
|
||||
@ -142,7 +142,7 @@ credentials=defgrp</pre>
|
||||
to storage VNC or SPICE login credentials
|
||||
</p>
|
||||
|
||||
<h2><a name="ACL_server_config">Server configuration</a></h2>
|
||||
<h2><a id="ACL_server_config">Server configuration</a></h2>
|
||||
<p>
|
||||
The libvirt daemon allows the administrator to choose the authentication
|
||||
mechanisms used for client connections on each network socket independently.
|
||||
@ -153,7 +153,7 @@ currently a choice of <code>none</code>, <code>polkit</code>, and <code>sasl</co
|
||||
The SASL scheme can be further configured to choose between a large
|
||||
number of different mechanisms.
|
||||
</p>
|
||||
<h2><a name="ACL_server_unix_perms">UNIX socket permissions/group</a></h2>
|
||||
<h2><a id="ACL_server_unix_perms">UNIX socket permissions/group</a></h2>
|
||||
<p>
|
||||
If libvirt does not contain support for PolicyKit, then access control for
|
||||
the UNIX domain socket is done using traditional file user/group ownership
|
||||
@ -170,7 +170,7 @@ parameter. For example, setting the former to mode <code>0770</code> and the
|
||||
latter <code>wheel</code> would let any user in the wheel group connect to
|
||||
the libvirt daemon.
|
||||
</p>
|
||||
<h2><a name="ACL_server_polkit">UNIX socket PolicyKit auth</a></h2>
|
||||
<h2><a id="ACL_server_polkit">UNIX socket PolicyKit auth</a></h2>
|
||||
<p>
|
||||
If libvirt contains support for PolicyKit, then access control options are
|
||||
more advanced. The <code>auth_unix_rw</code> parameter will default to
|
||||
@ -204,7 +204,7 @@ ResultActive=yes</pre>
|
||||
Further examples of PolicyKit setup can be found on the
|
||||
<a href="http://wiki.libvirt.org/page/SSHPolicyKitSetup">wiki page</a>.
|
||||
</p>
|
||||
<h2><a name="ACL_server_sasl">SASL pluggable authentication</a></h2>
|
||||
<h2><a id="ACL_server_sasl">SASL pluggable authentication</a></h2>
|
||||
|
||||
<p>
|
||||
Libvirt integrates with the cyrus-sasl library to provide a pluggable authentication
|
||||
@ -255,7 +255,7 @@ GSSAPI plugin is considered acceptably secure by modern standards:
|
||||
TLS or UNIX socket listeners.
|
||||
</p>
|
||||
|
||||
<h3><a name="ACL_server_username">Username/password auth</a></h3>
|
||||
<h3><a id="ACL_server_username">Username/password auth</a></h3>
|
||||
<p>
|
||||
As noted above, the DIGEST-MD5 mechanism is considered obsolete and should
|
||||
not be used anymore. To provide a simple username/password auth scheme on
|
||||
@ -297,7 +297,7 @@ again:
|
||||
<pre>
|
||||
# saslpasswd2 -a libvirt -d fred
|
||||
</pre>
|
||||
<h3><a name="ACL_server_kerberos">GSSAPI/Kerberos auth</a></h3>
|
||||
<h3><a id="ACL_server_kerberos">GSSAPI/Kerberos auth</a></h3>
|
||||
<p>
|
||||
The plain TCP listener of the libvirt daemon defaults to using SASL for authentication.
|
||||
The libvirt SASL config also defaults to GSSAPI, so there is no need to edit the
|
||||
|
@ -7,7 +7,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="security">Security Issues</a></h2>
|
||||
<h2><a id="security">Security Issues</a></h2>
|
||||
|
||||
<p>
|
||||
If you think that an issue with libvirt may have security
|
||||
@ -19,7 +19,7 @@
|
||||
<a href="securityprocess.html">security process</a> instead.
|
||||
</p>
|
||||
|
||||
<h2><a name="bugzilla">Bug Tracking</a></h2>
|
||||
<h2><a id="bugzilla">Bug Tracking</a></h2>
|
||||
|
||||
<p>
|
||||
If you are using libvirt binaries from a Linux distribution
|
||||
@ -27,7 +27,7 @@
|
||||
first.
|
||||
</p>
|
||||
|
||||
<h2><a name="general">General libvirt bug reports</a></h2>
|
||||
<h2><a id="general">General libvirt bug reports</a></h2>
|
||||
|
||||
<p>
|
||||
The <a href="http://bugzilla.redhat.com">Red Hat Bugzilla Server</a>
|
||||
@ -69,7 +69,7 @@
|
||||
<li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Virtualization%20Tools&component=libvirt">New libvirt ticket</a></li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="distribution">Linux Distribution specific bug reports</a></h2>
|
||||
<h2><a id="distribution">Linux Distribution specific bug reports</a></h2>
|
||||
<ul>
|
||||
<li>
|
||||
If you are using binaries from <strong>Fedora</strong>, enter
|
||||
@ -107,7 +107,7 @@
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="quality">How to file high quality bug reports</a></h2>
|
||||
<h2><a id="quality">How to file high quality bug reports</a></h2>
|
||||
|
||||
<p>
|
||||
To increase the likelihood of your bug report being addressed it is
|
||||
|
@ -11,7 +11,7 @@
|
||||
for applying resource management to their virtual machines and containers.
|
||||
</p>
|
||||
|
||||
<h2><a name="requiredControllers">Required controllers</a></h2>
|
||||
<h2><a id="requiredControllers">Required controllers</a></h2>
|
||||
|
||||
<p>
|
||||
The control groups filesystem supports multiple "controllers". By default
|
||||
@ -42,7 +42,7 @@
|
||||
which use them will cease to operate.
|
||||
</p>
|
||||
|
||||
<h2><a name="currentLayout">Current cgroups layout</a></h2>
|
||||
<h2><a id="currentLayout">Current cgroups layout</a></h2>
|
||||
|
||||
<p>
|
||||
As of libvirt 1.0.5 or later, the cgroups layout created by libvirt has been
|
||||
@ -63,14 +63,14 @@
|
||||
in two, one describing systemd hosts and the other non-systemd hosts.
|
||||
</p>
|
||||
|
||||
<h3><a name="currentLayoutSystemd">Systemd cgroups integration</a></h3>
|
||||
<h3><a id="currentLayoutSystemd">Systemd cgroups integration</a></h3>
|
||||
|
||||
<p>
|
||||
On hosts which use systemd, each consumer maps to a systemd scope unit,
|
||||
while partitions map to a system slice unit.
|
||||
</p>
|
||||
|
||||
<h4><a name="systemdScope">Systemd scope naming</a></h4>
|
||||
<h4><a id="systemdScope">Systemd scope naming</a></h4>
|
||||
|
||||
<p>
|
||||
The systemd convention is for the scope name of virtual machines / containers
|
||||
@ -83,7 +83,7 @@
|
||||
The scope names map directly to the cgroup directory names.
|
||||
</p>
|
||||
|
||||
<h4><a name="systemdSlice">Systemd slice naming</a></h4>
|
||||
<h4><a id="systemdSlice">Systemd slice naming</a></h4>
|
||||
|
||||
<p>
|
||||
The systemd convention for slice naming is that a slice should include the
|
||||
@ -96,7 +96,7 @@
|
||||
by libvirt will be associated with <code>machine.slice</code> by default.
|
||||
</p>
|
||||
|
||||
<h4><a name="systemdLayout">Systemd cgroup layout</a></h4>
|
||||
<h4><a id="systemdLayout">Systemd cgroup layout</a></h4>
|
||||
|
||||
<p>
|
||||
Given this, a possible systemd cgroups layout involving 3 qemu guests,
|
||||
@ -145,7 +145,7 @@ $ROOT
|
||||
+- machine-lxc\x2dcontainer3.scope
|
||||
</pre>
|
||||
|
||||
<h3><a name="currentLayoutGeneric">Non-systemd cgroups layout</a></h3>
|
||||
<h3><a id="currentLayoutGeneric">Non-systemd cgroups layout</a></h3>
|
||||
|
||||
<p>
|
||||
On hosts which do not use systemd, each consumer has a corresponding cgroup
|
||||
@ -206,7 +206,7 @@ $ROOT
|
||||
+- container3.libvirt-lxc
|
||||
</pre>
|
||||
|
||||
<h2><a name="customPartiton">Using custom partitions</a></h2>
|
||||
<h2><a id="customPartiton">Using custom partitions</a></h2>
|
||||
|
||||
<p>
|
||||
If there is a need to apply resource constraints to groups of
|
||||
@ -255,7 +255,7 @@ $ROOT
|
||||
later in this document did not support customization per guest.
|
||||
</p>
|
||||
|
||||
<h3><a name="createSystemd">Creating custom partitions (systemd)</a></h3>
|
||||
<h3><a id="createSystemd">Creating custom partitions (systemd)</a></h3>
|
||||
|
||||
<p>
|
||||
Given the XML config above, the admin on a systemd based host would
|
||||
@ -272,7 +272,7 @@ EOF
|
||||
# systemctl start machine-testing.slice
|
||||
</pre>
|
||||
|
||||
<h3><a name="createNonSystemd">Creating custom partitions (non-systemd)</a></h3>
|
||||
<h3><a id="createNonSystemd">Creating custom partitions (non-systemd)</a></h3>
|
||||
|
||||
<p>
|
||||
Given the XML config above, the admin on a non-systemd based host
|
||||
@ -291,7 +291,7 @@ EOF
|
||||
done
|
||||
</pre>
|
||||
|
||||
<h2><a name="resourceAPIs">Resource management APIs/commands</a></h2>
|
||||
<h2><a id="resourceAPIs">Resource management APIs/commands</a></h2>
|
||||
|
||||
<p>
|
||||
Since libvirt aims to provide an API which is portable across
|
||||
@ -354,7 +354,7 @@ swap_hard_limit: unlimited
|
||||
network interfaces.
|
||||
</p>
|
||||
|
||||
<h2><a name="legacyLayout">Legacy cgroups layout</a></h2>
|
||||
<h2><a id="legacyLayout">Legacy cgroups layout</a></h2>
|
||||
|
||||
<p>
|
||||
Prior to libvirt 1.0.5, the cgroups layout created by libvirt was different
|
||||
|
@ -2,11 +2,11 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<body>
|
||||
<h1><a name="installation">libvirt Installation</a></h1>
|
||||
<h1><a id="installation">libvirt Installation</a></h1>
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="compiling">Compiling a release tarball</a></h2>
|
||||
<h2><a id="compiling">Compiling a release tarball</a></h2>
|
||||
|
||||
<p>
|
||||
libvirt uses the standard configure/make/install steps:
|
||||
@ -58,7 +58,7 @@ $ <b>sudo</b> <i>make install</i></pre>
|
||||
to update your list of installed shared libs.
|
||||
</p>
|
||||
|
||||
<h2><a name="building">Building from a GIT checkout</a></h2>
|
||||
<h2><a id="building">Building from a GIT checkout</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt build process uses GNU autotools, so after obtaining a
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="security">Security Issues</a></h2>
|
||||
<h2><a id="security">Security Issues</a></h2>
|
||||
|
||||
<p>
|
||||
If you think that an issue with libvirt may have security
|
||||
@ -18,7 +18,7 @@
|
||||
<a href="securityprocess.html">security process</a> instead.
|
||||
</p>
|
||||
|
||||
<h2><a name="email">Mailing lists</a></h2>
|
||||
<h2><a id="email">Mailing lists</a></h2>
|
||||
|
||||
<p>
|
||||
There are three mailing-lists:
|
||||
@ -95,7 +95,7 @@
|
||||
page.
|
||||
</p>
|
||||
|
||||
<h2><a name="irc">IRC discussion</a></h2>
|
||||
<h2><a id="irc">IRC discussion</a></h2>
|
||||
|
||||
<p>
|
||||
Some of the libvirt developers may be found on IRC on the <a href="http://oftc.net">OFTC IRC</a>
|
||||
|
@ -11,7 +11,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="skills">Contributions required</a></h2>
|
||||
<h2><a id="skills">Contributions required</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt project is always looking for new contributors to
|
||||
@ -97,7 +97,7 @@
|
||||
these help forums.</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="comms">Communication</a></h2>
|
||||
<h2><a id="comms">Communication</a></h2>
|
||||
|
||||
<p>
|
||||
For full details on contacting other project contributors
|
||||
@ -106,7 +106,7 @@
|
||||
between contributors:
|
||||
</p>
|
||||
|
||||
<h3><a name="email">Mailing lists</a></h3>
|
||||
<h3><a id="email">Mailing lists</a></h3>
|
||||
|
||||
<p>
|
||||
The project has a number of
|
||||
@ -118,7 +118,7 @@
|
||||
to follow the traffic.
|
||||
</p>
|
||||
|
||||
<h3><a name="irc">Instant messaging / chat</a></h3>
|
||||
<h3><a id="irc">Instant messaging / chat</a></h3>
|
||||
|
||||
<p>
|
||||
Contributors to libvirt are encouraged to join the
|
||||
@ -127,7 +127,7 @@
|
||||
with others members.
|
||||
</p>
|
||||
|
||||
<h2><a name="outreach">Student / outreach coding programs</a></h2>
|
||||
<h2><a id="outreach">Student / outreach coding programs</a></h2>
|
||||
|
||||
<p>
|
||||
Since 2016, the libvirt project directly participates as an
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="description">Description</a></h2>
|
||||
<h2><a id="description">Description</a></h2>
|
||||
|
||||
<p>
|
||||
The C# libvirt bindings are a class library. They use a Microsoft
|
||||
@ -21,7 +21,7 @@
|
||||
|
||||
<p> </p>
|
||||
|
||||
<h2><a name="requirements">Requirements</a></h2>
|
||||
<h2><a id="requirements">Requirements</a></h2>
|
||||
|
||||
<p>
|
||||
These bindings depend upon the libvirt libraries being installed.
|
||||
@ -34,7 +34,7 @@
|
||||
<p> </p>
|
||||
|
||||
<!-- 2010-10-19 JC: Commented out until we have C# tarballs to download
|
||||
<h2><a name="getting">Getting them</a></h2>
|
||||
<h2><a id="getting">Getting them</a></h2>
|
||||
|
||||
<p>
|
||||
The latest versions of the libvirt C# bindings can be downloaded from:
|
||||
@ -46,7 +46,7 @@
|
||||
</ul>
|
||||
-->
|
||||
|
||||
<h2><a name="git">GIT source repository</a></h2>
|
||||
<h2><a id="git">GIT source repository</a></h2>
|
||||
<p>
|
||||
The C# bindings source code is maintained in a <a
|
||||
href="http://git-scm.com/">git</a> repository available on
|
||||
@ -67,7 +67,7 @@ git clone git://libvirt.org/libvirt-csharp.git
|
||||
|
||||
<p> </p>
|
||||
|
||||
<h2><a name="usage">Usage</a></h2>
|
||||
<h2><a id="usage">Usage</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt C# bindings class library exposes the <b>Libvirt</b>
|
||||
@ -118,7 +118,7 @@ git clone git://libvirt.org/libvirt-csharp.git
|
||||
|
||||
<p> </p>
|
||||
|
||||
<h2><a name="authors">Authors</a></h2>
|
||||
<h2><a id="authors">Authors</a></h2>
|
||||
|
||||
<p>
|
||||
The C# bindings are the work of Arnaud Champion
|
||||
@ -128,7 +128,7 @@ git clone git://libvirt.org/libvirt-csharp.git
|
||||
|
||||
<p> </p>
|
||||
|
||||
<h2><a name="notes">Test Configuration</a></h2>
|
||||
<h2><a id="notes">Test Configuration</a></h2>
|
||||
|
||||
<p>
|
||||
Testing is performed using the following configurations:
|
||||
@ -141,7 +141,7 @@ git clone git://libvirt.org/libvirt-csharp.git
|
||||
|
||||
<p> </p>
|
||||
|
||||
<h2><a name="type">Type Coverage</a></h2>
|
||||
<h2><a id="type">Type Coverage</a></h2>
|
||||
|
||||
<p>
|
||||
Coverage of the libvirt types is:
|
||||
@ -219,7 +219,7 @@ git clone git://libvirt.org/libvirt-csharp.git
|
||||
|
||||
<p> </p>
|
||||
|
||||
<h2><a name="funccover">Function Coverage</a></h2>
|
||||
<h2><a id="funccover">Function Coverage</a></h2>
|
||||
|
||||
<p>
|
||||
Coverage of the libvirt functions is:
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="releases">Project modules</a></h2>
|
||||
<h2><a id="releases">Project modules</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt project maintains a number of inter-related modules beyond
|
||||
@ -435,7 +435,7 @@
|
||||
<li><a href="https://libvirt.org/sources/">libvirt.org HTTPS server</a></li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="hourly">Hourly development snapshots</a></h2>
|
||||
<h2><a id="hourly">Hourly development snapshots</a></h2>
|
||||
|
||||
<p>
|
||||
Once an hour, an automated snapshot is made from the git server
|
||||
@ -450,7 +450,7 @@
|
||||
<li><a href="http://libvirt.org/sources/libvirt-git-snapshot.tar.xz">libvirt.org HTTP server</a></li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="schedule">Primary release schedule</a></h2>
|
||||
<h2><a id="schedule">Primary release schedule</a></h2>
|
||||
|
||||
<p>
|
||||
The core libvirt module follows a time based plan, with releases made
|
||||
@ -462,7 +462,7 @@
|
||||
independant ad-hoc releases with no fixed time schedle.
|
||||
</p>
|
||||
|
||||
<h2><a name="numbering">Release numbering</a></h2>
|
||||
<h2><a id="numbering">Release numbering</a></h2>
|
||||
|
||||
<p>
|
||||
Since libvirt 2.0.0, a time based version numbering rule
|
||||
@ -497,7 +497,7 @@
|
||||
digits.
|
||||
</p>
|
||||
|
||||
<h2><a name="maintenance">Maintenance releases</a></h2>
|
||||
<h2><a id="maintenance">Maintenance releases</a></h2>
|
||||
<p>
|
||||
In the git repository are several stable maintenance branches
|
||||
for the core library, matching the
|
||||
@ -525,7 +525,7 @@
|
||||
wiki page</a>.
|
||||
</p>
|
||||
|
||||
<h2><a name="git">GIT source repository</a></h2>
|
||||
<h2><a id="git">GIT source repository</a></h2>
|
||||
|
||||
<p>
|
||||
All modules maintained by the libvirt project have their primary
|
||||
|
@ -18,7 +18,7 @@
|
||||
network and storage driver active.
|
||||
</p>
|
||||
|
||||
<h2><a name="hypervisor">Hypervisor drivers</a></h2>
|
||||
<h2><a id="hypervisor">Hypervisor drivers</a></h2>
|
||||
|
||||
<p>
|
||||
The hypervisor drivers currently supported by libvirt are:
|
||||
@ -40,7 +40,7 @@
|
||||
<li><strong><a href="drvbhyve.html">Bhyve</a></strong> - The BSD Hypervisor</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="storage">Storage drivers</a></h2>
|
||||
<h2><a id="storage">Storage drivers</a></h2>
|
||||
|
||||
<ul>
|
||||
<li><strong><a href="storage.html#StorageBackendDir">Directory backend</a></strong></li>
|
||||
|
@ -31,7 +31,7 @@ $
|
||||
Additional information on bhyve could be obtained on <a href="http://bhyve.org/">bhyve.org</a>.
|
||||
</p>
|
||||
|
||||
<h2><a name="uri">Connections to the Bhyve driver</a></h2>
|
||||
<h2><a id="uri">Connections to the Bhyve driver</a></h2>
|
||||
<p>
|
||||
The libvirt bhyve driver is a single-instance privileged driver. Some sample
|
||||
connection URIs are:
|
||||
@ -43,7 +43,7 @@ bhyve+unix:///system (local access)
|
||||
bhyve+ssh://root@example.com/system (remote access, SSH tunnelled)
|
||||
</pre>
|
||||
|
||||
<h2><a name="exconfig">Example guest domain XML configurations</a></h2>
|
||||
<h2><a id="exconfig">Example guest domain XML configurations</a></h2>
|
||||
|
||||
<h3>Example config</h3>
|
||||
<p>
|
||||
@ -206,9 +206,9 @@ Note the addition of <bootloader>.
|
||||
|
||||
<p>Please refer to the <a href="#uefi">UEFI</a> section for a more detailed explanation.</p>
|
||||
|
||||
<h2><a name="usage">Guest usage / management</a></h2>
|
||||
<h2><a id="usage">Guest usage / management</a></h2>
|
||||
|
||||
<h3><a name="console">Connecting to a guest console</a></h3>
|
||||
<h3><a id="console">Connecting to a guest console</a></h3>
|
||||
|
||||
<p>
|
||||
Guest console connection is supported through the <code>nmdm</code> device. It could be enabled by adding
|
||||
@ -253,7 +253,7 @@ device) is:</p>
|
||||
|
||||
<pre>cu -l /dev/nmdm0B</pre>
|
||||
|
||||
<h3><a name="xmltonative">Converting from domain XML to Bhyve args</a></h3>
|
||||
<h3><a id="xmltonative">Converting from domain XML to Bhyve args</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh domxml-to-native</code> command can preview the actual
|
||||
@ -275,7 +275,7 @@ tweak them.</p>
|
||||
/usr/sbin/bhyve -c 2 -m 214 -A -I -H -P -s 0:0,hostbridge -s 3:0,virtio-net,tap0,mac=52:54:00:5d:74:e3 -s 2:0,virtio-blk,/home/user/vm1.img -s 1,lpc -l com1,/dev/nmdm0A vm1
|
||||
</pre>
|
||||
|
||||
<h3><a name="zfsvolume">Using ZFS volumes</a></h3>
|
||||
<h3><a id="zfsvolume">Using ZFS volumes</a></h3>
|
||||
|
||||
<p>It's possible to use ZFS volumes as disk devices <span class="since">since 1.2.8</span>.
|
||||
An example of domain XML device entry for that will look like:</p>
|
||||
@ -291,7 +291,7 @@ An example of domain XML device entry for that will look like:</p>
|
||||
<p>Please refer to the <a href="storage.html">Storage documentation</a> for more details on storage
|
||||
management.</p>
|
||||
|
||||
<h3><a name="grubbhyve">Using grub2-bhyve or Alternative Bootloaders</a></h3>
|
||||
<h3><a id="grubbhyve">Using grub2-bhyve or Alternative Bootloaders</a></h3>
|
||||
|
||||
<p>It's possible to boot non-FreeBSD guests by specifying an explicit
|
||||
bootloader, e.g. <code>grub-bhyve(1)</code>. Arguments to the bootloader may be
|
||||
@ -312,7 +312,7 @@ attempt to boot from the first partition in the disk image.</p>
|
||||
<p>Caveat: <code>bootloader_args</code> does not support any quoting.
|
||||
Filenames, etc, must not have spaces or they will be tokenized incorrectly.</p>
|
||||
|
||||
<h3><a name="uefi">Using UEFI bootrom, VNC, and USB tablet</a></h3>
|
||||
<h3><a id="uefi">Using UEFI bootrom, VNC, and USB tablet</a></h3>
|
||||
|
||||
<p><span class="since">Since 3.2.0</span>, in addition to <a href="#grubbhyve">grub-bhyve</a>,
|
||||
non-FreeBSD guests could be also booted using an UEFI boot ROM, provided both guest OS and
|
||||
@ -381,7 +381,7 @@ will be used. Please refer to the
|
||||
manual page and the <a href="https://wiki.freebsd.org/bhyve">bhyve wiki</a> for more details on using
|
||||
the <code>vgaconf</code> option.</p>
|
||||
|
||||
<h3><a name="clockconfig">Clock configuration</a></h3>
|
||||
<h3><a id="clockconfig">Clock configuration</a></h3>
|
||||
|
||||
<p>Originally bhyve supported only localtime for RTC. Support for UTC time was introduced in
|
||||
<a href="http://svnweb.freebsd.org/changeset/base/284894">r284894</a> for <i>10-STABLE</i> and
|
||||
@ -409,7 +409,7 @@ you'll need to explicitly specify 'localtime' in this case:</p>
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
<h3><a name="e1000">e1000 NIC</a></h3>
|
||||
<h3><a id="e1000">e1000 NIC</a></h3>
|
||||
|
||||
<p>As of <a href="https://svnweb.freebsd.org/changeset/base/302504">r302504</a> bhyve
|
||||
supports Intel e1000 network adapter emulation. It's supported in libvirt
|
||||
|
@ -11,7 +11,7 @@
|
||||
connect to a VMware vCenter 2.5/4.x/5.x (VPX).
|
||||
</p>
|
||||
|
||||
<h2><a name="project">Project Links</a></h2>
|
||||
<h2><a id="project">Project Links</a></h2>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
@ -20,7 +20,7 @@
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="prereq">Deployment pre-requisites</a></h2>
|
||||
<h2><a id="prereq">Deployment pre-requisites</a></h2>
|
||||
<p>
|
||||
None. Any out-of-the-box installation of VPX/ESX(i)/GSX should work. No
|
||||
preparations are required on the server side, no libvirtd must be
|
||||
@ -34,7 +34,7 @@
|
||||
VMware vSphere API</a>.
|
||||
</p>
|
||||
|
||||
<h2><a name="uri">Connections to the VMware ESX driver</a></h2>
|
||||
<h2><a id="uri">Connections to the VMware ESX driver</a></h2>
|
||||
<p>
|
||||
Some example remote connection URIs for the driver are:
|
||||
</p>
|
||||
@ -54,7 +54,7 @@ esx://example-esx.com/?no_verify=1 (ESX over HTTPS, but doesn't verify the s
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a name="uriformat">URI Format</a></h3>
|
||||
<h3><a id="uriformat">URI Format</a></h3>
|
||||
<p>
|
||||
URIs have this general form (<code>[...]</code> marks an optional part).
|
||||
</p>
|
||||
@ -93,7 +93,7 @@ vpx://example-vcenter.com/folder1/dc1/folder2/example-esx.com
|
||||
</pre>
|
||||
|
||||
|
||||
<h4><a name="extraparams">Extra parameters</a></h4>
|
||||
<h4><a id="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
|
||||
@ -188,7 +188,7 @@ vpx://example-vcenter.com/folder1/dc1/folder2/example-esx.com
|
||||
</table>
|
||||
|
||||
|
||||
<h3><a name="auth">Authentication</a></h3>
|
||||
<h3><a id="auth">Authentication</a></h3>
|
||||
<p>
|
||||
In order to perform any useful operation the driver needs to log into
|
||||
the ESX server. Therefore, only <code>virConnectOpenAuth</code> can be
|
||||
@ -208,7 +208,7 @@ vpx://example-vcenter.com/folder1/dc1/folder2/example-esx.com
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a name="certificates">Certificates for HTTPS</a></h3>
|
||||
<h3><a id="certificates">Certificates for HTTPS</a></h3>
|
||||
<p>
|
||||
By default the ESX driver uses HTTPS to communicate with an ESX server.
|
||||
Proper HTTPS communication requires correctly configured SSL
|
||||
@ -244,7 +244,7 @@ error: internal error curl_easy_perform() returned an error: Peer certificate ca
|
||||
</ul>
|
||||
|
||||
|
||||
<h3><a name="connproblems">Connection problems</a></h3>
|
||||
<h3><a id="connproblems">Connection problems</a></h3>
|
||||
<p>
|
||||
There are also other causes for connection problems than the
|
||||
<a href="#certificates">HTTPS certificate</a> related ones.
|
||||
@ -303,7 +303,7 @@ error: invalid argument in libvirt was built without the 'esx' driver
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="questions">Questions blocking tasks</a></h2>
|
||||
<h2><a id="questions">Questions blocking tasks</a></h2>
|
||||
<p>
|
||||
Some methods of the VI API start tasks, for example
|
||||
<code>PowerOnVM_Task()</code>. Such tasks may be blocked by questions
|
||||
@ -322,12 +322,12 @@ error: invalid argument in libvirt was built without the 'esx' driver
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a name="xmlspecial">Specialties in the domain XML config</a></h2>
|
||||
<h2><a id="xmlspecial">Specialties in the domain XML config</a></h2>
|
||||
<p>
|
||||
There are several specialties in the domain XML config for ESX domains.
|
||||
</p>
|
||||
|
||||
<h3><a name="restrictions">Restrictions</a></h3>
|
||||
<h3><a id="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.
|
||||
@ -347,7 +347,7 @@ error: invalid argument in libvirt was built without the 'esx' driver
|
||||
</ul>
|
||||
|
||||
|
||||
<h3><a name="datastore">Datastore references</a></h3>
|
||||
<h3><a id="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
|
||||
@ -366,7 +366,7 @@ error: invalid argument in libvirt was built without the 'esx' driver
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a name="macaddresses">MAC addresses</a></h3>
|
||||
<h3><a id="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
|
||||
@ -427,7 +427,7 @@ ethernet0.checkMACAddress = "false"
|
||||
</pre>
|
||||
|
||||
|
||||
<h3><a name="hardware">Available hardware</a></h3>
|
||||
<h3><a id="hardware">Available hardware</a></h3>
|
||||
<p>
|
||||
VMware ESX supports different models of SCSI controllers and network
|
||||
cards.
|
||||
@ -523,14 +523,14 @@ ethernet0.checkMACAddress = "false"
|
||||
</pre>
|
||||
|
||||
|
||||
<h2><a name="importexport">Import and export of domain XML configs</a></h2>
|
||||
<h2><a id="importexport">Import and export of domain XML configs</a></h2>
|
||||
<p>
|
||||
The ESX driver currently supports a native config format known as
|
||||
<code>vmware-vmx</code> to handle VMware VMX configs.
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a name="xmlimport">Converting from VMware VMX config to domain XML config</a></h3>
|
||||
<h3><a id="xmlimport">Converting from VMware VMX config to domain XML config</a></h3>
|
||||
<p>
|
||||
The <code>virsh domxml-from-native</code> provides a way to convert an
|
||||
existing VMware VMX config into a domain XML config that can then be
|
||||
@ -621,7 +621,7 @@ Enter root password for example.com:
|
||||
</pre>
|
||||
|
||||
|
||||
<h3><a name="xmlexport">Converting from domain XML config to VMware VMX config</a></h3>
|
||||
<h3><a id="xmlexport">Converting from domain XML config to VMware VMX config</a></h3>
|
||||
<p>
|
||||
The <code>virsh domxml-to-native</code> provides a way to convert a
|
||||
domain XML config into a VMware VMX config.
|
||||
@ -675,7 +675,7 @@ ethernet0.address = "00:50:56:25:48:C7"
|
||||
</pre>
|
||||
|
||||
|
||||
<h2><a name="xmlconfig">Example domain XML configs</a></h2>
|
||||
<h2><a id="xmlconfig">Example domain XML configs</a></h2>
|
||||
|
||||
<h3>Fedora11 on x86_64</h3>
|
||||
<pre>
|
||||
@ -704,7 +704,7 @@ ethernet0.address = "00:50:56:25:48:C7"
|
||||
</pre>
|
||||
|
||||
|
||||
<h2><a name="migration">Migration</a></h2>
|
||||
<h2><a id="migration">Migration</a></h2>
|
||||
<p>
|
||||
A migration cannot be initiated on an ESX server directly, a VMware
|
||||
vCenter is necessary for this. The <code>vcenter</code> query
|
||||
@ -749,7 +749,7 @@ Enter administrator password for example-vcenter.com:
|
||||
</pre>
|
||||
|
||||
|
||||
<h2><a name="scheduler">Scheduler configuration</a></h2>
|
||||
<h2><a id="scheduler">Scheduler configuration</a></h2>
|
||||
<p>
|
||||
The driver exposes the ESX CPU scheduler. The parameters listed below
|
||||
are available to control the scheduler.
|
||||
@ -780,7 +780,7 @@ Enter administrator password for example-vcenter.com:
|
||||
</dl>
|
||||
|
||||
|
||||
<h2><a name="tools">VMware tools</a></h2>
|
||||
<h2><a id="tools">VMware tools</a></h2>
|
||||
<p>
|
||||
Some actions require installed VMware tools. If the VMware tools are
|
||||
not installed in the guest and one of the actions below is to be
|
||||
@ -796,7 +796,7 @@ Enter administrator password for example-vcenter.com:
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="links">Links</a></h2>
|
||||
<h2><a id="links">Links</a></h2>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="http://www.vmware.com/support/developer/vc-sdk/">
|
||||
|
@ -9,7 +9,7 @@
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a name="project">Project Links</a></h2>
|
||||
<h2><a id="project">Project Links</a></h2>
|
||||
<ul>
|
||||
<li>
|
||||
The <a href="http://www.microsoft.com/hyper-v-server/">Microsoft Hyper-V</a>
|
||||
@ -18,7 +18,7 @@
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="uri">Connections to the Microsoft Hyper-V driver</a></h2>
|
||||
<h2><a id="uri">Connections to the Microsoft Hyper-V driver</a></h2>
|
||||
<p>
|
||||
Some example remote connection URIs for the driver are:
|
||||
</p>
|
||||
@ -36,7 +36,7 @@ hyperv://example-hyperv.com/?transport=http (over HTTP)
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a name="uriformat">URI Format</a></h3>
|
||||
<h3><a id="uriformat">URI Format</a></h3>
|
||||
<p>
|
||||
URIs have this general form (<code>[...]</code> marks an optional part).
|
||||
</p>
|
||||
@ -49,7 +49,7 @@ hyperv://[username@]hostname[:port]/[?extraparameters]
|
||||
</p>
|
||||
|
||||
|
||||
<h4><a name="extraparams">Extra parameters</a></h4>
|
||||
<h4><a id="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
|
||||
@ -83,7 +83,7 @@ hyperv://[username@]hostname[:port]/[?extraparameters]
|
||||
</table>
|
||||
|
||||
|
||||
<h3><a name="auth">Authentication</a></h3>
|
||||
<h3><a id="auth">Authentication</a></h3>
|
||||
<p>
|
||||
In order to perform any useful operation the driver needs to log into
|
||||
the Hyper-V server. Therefore, only <code>virConnectOpenAuth</code> can
|
||||
|
@ -18,7 +18,7 @@ particular sVirt for mandatory access control, auditing of operations,
|
||||
integration with control groups and many other features.
|
||||
</p>
|
||||
|
||||
<h2><a name="cgroups">Control groups Requirements</a></h2>
|
||||
<h2><a id="cgroups">Control groups Requirements</a></h2>
|
||||
|
||||
<p>
|
||||
In order to control the resource usage of processes inside containers, the
|
||||
@ -32,7 +32,7 @@ init service will be required. For further information, consult the general
|
||||
libvirt <a href="cgroups.html">cgroups documentation</a>.
|
||||
</p>
|
||||
|
||||
<h2><a name="namespaces">Namespace requirements</a></h2>
|
||||
<h2><a id="namespaces">Namespace requirements</a></h2>
|
||||
|
||||
<p>
|
||||
In order to separate processes inside a container from those in the
|
||||
@ -47,9 +47,9 @@ configured UID/GID mapping is a pre-requisite to making containers
|
||||
secure, in the absence of sVirt confinement.</strong>
|
||||
</p>
|
||||
|
||||
<h2><a name="init">Default container setup</a></h2>
|
||||
<h2><a id="init">Default container setup</a></h2>
|
||||
|
||||
<h3><a name="cliargs">Command line arguments</a></h3>
|
||||
<h3><a id="cliargs">Command line arguments</a></h3>
|
||||
|
||||
<p>
|
||||
When the container "init" process is started, it will typically
|
||||
@ -70,7 +70,7 @@ would use the following XML
|
||||
</os>
|
||||
</pre>
|
||||
|
||||
<h3><a name="envvars">Environment variables</a></h3>
|
||||
<h3><a id="envvars">Environment variables</a></h3>
|
||||
|
||||
<p>
|
||||
When the container "init" process is started, it will be given several useful
|
||||
@ -108,7 +108,7 @@ Use of this is discouraged, in favour of passing arguments directly to the
|
||||
container init process via the <code>initarg</code> config element.</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="fsmounts">Filesystem mounts</a></h3>
|
||||
<h3><a id="fsmounts">Filesystem mounts</a></h3>
|
||||
|
||||
<p>
|
||||
In the absence of any explicit configuration, the container will
|
||||
@ -131,7 +131,7 @@ only expose the sub-tree associated with the container</li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h3><a name="devnodes">Device nodes</a></h3>
|
||||
<h3><a id="devnodes">Device nodes</a></h3>
|
||||
|
||||
<p>
|
||||
The container init process will be started with <code>CAP_MKNOD</code>
|
||||
@ -178,7 +178,7 @@ Further block or character devices will be made available to containers
|
||||
depending on their configuration.
|
||||
</p>
|
||||
|
||||
<h2><a name="security">Security considerations</a></h2>
|
||||
<h2><a id="security">Security considerations</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt LXC driver is fairly flexible in how it can be configured,
|
||||
@ -190,7 +190,7 @@ isolation between a container and the host must ensure that they are
|
||||
writing a suitable configuration.
|
||||
</p>
|
||||
|
||||
<h3><a name="securenetworking">Network isolation</a></h3>
|
||||
<h3><a id="securenetworking">Network isolation</a></h3>
|
||||
|
||||
<p>
|
||||
If the guest configuration does not list any network interfaces,
|
||||
@ -205,7 +205,7 @@ namespace is not wanted, then applications should set the
|
||||
<code><features>....</features></code> element.
|
||||
</p>
|
||||
|
||||
<h3><a name="securefs">Filesystem isolation</a></h3>
|
||||
<h3><a id="securefs">Filesystem isolation</a></h3>
|
||||
|
||||
<p>
|
||||
If the guest configuration does not list any filesystems, then
|
||||
@ -250,7 +250,7 @@ a bind mount to hide them. This is particularly important for the
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a name="secureusers">User and group isolation</a></h3>
|
||||
<h3><a id="secureusers">User and group isolation</a></h3>
|
||||
|
||||
<p>
|
||||
If the guest configuration does not list any ID mapping, then the
|
||||
@ -281,7 +281,7 @@ causes libvirt to activate the user namespace feature.
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a name="activation">Systemd Socket Activation Integration</a></h2>
|
||||
<h2><a id="activation">Systemd Socket Activation Integration</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt LXC driver provides the ability to pass across pre-opened file
|
||||
@ -477,7 +477,7 @@ configured to block read/write/mknod from all devices except those
|
||||
that a container is authorized to use.
|
||||
</p>
|
||||
|
||||
<h2><a name="exconfig">Example configurations</a></h2>
|
||||
<h2><a id="exconfig">Example configurations</a></h2>
|
||||
|
||||
<h3>Example config version 1</h3>
|
||||
<p></p>
|
||||
@ -542,7 +542,7 @@ debootstrap, whatever) under /opt/vm-1-root:
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
<h2><a name="capabilities">Altering the available capabilities</a></h2>
|
||||
<h2><a id="capabilities">Altering the available capabilities</a></h2>
|
||||
|
||||
<p>
|
||||
By default the libvirt LXC driver drops some capabilities among which CAP_MKNOD.
|
||||
@ -590,7 +590,7 @@ Note that allowing capabilities that are normally dropped by default can serious
|
||||
affect the security of the container and the host.
|
||||
</p>
|
||||
|
||||
<h2><a name="share">Inherit namespaces</a></h2>
|
||||
<h2><a id="share">Inherit namespaces</a></h2>
|
||||
|
||||
<p>
|
||||
Libvirt allows you to inherit the namespace from container/process just like lxc tools
|
||||
@ -615,7 +615,7 @@ ignored.
|
||||
The use of namespace passthrough requires libvirt >= 1.2.19
|
||||
</p>
|
||||
|
||||
<h2><a name="usage">Container usage / management</a></h2>
|
||||
<h2><a id="usage">Container usage / management</a></h2>
|
||||
|
||||
<p>
|
||||
As with any libvirt virtualization driver, LXC containers can be
|
||||
@ -629,7 +629,7 @@ and LXC. For further details about usage of virsh consult its
|
||||
manual page.
|
||||
</p>
|
||||
|
||||
<h3><a name="usageSave">Defining (saving) container configuration</a></h3>
|
||||
<h3><a id="usageSave">Defining (saving) container configuration</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh define</code> command takes an XML configuration
|
||||
@ -640,7 +640,7 @@ document and loads it into libvirt, saving the configuration on disk
|
||||
# virsh -c lxc:/// define myguest.xml
|
||||
</pre>
|
||||
|
||||
<h3><a name="usageView">Viewing container configuration</a></h3>
|
||||
<h3><a id="usageView">Viewing container configuration</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh dumpxml</code> command can be used to view the
|
||||
@ -655,7 +655,7 @@ using the <code>--inactive</code> flag
|
||||
# virsh -c lxc:/// dumpxml myguest
|
||||
</pre>
|
||||
|
||||
<h3><a name="usageStart">Starting containers</a></h3>
|
||||
<h3><a id="usageStart">Starting containers</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh start</code> command can be used to start a
|
||||
@ -677,7 +677,7 @@ by libvirt, using the <code>virsh create</code> command.
|
||||
</pre>
|
||||
|
||||
|
||||
<h3><a name="usageStop">Stopping containers</a></h3>
|
||||
<h3><a id="usageStop">Stopping containers</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh shutdown</code> command can be used
|
||||
@ -702,7 +702,7 @@ request, it can be forcibly stopped using the <code>virsh destroy</code>
|
||||
</pre>
|
||||
|
||||
|
||||
<h3><a name="usageReboot">Rebooting a container</a></h3>
|
||||
<h3><a id="usageReboot">Rebooting a container</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh reboot</code> command can be used
|
||||
@ -717,7 +717,7 @@ to PID 1 inside the container.
|
||||
# virsh -c lxc:/// reboot myguest
|
||||
</pre>
|
||||
|
||||
<h3><a name="usageDelete">Undefining (deleting) a container configuration</a></h3>
|
||||
<h3><a id="usageDelete">Undefining (deleting) a container configuration</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh undefine</code> command can be used to delete the
|
||||
@ -729,7 +729,7 @@ running, this will turn it into a "transient" guest.
|
||||
# virsh -c lxc:/// undefine myguest
|
||||
</pre>
|
||||
|
||||
<h3><a name="usageConnect">Connecting to a container console</a></h3>
|
||||
<h3><a id="usageConnect">Connecting to a container console</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh console</code> command can be used to connect
|
||||
@ -752,7 +752,7 @@ as 'console0', 'console1', 'console2', etc.
|
||||
# virsh -c lxc:/// console myguest --devname console1
|
||||
</pre>
|
||||
|
||||
<h3><a name="usageEnter">Running commands in a container</a></h3>
|
||||
<h3><a id="usageEnter">Running commands in a container</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh lxc-enter-namespace</code> command can be used
|
||||
@ -764,7 +764,7 @@ and then execute an arbitrary command.
|
||||
# virsh -c lxc:/// lxc-enter-namespace myguest -- /bin/ls -al /dev
|
||||
</pre>
|
||||
|
||||
<h3><a name="usageTop">Monitoring container utilization</a></h3>
|
||||
<h3><a id="usageTop">Monitoring container utilization</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virt-top</code> command can be used to monitor the
|
||||
@ -776,7 +776,7 @@ host
|
||||
# virt-top -c lxc:///
|
||||
</pre>
|
||||
|
||||
<h3><a name="usageConvert">Converting LXC container configuration</a></h3>
|
||||
<h3><a id="usageConvert">Converting LXC container configuration</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh domxml-from-native</code> command can be used to convert
|
||||
|
@ -98,7 +98,7 @@
|
||||
|
||||
<ul id="toc"/>
|
||||
|
||||
<h2><a name="PCI">PCI host devices</a></h2>
|
||||
<h2><a id="PCI">PCI host devices</a></h2>
|
||||
<dl>
|
||||
<dt><code>capability</code></dt>
|
||||
<dd>
|
||||
@ -139,7 +139,7 @@
|
||||
element will be included for each capability the device supports.
|
||||
</p>
|
||||
|
||||
<h3><a name="SRIOVCap">SR-IOV capability</a></h3>
|
||||
<h3><a id="SRIOVCap">SR-IOV capability</a></h3>
|
||||
<p>
|
||||
Single root input/output virtualization (SR-IOV) allows sharing of the
|
||||
PCIe resources by multiple virtual environments. That is achieved by
|
||||
@ -186,7 +186,7 @@
|
||||
...
|
||||
<device></pre>
|
||||
|
||||
<h3><a name="MDEVCap">MDEV capability</a></h3>
|
||||
<h3><a id="MDEVCap">MDEV capability</a></h3>
|
||||
<p>
|
||||
A PCI device capable of creating mediated devices will include a nested
|
||||
capability <code>mdev_types</code> which enumerates all supported mdev
|
||||
@ -252,7 +252,7 @@
|
||||
</capability>
|
||||
</device></pre>
|
||||
|
||||
<h2><a name="MDEV">Mediated devices (MDEVs)</a></h2>
|
||||
<h2><a id="MDEV">Mediated devices (MDEVs)</a></h2>
|
||||
<p>
|
||||
Mediated devices (<span class="since">Since 3.2.0</span>) are software
|
||||
devices defining resource allocation on the backing physical device which
|
||||
|
@ -15,7 +15,7 @@
|
||||
undue trouble.
|
||||
</p>
|
||||
|
||||
<h2><a name="project">Project Links</a></h2>
|
||||
<h2><a id="project">Project Links</a></h2>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
@ -24,7 +24,7 @@
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="connections">Connections to OpenVZ driver</a></h2>
|
||||
<h2><a id="connections">Connections to OpenVZ driver</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt OpenVZ driver is a single-instance privileged driver,
|
||||
@ -40,7 +40,7 @@ openvz+tcp://example.com/system (remote access, SASl/Kerberos)
|
||||
openvz+ssh://root@example.com/system (remote access, SSH tunnelled)
|
||||
</pre>
|
||||
|
||||
<h2><a name="notes">Notes on bridged networking</a></h2>
|
||||
<h2><a id="notes">Notes on bridged networking</a></h2>
|
||||
|
||||
<p>
|
||||
Bridged networking enables a guest domain (ie container) to have its
|
||||
@ -49,7 +49,7 @@ openvz+ssh://root@example.com/system (remote access, SSH tunnelled)
|
||||
the host OS.
|
||||
</p>
|
||||
|
||||
<h3><a name="host">Host network devices</a></h3>
|
||||
<h3><a id="host">Host network devices</a></h3>
|
||||
|
||||
<p>
|
||||
One or more of the physical devices must be attached to a bridge. The
|
||||
@ -60,7 +60,7 @@ openvz+ssh://root@example.com/system (remote access, SSH tunnelled)
|
||||
physical device "eth0", or a bonding device "bond0".
|
||||
</p>
|
||||
|
||||
<h3><a name="tools">OpenVZ tools configuration</a></h3>
|
||||
<h3><a id="tools">OpenVZ tools configuration</a></h3>
|
||||
|
||||
<p>
|
||||
OpenVZ releases later than 3.0.23 ship with a standard network device
|
||||
@ -85,7 +85,7 @@ EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a name="example">Example guest domain XML configuration</a></h2>
|
||||
<h2><a id="example">Example guest domain XML configuration</a></h2>
|
||||
|
||||
<p>
|
||||
The current libvirt OpenVZ driver has a restriction that the
|
||||
|
@ -10,7 +10,7 @@
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a name="project">Project Links</a></h2>
|
||||
<h2><a id="project">Project Links</a></h2>
|
||||
<ul>
|
||||
<li>
|
||||
The <a href="http://www-03.ibm.com/systems/power/software/virtualization/index.html">IBM
|
||||
@ -19,7 +19,7 @@
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="uri">Connections to the PowerVM driver</a></h2>
|
||||
<h2><a id="uri">Connections to the PowerVM driver</a></h2>
|
||||
<p>
|
||||
Some example remote connection URIs for the driver are:
|
||||
</p>
|
||||
@ -38,7 +38,7 @@ phyp://user@ivm/system (IVM connection)
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a name="uriformat">URI Format</a></h3>
|
||||
<h3><a id="uriformat">URI Format</a></h3>
|
||||
<p>
|
||||
URIs have this general form (<code>[...]</code> marks an
|
||||
optional part, <code>{...|...}</code> marks a mandatory choice).
|
||||
|
@ -11,7 +11,7 @@
|
||||
version 0.12.0 or later.
|
||||
</p>
|
||||
|
||||
<h2><a name="project">Project Links</a></h2>
|
||||
<h2><a id="project">Project Links</a></h2>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
@ -23,7 +23,7 @@
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="prereq">Deployment pre-requisites</a></h2>
|
||||
<h2><a id="prereq">Deployment pre-requisites</a></h2>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
@ -43,7 +43,7 @@
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="uris">Connections to QEMU driver</a></h2>
|
||||
<h2><a id="uris">Connections to QEMU driver</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt QEMU driver is a multi-instance driver, providing a single
|
||||
@ -63,14 +63,14 @@ qemu+tcp://example.com/system (remote access, SASl/Kerberos)
|
||||
qemu+ssh://root@example.com/system (remote access, SSH tunnelled)
|
||||
</pre>
|
||||
|
||||
<h2><a name="security">Driver security architecture</a></h2>
|
||||
<h2><a id="security">Driver security architecture</a></h2>
|
||||
|
||||
<p>
|
||||
There are multiple layers to security in the QEMU driver, allowing for
|
||||
flexibility in the use of QEMU based virtual machines.
|
||||
</p>
|
||||
|
||||
<h3><a name="securitydriver">Driver instances</a></h3>
|
||||
<h3><a id="securitydriver">Driver instances</a></h3>
|
||||
|
||||
<p>
|
||||
As explained above there are two ways to access the QEMU driver
|
||||
@ -94,7 +94,7 @@ qemu+ssh://root@example.com/system (remote access, SSH tunnelled)
|
||||
elevated privileges.
|
||||
</p>
|
||||
|
||||
<h3><a name="securitydac">POSIX users/groups</a></h3>
|
||||
<h3><a id="securitydac">POSIX users/groups</a></h3>
|
||||
|
||||
<p>
|
||||
In the "session" instance, the POSIX users/groups model restricts QEMU
|
||||
@ -187,7 +187,7 @@ chmod o+x /path/to/directory
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h3><a name="securitycap">Linux process capabilities</a></h3>
|
||||
<h3><a id="securitycap">Linux process capabilities</a></h3>
|
||||
|
||||
<p>
|
||||
The libvirt QEMU driver has a build time option allowing it to use
|
||||
@ -224,7 +224,7 @@ chmod o+x /path/to/directory
|
||||
to changing the <code>/etc/libvirt/qemu.conf</code> settings.
|
||||
</p>
|
||||
|
||||
<h3><a name="securityselinux">SELinux basic confinement</a></h3>
|
||||
<h3><a id="securityselinux">SELinux basic confinement</a></h3>
|
||||
|
||||
<p>
|
||||
The basic SELinux protection for QEMU virtual machines is intended to
|
||||
@ -255,7 +255,7 @@ chmod o+x /path/to/directory
|
||||
SELinux boolean.
|
||||
</p>
|
||||
|
||||
<h3><a name="securitysvirt">SELinux sVirt confinement</a></h3>
|
||||
<h3><a id="securitysvirt">SELinux sVirt confinement</a></h3>
|
||||
|
||||
<p>
|
||||
The SELinux sVirt protection for QEMU virtual machines builds to the
|
||||
@ -305,7 +305,7 @@ chmod o+x /path/to/directory
|
||||
file can be used to change the setting to <code>security_driver="none"</code>
|
||||
</p>
|
||||
|
||||
<h3><a name="securitysvirtaa">AppArmor sVirt confinement</a></h3>
|
||||
<h3><a id="securitysvirtaa">AppArmor sVirt confinement</a></h3>
|
||||
|
||||
<p>
|
||||
When using basic AppArmor protection for the libvirtd daemon and
|
||||
@ -373,7 +373,7 @@ chmod o+x /path/to/directory
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a name="securityacl">Cgroups device ACLs</a></h3>
|
||||
<h3><a id="securityacl">Cgroups device ACLs</a></h3>
|
||||
|
||||
<p>
|
||||
Recent Linux kernels have a capability known as "cgroups" which is used
|
||||
@ -416,7 +416,7 @@ mount -t cgroup none /dev/cgroup -o devices
|
||||
<code>/dev/cgroup/libvirt/qemu/$VMNAME/</code>
|
||||
</p>
|
||||
|
||||
<h2><a name="imex">Import and export of libvirt domain XML configs</a></h2>
|
||||
<h2><a id="imex">Import and export of libvirt domain XML configs</a></h2>
|
||||
|
||||
<p>The QEMU driver currently supports a single native
|
||||
config format known as <code>qemu-argv</code>. The data for this format
|
||||
@ -424,7 +424,7 @@ mount -t cgroup none /dev/cgroup -o devices
|
||||
then the QEMu binary name, finally followed by the QEMU command line
|
||||
arguments</p>
|
||||
|
||||
<h3><a name="xmlimport">Converting from QEMU args to domain XML</a></h3>
|
||||
<h3><a id="xmlimport">Converting from QEMU args to domain XML</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh domxml-from-native</code> provides a way to
|
||||
@ -473,7 +473,7 @@ $ virsh domxml-from-native qemu-argv demo.args
|
||||
|
||||
<p>NB, don't include the literal \ in the args, put everything on one line</p>
|
||||
|
||||
<h3><a name="xmlexport">Converting from domain XML to QEMU args</a></h3>
|
||||
<h3><a id="xmlexport">Converting from domain XML to QEMU args</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh domxml-to-native</code> provides a way to convert a
|
||||
@ -515,7 +515,7 @@ $ virsh domxml-to-native qemu-argv demo.xml
|
||||
-serial none -parallel none -usb
|
||||
</pre>
|
||||
|
||||
<h2><a name="qemucommand">Pass-through of arbitrary qemu
|
||||
<h2><a id="qemucommand">Pass-through of arbitrary qemu
|
||||
commands</a></h2>
|
||||
|
||||
<p>Libvirt provides an XML namespace and an optional
|
||||
@ -582,7 +582,7 @@ $ virsh domxml-to-native qemu-argv demo.xml
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
<h2><a name="xmlconfig">Example domain XML config</a></h2>
|
||||
<h2><a id="xmlconfig">Example domain XML config</a></h2>
|
||||
|
||||
<h3>QEMU emulated guest on x86_64</h3>
|
||||
|
||||
|
@ -13,7 +13,7 @@
|
||||
has pre-created TAP devices.
|
||||
</p>
|
||||
|
||||
<h2><a name="project">Project Links</a></h2>
|
||||
<h2><a id="project">Project Links</a></h2>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
|
@ -8,7 +8,7 @@
|
||||
from version 2.2 onwards.
|
||||
</p>
|
||||
|
||||
<h2><a name="project">Project Links</a></h2>
|
||||
<h2><a id="project">Project Links</a></h2>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
@ -43,7 +43,7 @@ vbox+ssh://user@example.com/session (remote access, SSH tunnelled)
|
||||
work is completed to get the libvirtd daemon working there.</strong>
|
||||
</p>
|
||||
|
||||
<h2><a name="xmlconfig">Example domain XML config</a></h2>
|
||||
<h2><a id="xmlconfig">Example domain XML config</a></h2>
|
||||
|
||||
<pre>
|
||||
<domain type='vbox'>
|
||||
|
@ -9,7 +9,7 @@
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a name="project">Project Links</a></h2>
|
||||
<h2><a id="project">Project Links</a></h2>
|
||||
<ul>
|
||||
<li>
|
||||
The <a href="http://www.odin.com/products/virtuozzo/">Virtuozzo</a> Solution.
|
||||
@ -17,7 +17,7 @@
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="uri">Connections to the Virtuozzo driver</a></h2>
|
||||
<h2><a id="uri">Connections to the Virtuozzo driver</a></h2>
|
||||
<p>
|
||||
The libvirt Virtuozzo driver is a single-instance privileged driver, with a driver name of 'virtuozzo'. Some example connection URIs for the libvirt driver are:
|
||||
</p>
|
||||
@ -29,7 +29,7 @@ vz+tcp://example.com/system (remote access, SASl/Kerberos)
|
||||
vz+ssh://root@example.com/system (remote access, SSH tunnelled)
|
||||
</pre>
|
||||
|
||||
<h2><a name="example">Example guest domain XML configuration</a></h2>
|
||||
<h2><a id="example">Example guest domain XML configuration</a></h2>
|
||||
|
||||
<p>
|
||||
Virtuozzo driver require at least one hard disk for new domains
|
||||
|
@ -15,7 +15,7 @@
|
||||
from <a href="http://www.vmware.com/support/developer/vix-api/">here</a>.
|
||||
</p>
|
||||
|
||||
<h2><a name="project">Project Links</a></h2>
|
||||
<h2><a id="project">Project Links</a></h2>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
@ -51,7 +51,7 @@ vmwarews+tcp://user@example.com/session (remote access to VMware Workstation, S
|
||||
vmwarews+ssh://user@example.com/session (remote access to VMware Workstation, SSH tunnelled)
|
||||
</pre>
|
||||
|
||||
<h2><a name="xmlconfig">Example domain XML config</a></h2>
|
||||
<h2><a id="xmlconfig">Example domain XML config</a></h2>
|
||||
|
||||
<pre>
|
||||
<domain type='vmware'>
|
||||
|
@ -11,7 +11,7 @@
|
||||
on any Xen release from 3.0.1 onwards.
|
||||
</p>
|
||||
|
||||
<h2><a name="project">Project Links</a></h2>
|
||||
<h2><a id="project">Project Links</a></h2>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
@ -20,7 +20,7 @@
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="prereq">Deployment pre-requisites</a></h2>
|
||||
<h2><a id="prereq">Deployment pre-requisites</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt Xen driver uses a combination of channels to manage Xen
|
||||
@ -65,7 +65,7 @@
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="uri">Connections to Xen driver</a></h2>
|
||||
<h2><a id="uri">Connections to Xen driver</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt Xen driver is a single-instance privileged driver,
|
||||
@ -81,7 +81,7 @@ xen+tcp://example.com/ (remote access, SASl/Kerberos)
|
||||
xen+ssh://root@example.com/ (remote access, SSH tunnelled)
|
||||
</pre>
|
||||
|
||||
<h2><a name="imex">Import and export of libvirt domain XML configs</a></h2>
|
||||
<h2><a id="imex">Import and export of libvirt domain XML configs</a></h2>
|
||||
|
||||
<p>The Xen driver currently supports two native
|
||||
config formats. The first known as <code>xen-xm</code> is the format
|
||||
@ -89,7 +89,7 @@ xen+ssh://root@example.com/ (remote access, SSH tunnelled)
|
||||
known as <code>xen-sxpr</code>, is the format used for interacting
|
||||
with the XenD's legacy HTTP RPC service.</p>
|
||||
|
||||
<h3><a name="xmlimport">Converting from XM config files to domain XML</a></h3>
|
||||
<h3><a id="xmlimport">Converting from XM config files to domain XML</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh domxml-from-native</code> provides a way to convert an
|
||||
@ -135,7 +135,7 @@ xen+ssh://root@example.com/ (remote access, SSH tunnelled)
|
||||
</devices>
|
||||
</domain></pre>
|
||||
|
||||
<h3><a name="xmlexport">Converting from domain XML to XM config files</a></h3>
|
||||
<h3><a id="xmlexport">Converting from domain XML to XM config files</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>virsh domxml-to-native</code> provides a way to convert a
|
||||
@ -163,7 +163,7 @@ vnclisten = "0.0.0.0"
|
||||
disk = [ "tap:aio:/var/lib/xen/images/rhel5pv.img,xvda,w", "tap:qcow:/root/qcow1-xen.img,xvdd,w" ]
|
||||
vif = [ "mac=00:16:3e:60:36:ba,bridge=virbr0,script=vif-bridge,vifname=vif5.0" ]</pre>
|
||||
|
||||
<h2><a name="xmlconfig">Example domain XML config</a></h2>
|
||||
<h2><a id="xmlconfig">Example domain XML config</a></h2>
|
||||
|
||||
<p>
|
||||
Below are some example XML configurations for Xen guest domains.
|
||||
|
@ -35,8 +35,7 @@
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h3><a name="name-fw-virtual-network-driver"
|
||||
id="id-fw-virtual-network-driver">The virtual network driver</a>
|
||||
<h3><a id="fw-virtual-network-driver">The virtual network driver</a>
|
||||
</h3>
|
||||
<p>The typical configuration for guests is to use bridging of the
|
||||
physical NIC on the host to connect the guest directly to the LAN.
|
||||
@ -130,8 +129,7 @@ MASQUERADE all -- * * 192.168.122.0/24 !192.168.122.0/24</pre>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h3><a name="name-fw-network-filter-driver"
|
||||
id="id-fw-network-filter-driver">The network filter driver</a>
|
||||
<h3><a id="fw-network-filter-driver">The network filter driver</a>
|
||||
</h3>
|
||||
<p>This driver provides a fully configurable network filtering capability
|
||||
that leverages ebtables, iptables and ip6tables. This was written by
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="elements">Element and attribute overview</a></h2>
|
||||
<h2><a id="elements">Element and attribute overview</a></h2>
|
||||
|
||||
<p>As new virtualization engine support gets added to libvirt, and to
|
||||
handle cases like QEMU supporting a variety of emulations, a query
|
||||
@ -28,7 +28,7 @@
|
||||
the set of architectures the host can run at the moment.</p>
|
||||
|
||||
|
||||
<h3><a name="elementHost">Host capabilities</a></h3>
|
||||
<h3><a id="elementHost">Host capabilities</a></h3>
|
||||
|
||||
<p>The <code><host/></code> element consists of the following child
|
||||
elements:</p>
|
||||
@ -61,7 +61,7 @@
|
||||
</dl>
|
||||
|
||||
|
||||
<h3><a name="elementGuest">Guest capabilities</a></h3>
|
||||
<h3><a id="elementGuest">Guest capabilities</a></h3>
|
||||
|
||||
<p>While the <a href="#elementHost">previous section</a> aims at host
|
||||
capabilities, this one focuses on capabilities available to a guest
|
||||
@ -138,7 +138,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementExamples">Examples</a></h3>
|
||||
<h3><a id="elementExamples">Examples</a></h3>
|
||||
|
||||
<p>For example, in the case of a 64-bit machine with hardware
|
||||
virtualization capabilities enabled in the chip and
|
||||
|
@ -14,7 +14,7 @@
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a name="elements">Element and attribute overview</a></h2>
|
||||
<h2><a id="elements">Element and attribute overview</a></h2>
|
||||
|
||||
<p>
|
||||
The root element required for all virtual machines is
|
||||
@ -28,7 +28,7 @@
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a name="elementsMetadata">General metadata</a></h3>
|
||||
<h3><a id="elementsMetadata">General metadata</a></h3>
|
||||
|
||||
<pre>
|
||||
<domain type='xen' id='3'>
|
||||
@ -82,14 +82,14 @@
|
||||
element). <span class="since">Since 0.9.10</span></dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsOS">Operating system booting</a></h3>
|
||||
<h3><a id="elementsOS">Operating system booting</a></h3>
|
||||
|
||||
<p>
|
||||
There are a number of different ways to boot virtual machines
|
||||
each with their own pros and cons.
|
||||
</p>
|
||||
|
||||
<h4><a name="elementsOSBIOS">BIOS bootloader</a></h4>
|
||||
<h4><a id="elementsOSBIOS">BIOS bootloader</a></h4>
|
||||
|
||||
<p>
|
||||
Booting via the BIOS is available for hypervisors supporting
|
||||
@ -229,7 +229,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsOSBootloader">Host bootloader</a></h4>
|
||||
<h4><a id="elementsOSBootloader">Host bootloader</a></h4>
|
||||
|
||||
<p>
|
||||
Hypervisors employing paravirtualization do not usually emulate
|
||||
@ -262,7 +262,7 @@
|
||||
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsOSKernel">Direct kernel boot</a></h4>
|
||||
<h4><a id="elementsOSKernel">Direct kernel boot</a></h4>
|
||||
|
||||
<p>
|
||||
When installing a new guest OS it is often useful to boot directly
|
||||
@ -315,7 +315,7 @@
|
||||
<span class="since">Since 1.3.5 (QEMU only)</span></dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsOSContainer">Container boot</a></h4>
|
||||
<h4><a id="elementsOSContainer">Container boot</a></h4>
|
||||
|
||||
<p>
|
||||
When booting a domain using container based virtualization, instead
|
||||
@ -379,7 +379,7 @@
|
||||
</pre>
|
||||
|
||||
|
||||
<h3><a name="elementsSysinfo">SMBIOS System Information</a></h3>
|
||||
<h3><a id="elementsSysinfo">SMBIOS System Information</a></h3>
|
||||
|
||||
<p>
|
||||
Some hypervisors allow control over what system information is
|
||||
@ -502,7 +502,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsCPUAllocation">CPU Allocation</a></h3>
|
||||
<h3><a id="elementsCPUAllocation">CPU Allocation</a></h3>
|
||||
|
||||
<pre>
|
||||
<domain>
|
||||
@ -610,7 +610,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsIOThreadsAllocation">IOThreads Allocation</a></h3>
|
||||
<h3><a id="elementsIOThreadsAllocation">IOThreads Allocation</a></h3>
|
||||
<p>
|
||||
IOThreads are dedicated event loop threads for supported disk
|
||||
devices to perform block I/O requests in order to improve
|
||||
@ -667,7 +667,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsCPUTuning">CPU Tuning</a></h3>
|
||||
<h3><a id="elementsCPUTuning">CPU Tuning</a></h3>
|
||||
|
||||
<pre>
|
||||
<domain>
|
||||
@ -837,7 +837,7 @@
|
||||
</dl>
|
||||
|
||||
|
||||
<h3><a name="elementsMemoryAllocation">Memory Allocation</a></h3>
|
||||
<h3><a id="elementsMemoryAllocation">Memory Allocation</a></h3>
|
||||
|
||||
<pre>
|
||||
<domain>
|
||||
@ -910,7 +910,7 @@
|
||||
</dl>
|
||||
|
||||
|
||||
<h3><a name="elementsMemoryBacking">Memory Backing</a></h3>
|
||||
<h3><a id="elementsMemoryBacking">Memory Backing</a></h3>
|
||||
|
||||
<pre>
|
||||
<domain>
|
||||
@ -980,7 +980,7 @@
|
||||
</dl>
|
||||
|
||||
|
||||
<h3><a name="elementsMemoryTuning">Memory Tuning</a></h3>
|
||||
<h3><a id="elementsMemoryTuning">Memory Tuning</a></h3>
|
||||
|
||||
<pre>
|
||||
<domain>
|
||||
@ -1044,7 +1044,7 @@
|
||||
</dl>
|
||||
|
||||
|
||||
<h3><a name="elementsNUMATuning">NUMA Node Tuning</a></h3>
|
||||
<h3><a id="elementsNUMATuning">NUMA Node Tuning</a></h3>
|
||||
|
||||
<pre>
|
||||
<domain>
|
||||
@ -1105,7 +1105,7 @@
|
||||
</dl>
|
||||
|
||||
|
||||
<h3><a name="elementsBlockTuning">Block I/O Tuning</a></h3>
|
||||
<h3><a id="elementsBlockTuning">Block I/O Tuning</a></h3>
|
||||
<pre>
|
||||
<domain>
|
||||
...
|
||||
@ -1174,7 +1174,7 @@
|
||||
</dl></dd></dl>
|
||||
|
||||
|
||||
<h3><a name="resPartition">Resource partitioning</a></h3>
|
||||
<h3><a id="resPartition">Resource partitioning</a></h3>
|
||||
|
||||
<p>
|
||||
Hypervisors may allow for virtual machines to be placed into
|
||||
@ -1203,7 +1203,7 @@
|
||||
in all mounted controllers. <span class="since">Since 1.0.5</span>
|
||||
</p>
|
||||
|
||||
<h3><a name="elementsCPU">CPU model and topology</a></h3>
|
||||
<h3><a id="elementsCPU">CPU model and topology</a></h3>
|
||||
|
||||
<p>
|
||||
Requirements for CPU model, its features and topology can be specified
|
||||
@ -1532,7 +1532,7 @@
|
||||
This guest NUMA specification is currently available only for QEMU/KVM.
|
||||
</p>
|
||||
|
||||
<h3><a name="elementsEvents">Events configuration</a></h3>
|
||||
<h3><a id="elementsEvents">Events configuration</a></h3>
|
||||
|
||||
<p>
|
||||
It is sometimes necessary to override the default actions taken
|
||||
@ -1643,7 +1643,7 @@
|
||||
<dd>Keep the domain running as if nothing happened.</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsPowerManagement">Power Management</a></h3>
|
||||
<h3><a id="elementsPowerManagement">Power Management</a></h3>
|
||||
|
||||
<p>
|
||||
<span class="since">Since 0.10.2</span> it is possible to
|
||||
@ -1667,7 +1667,7 @@
|
||||
left with its default value.</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsFeatures">Hypervisor features</a></h3>
|
||||
<h3><a id="elementsFeatures">Hypervisor features</a></h3>
|
||||
|
||||
<p>
|
||||
Hypervisors may allow certain CPU / machine features to be
|
||||
@ -1869,7 +1869,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsTime">Time keeping</a></h3>
|
||||
<h3><a id="elementsTime">Time keeping</a></h3>
|
||||
|
||||
<p>
|
||||
The guest clock is typically initialized from the host clock.
|
||||
@ -2037,7 +2037,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsPerf">Performance monitoring events</a></h3>
|
||||
<h3><a id="elementsPerf">Performance monitoring events</a></h3>
|
||||
|
||||
<p>
|
||||
Some platforms allow monitoring of performance of the virtual machine and
|
||||
@ -2218,7 +2218,7 @@
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3><a name="elementsDevices">Devices</a></h3>
|
||||
<h3><a id="elementsDevices">Devices</a></h3>
|
||||
|
||||
<p>
|
||||
The final set of XML elements are all used to describe devices
|
||||
@ -2245,7 +2245,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsDisks">Hard drives, floppy disks, CDROMs</a></h4>
|
||||
<h4><a id="elementsDisks">Hard drives, floppy disks, CDROMs</a></h4>
|
||||
|
||||
<p>
|
||||
Any device that looks like a disk, be it a floppy, harddisk,
|
||||
@ -3185,7 +3185,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsFilesystems">Filesystems</a></h4>
|
||||
<h4><a id="elementsFilesystems">Filesystems</a></h4>
|
||||
|
||||
<p>
|
||||
A directory on the host that can be accessed directly from the guest.
|
||||
@ -3368,7 +3368,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsAddress">Device Addresses</a></h4>
|
||||
<h4><a id="elementsAddress">Device Addresses</a></h4>
|
||||
|
||||
<p>
|
||||
Many devices have an optional <code><address></code>
|
||||
@ -3485,7 +3485,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsVirtio">Virtio-related options</a></h4>
|
||||
<h4><a id="elementsVirtio">Virtio-related options</a></h4>
|
||||
|
||||
<p>
|
||||
QEMU's virtio devices have some attributes related to the virtio transport under
|
||||
@ -3498,7 +3498,7 @@
|
||||
<span class="since">Since 3.5.0</span>
|
||||
</p>
|
||||
|
||||
<h4><a name="elementsControllers">Controllers</a></h4>
|
||||
<h4><a id="elementsControllers">Controllers</a></h4>
|
||||
|
||||
<p>
|
||||
Depending on the guest architecture, some device buses can
|
||||
@ -3884,7 +3884,7 @@
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<h4><a name="elementsLease">Device leases</a></h4>
|
||||
<h4><a id="elementsLease">Device leases</a></h4>
|
||||
|
||||
<p>
|
||||
When using a lock manager, it may be desirable to record device leases
|
||||
@ -3924,9 +3924,9 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsHostDev">Host device assignment</a></h4>
|
||||
<h4><a id="elementsHostDev">Host device assignment</a></h4>
|
||||
|
||||
<h5><a name="elementsHostDevSubsys">USB / PCI / SCSI devices</a></h5>
|
||||
<h5><a id="elementsHostDevSubsys">USB / PCI / SCSI devices</a></h5>
|
||||
|
||||
<p>
|
||||
USB, PCI and SCSI devices attached to the host can be passed through
|
||||
@ -4237,7 +4237,7 @@
|
||||
</dl>
|
||||
|
||||
|
||||
<h5><a name="elementsHostDevCaps">Block / character devices</a></h5>
|
||||
<h5><a id="elementsHostDevCaps">Block / character devices</a></h5>
|
||||
|
||||
<p>
|
||||
Block / character devices from the host can be passed through
|
||||
@ -4294,7 +4294,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsRedir">Redirected devices</a></h4>
|
||||
<h4><a id="elementsRedir">Redirected devices</a></h4>
|
||||
|
||||
<p>
|
||||
USB device redirection through a character device is
|
||||
@ -4361,7 +4361,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsSmartcard">Smartcard devices</a></h4>
|
||||
<h4><a id="elementsSmartcard">Smartcard devices</a></h4>
|
||||
|
||||
<p>
|
||||
A virtual smartcard device can be supplied to the guest via the
|
||||
@ -4454,7 +4454,7 @@
|
||||
smartcard, with an address of bus=0 slot=0.
|
||||
</p>
|
||||
|
||||
<h4><a name="elementsNICS">Network interfaces</a></h4>
|
||||
<h4><a id="elementsNICS">Network interfaces</a></h4>
|
||||
|
||||
<pre>
|
||||
...
|
||||
@ -4494,7 +4494,7 @@
|
||||
as <a href="#elementsAddress">documented above</a>.
|
||||
</p>
|
||||
|
||||
<h5><a name="elementsNICSVirtual">Virtual network</a></h5>
|
||||
<h5><a id="elementsNICSVirtual">Virtual network</a></h5>
|
||||
|
||||
<p>
|
||||
<strong><em>
|
||||
@ -4600,7 +4600,7 @@
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<h5><a name="elementsNICSBridge">Bridge to LAN</a></h5>
|
||||
<h5><a id="elementsNICSBridge">Bridge to LAN</a></h5>
|
||||
|
||||
<p>
|
||||
<strong><em>
|
||||
@ -4691,7 +4691,7 @@
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<h5><a name="elementsNICSSlirp">Userspace SLIRP stack</a></h5>
|
||||
<h5><a id="elementsNICSSlirp">Userspace SLIRP stack</a></h5>
|
||||
|
||||
<p>
|
||||
Provides a virtual LAN with NAT to the outside world. The virtual
|
||||
@ -4714,7 +4714,7 @@
|
||||
...</pre>
|
||||
|
||||
|
||||
<h5><a name="elementsNICSEthernet">Generic ethernet connection</a></h5>
|
||||
<h5><a id="elementsNICSEthernet">Generic ethernet connection</a></h5>
|
||||
|
||||
<p>
|
||||
Provides a means for the administrator to execute an arbitrary script
|
||||
@ -4738,7 +4738,7 @@
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<h5><a name="elementsNICSDirect">Direct attachment to physical interface</a></h5>
|
||||
<h5><a id="elementsNICSDirect">Direct attachment to physical interface</a></h5>
|
||||
|
||||
<p>
|
||||
Provides direct attachment of the virtual machine's NIC to the given
|
||||
@ -4883,7 +4883,7 @@
|
||||
</pre>
|
||||
|
||||
|
||||
<h5><a name="elementsNICSHostdev">PCI Passthrough</a></h5>
|
||||
<h5><a id="elementsNICSHostdev">PCI Passthrough</a></h5>
|
||||
|
||||
<p>
|
||||
A PCI network device (specified by the <source> element)
|
||||
@ -4956,7 +4956,7 @@
|
||||
...</pre>
|
||||
|
||||
|
||||
<h5><a name="elementsNICSMulticast">Multicast tunnel</a></h5>
|
||||
<h5><a id="elementsNICSMulticast">Multicast tunnel</a></h5>
|
||||
|
||||
<p>
|
||||
A multicast group is setup to represent a virtual network. Any VMs
|
||||
@ -4980,7 +4980,7 @@
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<h5><a name="elementsNICSTCP">TCP tunnel</a></h5>
|
||||
<h5><a id="elementsNICSTCP">TCP tunnel</a></h5>
|
||||
|
||||
<p>
|
||||
A TCP client/server architecture provides a virtual network. One VM
|
||||
@ -5006,7 +5006,7 @@
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<h5><a name="elementsNICSUDP">UDP unicast tunnel</a></h5>
|
||||
<h5><a id="elementsNICSUDP">UDP unicast tunnel</a></h5>
|
||||
|
||||
<p>
|
||||
A UDP unicast architecture provides a virtual network which enables
|
||||
@ -5030,7 +5030,7 @@
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<h5><a name="elementsNICSModel">Setting the NIC model</a></h5>
|
||||
<h5><a id="elementsNICSModel">Setting the NIC model</a></h5>
|
||||
|
||||
<pre>
|
||||
...
|
||||
@ -5065,7 +5065,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
ne2k_isa i82551 i82557b i82559er ne2k_pci pcnet rtl8139 e1000 virtio
|
||||
</p>
|
||||
|
||||
<h5><a name="elementsDriverBackendOptions">Setting NIC driver-specific options</a></h5>
|
||||
<h5><a id="elementsDriverBackendOptions">Setting NIC driver-specific options</a></h5>
|
||||
|
||||
<pre>
|
||||
...
|
||||
@ -5253,7 +5253,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h5><a name="elementsBackendOptions">Setting network backend-specific options</a></h5>
|
||||
<h5><a id="elementsBackendOptions">Setting network backend-specific options</a></h5>
|
||||
|
||||
<pre>
|
||||
...
|
||||
@ -5284,7 +5284,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
adjust the size of send buffer in the host. <span class="since">Since
|
||||
0.8.8</span>
|
||||
</p>
|
||||
<h5><a name="elementsNICSTargetOverride">Overriding the target element</a></h5>
|
||||
<h5><a id="elementsNICSTargetOverride">Overriding the target element</a></h5>
|
||||
|
||||
<pre>
|
||||
...
|
||||
@ -5322,7 +5322,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<h5><a name="elementsNICSBoot">Specifying boot order</a></h5>
|
||||
<h5><a id="elementsNICSBoot">Specifying boot order</a></h5>
|
||||
|
||||
<pre>
|
||||
...
|
||||
@ -5345,7 +5345,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
<span class="since">Since 0.8.8</span>
|
||||
</p>
|
||||
|
||||
<h5><a name="elementsNICSROM">Interface ROM BIOS configuration</a></h5>
|
||||
<h5><a id="elementsNICSROM">Interface ROM BIOS configuration</a></h5>
|
||||
|
||||
<pre>
|
||||
...
|
||||
@ -5374,7 +5374,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
network device.
|
||||
<span class="since">Since 0.9.10 (QEMU and KVM only)</span>.
|
||||
</p>
|
||||
<h5><a name="elementDomain">Setting up a network backend in a driver domain</a></h5>
|
||||
<h5><a id="elementDomain">Setting up a network backend in a driver domain</a></h5>
|
||||
<pre>
|
||||
...
|
||||
<devices>
|
||||
@ -5398,7 +5398,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
<span class="since">Since 1.2.13 (Xen only)</span>
|
||||
</p>
|
||||
|
||||
<h5><a name="elementQoS">Quality of service</a></h5>
|
||||
<h5><a id="elementQoS">Quality of service</a></h5>
|
||||
|
||||
<pre>
|
||||
...
|
||||
@ -5422,7 +5422,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
the Network XML.
|
||||
</p>
|
||||
|
||||
<h5><a name="elementVlanTag">Setting VLAN tag (on supported network types only)</a></h5>
|
||||
<h5><a id="elementVlanTag">Setting VLAN tag (on supported network types only)</a></h5>
|
||||
|
||||
<pre>
|
||||
...
|
||||
@ -5490,7 +5490,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
traffic for that VLAN will be tagged.
|
||||
</p>
|
||||
|
||||
<h5><a name="elementLink">Modifying virtual link state</a></h5>
|
||||
<h5><a id="elementLink">Modifying virtual link state</a></h5>
|
||||
<pre>
|
||||
...
|
||||
<devices>
|
||||
@ -5511,7 +5511,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
<span class="since">Since 0.9.5</span>
|
||||
</p>
|
||||
|
||||
<h5><a name="mtu">MTU configuration</a></h5>
|
||||
<h5><a id="mtu">MTU configuration</a></h5>
|
||||
<pre>
|
||||
...
|
||||
<devices>
|
||||
@ -5530,7 +5530,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
<span class="since">Since 3.1.0</span>
|
||||
</p>
|
||||
|
||||
<h5><a name="coalesce">Coalesce settings</a></h5>
|
||||
<h5><a id="coalesce">Coalesce settings</a></h5>
|
||||
<pre>
|
||||
...
|
||||
<devices>
|
||||
@ -5557,7 +5557,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
<span class="since">Since 3.3.0</span>
|
||||
</p>
|
||||
|
||||
<h5><a name="ipconfig">IP configuration</a></h5>
|
||||
<h5><a id="ipconfig">IP configuration</a></h5>
|
||||
<pre>
|
||||
...
|
||||
<devices>
|
||||
@ -5636,7 +5636,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
configure the guest side of the interface (described above).
|
||||
</p>
|
||||
|
||||
<h5><a name="elementVhostuser">vhost-user interface</a></h5>
|
||||
<h5><a id="elementVhostuser">vhost-user interface</a></h5>
|
||||
|
||||
<p>
|
||||
<span class="since">Since 1.2.7</span> the vhost-user enables the
|
||||
@ -5673,7 +5673,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
<code><model></code> element is mandatory.
|
||||
</p>
|
||||
|
||||
<h5><a name="elementNwfilter">Traffic filtering with NWFilter</a></h5>
|
||||
<h5><a id="elementNwfilter">Traffic filtering with NWFilter</a></h5>
|
||||
|
||||
<p>
|
||||
<span class="since">Since 0.8.0</span> an <code>nwfilter</code> profile
|
||||
@ -5713,7 +5713,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</p>
|
||||
|
||||
|
||||
<h4><a name="elementsInput">Input devices</a></h4>
|
||||
<h4><a id="elementsInput">Input devices</a></h4>
|
||||
|
||||
<p>
|
||||
Input devices allow interaction with the graphical framebuffer
|
||||
@ -5768,7 +5768,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
set. (<span class="since">Since 3.5.0</span>)
|
||||
</p>
|
||||
|
||||
<h4><a name="elementsHub">Hub devices</a></h4>
|
||||
<h4><a id="elementsHub">Hub devices</a></h4>
|
||||
|
||||
<p>
|
||||
A hub is a device that expands a single port into several so
|
||||
@ -5797,7 +5797,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
above</a>.
|
||||
</p>
|
||||
|
||||
<h4><a name="elementsGraphics">Graphical framebuffers</a></h4>
|
||||
<h4><a id="elementsGraphics">Graphical framebuffers</a></h4>
|
||||
|
||||
<p>
|
||||
A graphics device allows for graphical interaction with the
|
||||
@ -6095,7 +6095,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsVideo">Video devices</a></h4>
|
||||
<h4><a id="elementsVideo">Video devices</a></h4>
|
||||
<p>
|
||||
A video device.
|
||||
</p>
|
||||
@ -6210,7 +6210,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsConsole">Consoles, serial, parallel & channel devices</a></h4>
|
||||
<h4><a id="elementsConsole">Consoles, serial, parallel & channel devices</a></h4>
|
||||
|
||||
<p>
|
||||
A character device provides a way to interact with the virtual machine.
|
||||
@ -6296,14 +6296,14 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
slot.
|
||||
</p>
|
||||
|
||||
<h5><a name="elementsCharGuestInterface">Guest interface</a></h5>
|
||||
<h5><a id="elementsCharGuestInterface">Guest interface</a></h5>
|
||||
|
||||
<p>
|
||||
A character device presents itself to the guest as one of the following
|
||||
types.
|
||||
</p>
|
||||
|
||||
<h6><a name="elementCharParallel">Parallel port</a></h6>
|
||||
<h6><a id="elementCharParallel">Parallel port</a></h6>
|
||||
|
||||
<pre>
|
||||
...
|
||||
@ -6321,7 +6321,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
usually 0, 1 or 2 parallel ports.
|
||||
</p>
|
||||
|
||||
<h6><a name="elementCharSerial">Serial port</a></h6>
|
||||
<h6><a id="elementCharSerial">Serial port</a></h6>
|
||||
|
||||
<pre>
|
||||
...
|
||||
@ -6350,7 +6350,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
<code>type='pci'</code> to select desired location on the PCI bus.
|
||||
</p>
|
||||
|
||||
<h6><a name="elementCharConsole">Console</a></h6>
|
||||
<h6><a id="elementCharConsole">Console</a></h6>
|
||||
|
||||
<p>
|
||||
The console element is used to represent interactive consoles. Depending
|
||||
@ -6422,7 +6422,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
only 1 console.
|
||||
</p>
|
||||
|
||||
<h6><a name="elementCharChannel">Channel</a></h6>
|
||||
<h6><a id="elementCharChannel">Channel</a></h6>
|
||||
|
||||
<p>
|
||||
This represents a private communication channel between the host and the
|
||||
@ -6514,14 +6514,14 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
<span class="since">Since 0.8.8</span></dd>
|
||||
</dl>
|
||||
|
||||
<h5><a name="elementsCharHostInterface">Host interface</a></h5>
|
||||
<h5><a id="elementsCharHostInterface">Host interface</a></h5>
|
||||
|
||||
<p>
|
||||
A character device presents itself to the host as one of the following
|
||||
types.
|
||||
</p>
|
||||
|
||||
<h6><a name="elementsCharSTDIO">Domain logfile</a></h6>
|
||||
<h6><a id="elementsCharSTDIO">Domain logfile</a></h6>
|
||||
|
||||
<p>
|
||||
This disables all input on the character device, and sends output
|
||||
@ -6538,7 +6538,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
...</pre>
|
||||
|
||||
|
||||
<h6><a name="elementsCharFle">Device logfile</a></h6>
|
||||
<h6><a id="elementsCharFle">Device logfile</a></h6>
|
||||
|
||||
<p>
|
||||
A file is opened and all data sent to the character
|
||||
@ -6555,7 +6555,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<h6><a name="elementsCharVC">Virtual console</a></h6>
|
||||
<h6><a id="elementsCharVC">Virtual console</a></h6>
|
||||
|
||||
<p>
|
||||
Connects the character device to the graphical framebuffer in
|
||||
@ -6572,7 +6572,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<h6><a name="elementsCharNull">Null device</a></h6>
|
||||
<h6><a id="elementsCharNull">Null device</a></h6>
|
||||
|
||||
<p>
|
||||
Connects the character device to the void. No data is ever
|
||||
@ -6588,7 +6588,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<h6><a name="elementsCharPTY">Pseudo TTY</a></h6>
|
||||
<h6><a id="elementsCharPTY">Pseudo TTY</a></h6>
|
||||
|
||||
<p>
|
||||
A Pseudo TTY is allocated using /dev/ptmx. A suitable client
|
||||
@ -6613,7 +6613,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
with existing syntax for <console> tags.
|
||||
</p>
|
||||
|
||||
<h6><a name="elementsCharHost">Host device proxy</a></h6>
|
||||
<h6><a id="elementsCharHost">Host device proxy</a></h6>
|
||||
|
||||
<p>
|
||||
The character device is passed through to the underlying
|
||||
@ -6633,7 +6633,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<h6><a name="elementsCharPipe">Named pipe</a></h6>
|
||||
<h6><a id="elementsCharPipe">Named pipe</a></h6>
|
||||
|
||||
<p>
|
||||
The character device writes output to a named pipe. See pipe(7) for
|
||||
@ -6650,7 +6650,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<h6><a name="elementsCharTCP">TCP client/server</a></h6>
|
||||
<h6><a id="elementsCharTCP">TCP client/server</a></h6>
|
||||
|
||||
<p>
|
||||
The character device acts as a TCP client connecting to a
|
||||
@ -6739,7 +6739,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<h6><a name="elementsCharUDP">UDP network console</a></h6>
|
||||
<h6><a id="elementsCharUDP">UDP network console</a></h6>
|
||||
|
||||
<p>
|
||||
The character device acts as a UDP netconsole service,
|
||||
@ -6757,7 +6757,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<h6><a name="elementsCharUNIX">UNIX domain socket client/server</a></h6>
|
||||
<h6><a id="elementsCharUNIX">UNIX domain socket client/server</a></h6>
|
||||
|
||||
<p>
|
||||
The character device acts as a UNIX domain socket server,
|
||||
@ -6774,7 +6774,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<h6><a name="elementsCharSpiceport">Spice channel</a></h6>
|
||||
<h6><a id="elementsCharSpiceport">Spice channel</a></h6>
|
||||
|
||||
<p>
|
||||
The character device is accessible through spice connection
|
||||
@ -6797,7 +6797,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<h6><a name="elementsNmdm">Nmdm device</a></h6>
|
||||
<h6><a id="elementsNmdm">Nmdm device</a></h6>
|
||||
|
||||
<p>
|
||||
The nmdm device driver, available on FreeBSD, provides two
|
||||
@ -6828,7 +6828,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
to the guest console. Device is specified by a fully qualified path.</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsSound">Sound devices</a></h4>
|
||||
<h4><a id="elementsSound">Sound devices</a></h4>
|
||||
|
||||
<p>
|
||||
A virtual sound card can be attached to the host via the
|
||||
@ -6881,7 +6881,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
slot, <a href="#elementsAddress">documented above</a>.
|
||||
</p>
|
||||
|
||||
<h4><a name="elementsWatchdog">Watchdog device</a></h4>
|
||||
<h4><a id="elementsWatchdog">Watchdog device</a></h4>
|
||||
|
||||
<p>
|
||||
A virtual hardware watchdog device can be added to the guest via
|
||||
@ -6971,7 +6971,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsMemBalloon">Memory balloon device</a></h4>
|
||||
<h4><a id="elementsMemBalloon">Memory balloon device</a></h4>
|
||||
|
||||
<p>
|
||||
A virtual memory balloon device is added to all Xen and KVM/QEMU
|
||||
@ -7056,7 +7056,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
set. (<span class="since">Since 3.5.0</span>)
|
||||
</dd>
|
||||
</dl>
|
||||
<h4><a name="elementsRng">Random number generator device</a></h4>
|
||||
<h4><a id="elementsRng">Random number generator device</a></h4>
|
||||
|
||||
<p>
|
||||
The virtual random number generator device allows the host to pass
|
||||
@ -7150,7 +7150,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsTpm">TPM device</a></h4>
|
||||
<h4><a id="elementsTpm">TPM device</a></h4>
|
||||
|
||||
<p>
|
||||
The TPM device enables a QEMU guest to have access to TPM
|
||||
@ -7210,7 +7210,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsNVRAM">NVRAM device</a></h4>
|
||||
<h4><a id="elementsNVRAM">NVRAM device</a></h4>
|
||||
<p>
|
||||
nvram device is always added to pSeries guest on PPC64, and its address
|
||||
is allowed to be changed. Element <code>nvram</code> (only valid for
|
||||
@ -7244,7 +7244,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsPanic">panic device</a></h4>
|
||||
<h4><a id="elementsPanic">panic device</a></h4>
|
||||
<p>
|
||||
panic device enables libvirt to receive panic notification from a QEMU
|
||||
guest.
|
||||
@ -7301,7 +7301,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsShmem">Shared memory device</a></h4>
|
||||
<h4><a id="elementsShmem">Shared memory device</a></h4>
|
||||
|
||||
<p>
|
||||
A shared memory device allows to share a memory region between
|
||||
@ -7365,7 +7365,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsMemory">Memory devices</a></h4>
|
||||
<h4><a id="elementsMemory">Memory devices</a></h4>
|
||||
|
||||
<p>
|
||||
In addition to the initial memory assigned to the guest, memory devices
|
||||
@ -7508,7 +7508,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h4><a name="elementsIommu">IOMMU devices</a></h4>
|
||||
<h4><a id="elementsIommu">IOMMU devices</a></h4>
|
||||
|
||||
<p>
|
||||
The <code>iommu</code> element can be used to add an IOMMU device.
|
||||
@ -7588,7 +7588,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="seclabel">Security label</a></h3>
|
||||
<h3><a id="seclabel">Security label</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>seclabel</code> element allows control over the
|
||||
@ -7717,7 +7717,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
being on a file system that lacks security labeling.
|
||||
</p>
|
||||
|
||||
<h3><a name="keywrap">Key Wrap</a></h3>
|
||||
<h3><a id="keywrap">Key Wrap</a></h3>
|
||||
|
||||
<p>The content of the optional <code>keywrap</code> element specifies
|
||||
whether the guest will be allowed to perform the S390 cryptographic key
|
||||
@ -7756,7 +7756,7 @@ qemu-kvm -net nic,model=? /dev/null
|
||||
|
||||
<p>Note: DEA/TDEA is synonymous with DES/TDES.</p>
|
||||
|
||||
<h2><a name="examples">Example configs</a></h2>
|
||||
<h2><a id="examples">Example configs</a></h2>
|
||||
|
||||
<p>
|
||||
Example configurations for each driver are provide on the
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="Overview">Overview</a></h2>
|
||||
<h2><a id="Overview">Overview</a></h2>
|
||||
|
||||
<p>Sometimes, when a new domain is to be created it may come handy to know
|
||||
the capabilities of the hypervisor so the correct combination of devices and
|
||||
@ -37,7 +37,7 @@
|
||||
management application to choose an appropriate mode for a pass-through
|
||||
host device as well as which adapter to utilize.</p>
|
||||
|
||||
<h2><a name="elements">Element and attribute overview</a></h2>
|
||||
<h2><a id="elements">Element and attribute overview</a></h2>
|
||||
|
||||
<p> A new query interface was added to the virConnect API's to retrieve the
|
||||
XML listing of the set of domain capabilities (<span class="since">Since
|
||||
@ -79,7 +79,7 @@
|
||||
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsCPUAllocation">CPU Allocation</a></h3>
|
||||
<h3><a id="elementsCPUAllocation">CPU Allocation</a></h3>
|
||||
|
||||
<p>Before any devices capability occurs, there might be a info on domain
|
||||
wide capabilities, e.g. virtual CPUs:</p>
|
||||
@ -97,7 +97,7 @@
|
||||
<dd>The maximum number of supported virtual CPUs</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsOSBIOS">BIOS bootloader</a></h3>
|
||||
<h3><a id="elementsOSBIOS">BIOS bootloader</a></h3>
|
||||
|
||||
<p>Sometimes users might want to tweak some BIOS knobs or use
|
||||
UEFI. For cases like that, <a
|
||||
@ -143,7 +143,7 @@
|
||||
<loader/> element.</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsCPU">CPU configuration</a></h3>
|
||||
<h3><a id="elementsCPU">CPU configuration</a></h3>
|
||||
|
||||
<p>
|
||||
The <code>cpu</code> element exposes options usable for configuring
|
||||
@ -208,7 +208,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsDevices">Devices</a></h3>
|
||||
<h3><a id="elementsDevices">Devices</a></h3>
|
||||
|
||||
<p>
|
||||
Another set of XML elements describe the supported devices and their
|
||||
@ -240,7 +240,7 @@
|
||||
support the values <code>disk</code>, <code>cdrom</code>,
|
||||
<code>floppy</code>, or <code>lun</code>.</p>
|
||||
|
||||
<h4><a name="elementsDisks">Hard drives, floppy disks, CDROMs</a></h4>
|
||||
<h4><a id="elementsDisks">Hard drives, floppy disks, CDROMs</a></h4>
|
||||
<p>Disk capabilities are exposed under the <code>disk</code> element. For
|
||||
instance:</p>
|
||||
|
||||
@ -283,7 +283,7 @@
|
||||
</dl>
|
||||
|
||||
|
||||
<h4><a name="elementsGraphics">Graphical framebuffers</a></h4>
|
||||
<h4><a id="elementsGraphics">Graphical framebuffers</a></h4>
|
||||
<p>Graphics device capabilities are exposed under the
|
||||
<code>graphics</code> element. For instance:</p>
|
||||
|
||||
@ -310,7 +310,7 @@
|
||||
</dl>
|
||||
|
||||
|
||||
<h4><a name="elementsVideo">Video device</a></h4>
|
||||
<h4><a id="elementsVideo">Video device</a></h4>
|
||||
<p>Video device capabilities are exposed under the
|
||||
<code>video</code> element. For instance:</p>
|
||||
|
||||
@ -339,7 +339,7 @@
|
||||
</dl>
|
||||
|
||||
|
||||
<h4><a name="elementsHostDev">Host device assignment</a></h4>
|
||||
<h4><a id="elementsHostDev">Host device assignment</a></h4>
|
||||
<p>Some host devices can be passed through to a guest (e.g. USB, PCI and
|
||||
SCSI). Well, only if the following is enabled:</p>
|
||||
|
||||
@ -401,7 +401,7 @@
|
||||
element.</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsFeatures">Features</a></h3>
|
||||
<h3><a id="elementsFeatures">Features</a></h3>
|
||||
|
||||
<p>One more set of XML elements describe the supported features and
|
||||
their capabilities. All features occur as children of the main
|
||||
@ -431,7 +431,7 @@
|
||||
the domain XML documentation.
|
||||
</p>
|
||||
|
||||
<h4><a name="elementsGIC">GIC capabilities</a></h4>
|
||||
<h4><a id="elementsGIC">GIC capabilities</a></h4>
|
||||
|
||||
<p>GIC capabilities are exposed under the <code>gic</code> element.</p>
|
||||
|
||||
|
@ -13,7 +13,7 @@
|
||||
<a href="https://wiki.libvirt.org/page/Networking">relevant wiki page</a>.
|
||||
</p>
|
||||
|
||||
<h2><a name="elements">Element and attribute overview</a></h2>
|
||||
<h2><a id="elements">Element and attribute overview</a></h2>
|
||||
|
||||
<p>
|
||||
The root element required for all virtual networks is
|
||||
@ -27,7 +27,7 @@
|
||||
available <span class="since">since 0.3.0</span>
|
||||
</p>
|
||||
|
||||
<h3><a name="elementsMetadata">General metadata</a></h3>
|
||||
<h3><a id="elementsMetadata">General metadata</a></h3>
|
||||
|
||||
<p>
|
||||
The first elements provide basic metadata about the virtual
|
||||
@ -83,7 +83,7 @@
|
||||
override the setting in the network.</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsConnect">Connectivity</a></h3>
|
||||
<h3><a id="elementsConnect">Connectivity</a></h3>
|
||||
|
||||
<p>
|
||||
The next set of elements control how a virtual network is
|
||||
@ -514,7 +514,7 @@
|
||||
|
||||
</dd>
|
||||
</dl>
|
||||
<h5><a name="elementQoS">Quality of service</a></h5>
|
||||
<h5><a id="elementQoS">Quality of service</a></h5>
|
||||
|
||||
<pre>
|
||||
...
|
||||
@ -634,7 +634,7 @@
|
||||
<span class="since">since 1.0.1</span>.
|
||||
</p>
|
||||
|
||||
<h5><a name="elementVlanTag">Setting VLAN tag (on supported network types only)</a></h5>
|
||||
<h5><a id="elementVlanTag">Setting VLAN tag (on supported network types only)</a></h5>
|
||||
|
||||
<pre>
|
||||
<network>
|
||||
@ -712,7 +712,7 @@
|
||||
or <code><interface></code>.
|
||||
</p>
|
||||
|
||||
<h5><a name="elementsPortgroup">Portgroups</a></h5>
|
||||
<h5><a id="elementsPortgroup">Portgroups</a></h5>
|
||||
|
||||
<pre>
|
||||
...
|
||||
@ -790,7 +790,7 @@
|
||||
setting in the portgroup.
|
||||
</p>
|
||||
|
||||
<h5><a name="elementsStaticroute">Static Routes</a></h5>
|
||||
<h5><a id="elementsStaticroute">Static Routes</a></h5>
|
||||
<p>
|
||||
Static route definitions are used to provide routing information
|
||||
to the virtualization host for networks which are not directly
|
||||
@ -845,7 +845,7 @@
|
||||
...
|
||||
</pre>
|
||||
|
||||
<h3><a name="elementsAddress">Addressing</a></h3>
|
||||
<h3><a id="elementsAddress">Addressing</a></h3>
|
||||
|
||||
<p>
|
||||
The final set of elements define the addresses (IPv4 and/or
|
||||
@ -1079,9 +1079,9 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a name="examples">Example configuration</a></h2>
|
||||
<h2><a id="examples">Example configuration</a></h2>
|
||||
|
||||
<h3><a name="examplesNAT">NAT based network</a></h3>
|
||||
<h3><a id="examplesNAT">NAT based network</a></h3>
|
||||
|
||||
<p>
|
||||
This example is the so called "default" virtual network. It is
|
||||
@ -1129,7 +1129,7 @@
|
||||
</ip>
|
||||
</network></pre>
|
||||
|
||||
<h3><a name="examplesRoute">Routed network config</a></h3>
|
||||
<h3><a id="examplesRoute">Routed network config</a></h3>
|
||||
|
||||
<p>
|
||||
This is a variant on the default network which routes traffic
|
||||
@ -1211,7 +1211,7 @@
|
||||
<route family="ipv6" address="2001:db8:ca2:8::" prefix="64" gateway="2001:db8:ca2:7::4"/>
|
||||
</network></pre>
|
||||
|
||||
<h3><a name="examplesPrivate">Isolated network config</a></h3>
|
||||
<h3><a id="examplesPrivate">Isolated network config</a></h3>
|
||||
|
||||
<p>
|
||||
This variant provides a completely isolated private network
|
||||
@ -1233,7 +1233,7 @@
|
||||
<ip family="ipv6" address="2001:db8:ca2:3::1" prefix="64"/>
|
||||
</network></pre>
|
||||
|
||||
<h3><a name="examplesPrivate6">Isolated IPv6 network config</a></h3>
|
||||
<h3><a id="examplesPrivate6">Isolated IPv6 network config</a></h3>
|
||||
|
||||
<p>
|
||||
This variation of an isolated network defines only IPv6.
|
||||
@ -1259,7 +1259,7 @@
|
||||
</ip>
|
||||
</network></pre>
|
||||
|
||||
<h3><a name="examplesBridge">Using an existing host bridge</a></h3>
|
||||
<h3><a id="examplesBridge">Using an existing host bridge</a></h3>
|
||||
|
||||
<p>
|
||||
<span class="since">Since 0.9.4</span>
|
||||
@ -1277,7 +1277,7 @@
|
||||
<bridge name="br0"/>
|
||||
</network></pre>
|
||||
|
||||
<h3><a name="examplesDirect">Using a macvtap "direct" connection</a></h3>
|
||||
<h3><a id="examplesDirect">Using a macvtap "direct" connection</a></h3>
|
||||
|
||||
<p>
|
||||
<span class="since">Since 0.9.4, QEMU and KVM only, requires
|
||||
@ -1312,7 +1312,7 @@
|
||||
</forward>
|
||||
</network></pre>
|
||||
|
||||
<h3><a name="examplesNoGateway">Network config with no gateway addresses</a></h3>
|
||||
<h3><a id="examplesNoGateway">Network config with no gateway addresses</a></h3>
|
||||
|
||||
<p>
|
||||
A valid network definition can contain no IPv4 or IPv6 addresses. Such a definition
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="NodedevAttributes">Node Device XML</a></h2>
|
||||
<h2><a id="NodedevAttributes">Node Device XML</a></h2>
|
||||
|
||||
<p>
|
||||
There are several libvirt functions, all with the
|
||||
@ -340,7 +340,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a name="nodeExample">Examples</a></h2>
|
||||
<h2><a id="nodeExample">Examples</a></h2>
|
||||
|
||||
<p>The following are some example node device XML outputs:</p>
|
||||
<pre>
|
||||
|
@ -12,7 +12,7 @@
|
||||
their goals, concepts and XML format.
|
||||
</p>
|
||||
|
||||
<h2><a name="goals">Goals and background</a></h2>
|
||||
<h2><a id="goals">Goals and background</a></h2>
|
||||
|
||||
<p>
|
||||
The goal of the network filtering XML is to enable administrators
|
||||
@ -43,7 +43,7 @@
|
||||
(QEMU, KVM)</span>
|
||||
</p>
|
||||
|
||||
<h2><a name="nwfconcepts">Concepts</a></h2>
|
||||
<h2><a id="nwfconcepts">Concepts</a></h2>
|
||||
<p>
|
||||
The network traffic filtering subsystem enables configuration
|
||||
of network traffic filtering rules on individual network
|
||||
@ -111,7 +111,7 @@
|
||||
<br/><br/>
|
||||
</p>
|
||||
|
||||
<h3><a name="nwfconceptschains">Filtering chains</a></h3>
|
||||
<h3><a id="nwfconceptschains">Filtering chains</a></h3>
|
||||
<p>
|
||||
Filtering rules are organized in filter chains. These chains can be
|
||||
thought of as having a tree structure with packet
|
||||
@ -192,7 +192,7 @@
|
||||
traverse the ARP chain.
|
||||
<br/><br/>
|
||||
</p>
|
||||
<h3><a name="nwfconceptschainpriorities">Filtering chain priorities</a></h3>
|
||||
<h3><a id="nwfconceptschainpriorities">Filtering chain priorities</a></h3>
|
||||
<p>
|
||||
All chains are connected to the <code>root</code> chain. The order in
|
||||
which those chains are accessed is influenced by the priority of the
|
||||
@ -236,7 +236,7 @@
|
||||
node. The above example filter shows the default priority of -500
|
||||
for <code>arp</code> chains.
|
||||
</p>
|
||||
<h3><a name="nwfconceptsvars">Usage of variables in filters</a></h3>
|
||||
<h3><a id="nwfconceptsvars">Usage of variables in filters</a></h3>
|
||||
<p>
|
||||
|
||||
Two variables names have so far been reserved for usage by the
|
||||
@ -374,7 +374,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
former notation always assumes the iterator with Id '0'.
|
||||
</p>
|
||||
|
||||
<h3><a name="nwfelemsRulesAdvIPAddrDetection">Automatic IP address detection</a></h3>
|
||||
<h3><a id="nwfelemsRulesAdvIPAddrDetection">Automatic IP address detection</a></h3>
|
||||
<p>
|
||||
The detection of IP addresses used on a virtual machine's interface
|
||||
is automatically activated if the variable <code>IP</code> is referenced
|
||||
@ -448,7 +448,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
</interface>
|
||||
</pre>
|
||||
|
||||
<h3><a name="nwfelemsReservedVars">Reserved Variables</a></h3>
|
||||
<h3><a id="nwfelemsReservedVars">Reserved Variables</a></h3>
|
||||
<p>
|
||||
The following table lists reserved variables in use by libvirt.
|
||||
</p>
|
||||
@ -485,7 +485,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h2><a name="nwfelems">Element and attribute overview</a></h2>
|
||||
<h2><a id="nwfelems">Element and attribute overview</a></h2>
|
||||
|
||||
<p>
|
||||
The root element required for all network filters is
|
||||
@ -498,7 +498,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
ipv4, ipv6, arp and rarp</code>.
|
||||
</p>
|
||||
|
||||
<h3><a name="nwfelemsRefs">References to other filters</a></h3>
|
||||
<h3><a id="nwfelemsRefs">References to other filters</a></h3>
|
||||
<p>
|
||||
Any filter may hold references to other filters. Individual
|
||||
filters may be referenced multiple times in a filter tree but
|
||||
@ -536,7 +536,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
attached.
|
||||
</p>
|
||||
|
||||
<h3><a name="nwfelemsRules">Filter rules</a></h3>
|
||||
<h3><a id="nwfelemsRules">Filter rules</a></h3>
|
||||
<p>
|
||||
The following XML shows a simple example of a network
|
||||
traffic filter implementing a rule to drop traffic if
|
||||
@ -618,7 +618,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
filtered.
|
||||
</p>
|
||||
|
||||
<h4><a name="nwfelemsRulesProto">Supported protocols</a></h4>
|
||||
<h4><a id="nwfelemsRulesProto">Supported protocols</a></h4>
|
||||
<p>
|
||||
The following sections enumerate the list of protocols that
|
||||
are supported by the network filtering subsystem. The
|
||||
@ -677,7 +677,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
</p>
|
||||
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoMAC">MAC (Ethernet)</a></h5>
|
||||
<h5><a id="nwfelemsRulesProtoMAC">MAC (Ethernet)</a></h5>
|
||||
<p>
|
||||
Protocol ID: <code>mac</code>
|
||||
<br/>
|
||||
@ -729,7 +729,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
[...]
|
||||
</pre>
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoVLAN">VLAN (802.1Q)</a>
|
||||
<h5><a id="nwfelemsRulesProtoVLAN">VLAN (802.1Q)</a>
|
||||
<span class="since">(Since 0.9.8)</span>
|
||||
</h5>
|
||||
<p>
|
||||
@ -784,7 +784,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
Valid Strings for <code>encap-protocol</code> are: arp, ipv4, ipv6
|
||||
</p>
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoSTP">STP (Spanning Tree Protocol)</a>
|
||||
<h5><a id="nwfelemsRulesProtoSTP">STP (Spanning Tree Protocol)</a>
|
||||
<span class="since">(Since 0.9.8)</span>
|
||||
</h5>
|
||||
<p>
|
||||
@ -926,7 +926,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoARP">ARP/RARP</a></h5>
|
||||
<h5><a id="nwfelemsRulesProtoARP">ARP/RARP</a></h5>
|
||||
<p>
|
||||
Protocol ID: <code>arp</code> or <code>rarp</code>
|
||||
<br/>
|
||||
@ -1022,7 +1022,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
<br/><br/>
|
||||
</p>
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoIP">IPv4</a></h5>
|
||||
<h5><a id="nwfelemsRulesProtoIP">IPv4</a></h5>
|
||||
<p>
|
||||
Protocol ID: <code>ip</code>
|
||||
<br/>
|
||||
@ -1118,7 +1118,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
</p>
|
||||
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoIPv6">IPv6</a></h5>
|
||||
<h5><a id="nwfelemsRulesProtoIPv6">IPv6</a></h5>
|
||||
<p>
|
||||
Protocol ID: <code>ipv6</code>
|
||||
<br/>
|
||||
@ -1228,7 +1228,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
<br/><br/>
|
||||
</p>
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoTCP-ipv4">TCP/UDP/SCTP</a></h5>
|
||||
<h5><a id="nwfelemsRulesProtoTCP-ipv4">TCP/UDP/SCTP</a></h5>
|
||||
<p>
|
||||
Protocol ID: <code>tcp</code>, <code>udp</code>, <code>sctp</code>
|
||||
<br/>
|
||||
@ -1344,7 +1344,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
</p>
|
||||
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoICMP">ICMP</a></h5>
|
||||
<h5><a id="nwfelemsRulesProtoICMP">ICMP</a></h5>
|
||||
<p>
|
||||
Protocol ID: <code>icmp</code>
|
||||
<br/>
|
||||
@ -1458,7 +1458,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
<br/><br/>
|
||||
</p>
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoMisc">IGMP, ESP, AH, UDPLITE, 'ALL'</a></h5>
|
||||
<h5><a id="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/>
|
||||
@ -1563,7 +1563,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
</p>
|
||||
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoTCP-ipv6">TCP/UDP/SCTP over IPV6</a></h5>
|
||||
<h5><a id="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/>
|
||||
@ -1679,7 +1679,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
</p>
|
||||
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoICMPv6">ICMPv6</a></h5>
|
||||
<h5><a id="nwfelemsRulesProtoICMPv6">ICMPv6</a></h5>
|
||||
<p>
|
||||
Protocol ID: <code>icmpv6</code>
|
||||
<br/>
|
||||
@ -1779,7 +1779,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
<br/><br/>
|
||||
</p>
|
||||
|
||||
<h5><a name="nwfelemsRulesProtoMiscv6">ESP, AH, UDPLITE, 'ALL' over IPv6</a></h5>
|
||||
<h5><a id="nwfelemsRulesProtoMiscv6">ESP, AH, UDPLITE, 'ALL' over IPv6</a></h5>
|
||||
<p>
|
||||
Protocol ID: <code>esp-ipv6</code>, <code>ah-ipv6</code>, <code>udplite-ipv6</code>, <code>all-ipv6</code>
|
||||
<br/>
|
||||
@ -1868,13 +1868,13 @@ DSTPORTS = [ 80, 8080 ]
|
||||
<br/><br/>
|
||||
</p>
|
||||
|
||||
<h3><a name="nwfelemsRulesAdv">Advanced Filter Configuration Topics</a></h3>
|
||||
<h3><a id="nwfelemsRulesAdv">Advanced Filter Configuration Topics</a></h3>
|
||||
<p>
|
||||
The following sections discuss advanced filter configuration
|
||||
topics.
|
||||
</p>
|
||||
|
||||
<h4><a name="nwfelemsRulesAdvTracking">Connection tracking</a></h4>
|
||||
<h4><a id="nwfelemsRulesAdvTracking">Connection tracking</a></h4>
|
||||
<p>
|
||||
The network filtering subsystem (on Linux) makes use of the connection
|
||||
tracking support of iptables. This helps in enforcing the
|
||||
@ -1908,7 +1908,7 @@ DSTPORTS = [ 80, 8080 ]
|
||||
which may or may not be desirable.
|
||||
</p>
|
||||
|
||||
<h4><a name="nwfelemsRulesAdvLimiting">Limiting Number of Connections</a></h4>
|
||||
<h4><a id="nwfelemsRulesAdvLimiting">Limiting Number of Connections</a></h4>
|
||||
<p>
|
||||
To limit the number of connections a VM may establish, a rule must
|
||||
be provided that sets a limit of connections for a given
|
||||
@ -1981,7 +1981,7 @@ echo 3 > /proc/sys/net/netfilter/nf_conntrack_icmp_timeout
|
||||
traffic behavior in relation to idle connections.
|
||||
</p>
|
||||
|
||||
<h2><a name="nwfcli">Command line tools</a></h2>
|
||||
<h2><a id="nwfcli">Command line tools</a></h2>
|
||||
<p>
|
||||
The libvirt command line tool <code>virsh</code> has been extended
|
||||
with life-cycle support for network filters. All commands related
|
||||
@ -1996,7 +1996,7 @@ echo 3 > /proc/sys/net/netfilter/nf_conntrack_icmp_timeout
|
||||
<li>nwfilter-edit : edit a network filter given its name</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="nwfexamples">Pre-existing network filters</a></h2>
|
||||
<h2><a id="nwfexamples">Pre-existing network filters</a></h2>
|
||||
<p>
|
||||
The following is a list of example network filters that are
|
||||
automatically installed with libvirt.</p>
|
||||
@ -2051,7 +2051,7 @@ echo 3 > /proc/sys/net/netfilter/nf_conntrack_icmp_timeout
|
||||
on top of the prevention of packet spoofing.
|
||||
</p>
|
||||
|
||||
<h2><a name="nwfwrite">Writing your own filters</a></h2>
|
||||
<h2><a id="nwfwrite">Writing your own filters</a></h2>
|
||||
|
||||
<p>
|
||||
Since libvirt only provides a couple of example networking filters, you
|
||||
@ -2124,7 +2124,7 @@ echo 3 > /proc/sys/net/netfilter/nf_conntrack_icmp_timeout
|
||||
<code>udp-ipv6</code> traffic filtering node.
|
||||
</p>
|
||||
|
||||
<h3><a name="nwfwriteexample">Example custom filter</a></h3>
|
||||
<h3><a id="nwfwriteexample">Example custom filter</a></h3>
|
||||
<p>
|
||||
As an example we want to now build a filter that fulfills the following
|
||||
list of requirements:
|
||||
@ -2227,7 +2227,7 @@ echo 3 > /proc/sys/net/netfilter/nf_conntrack_icmp_timeout
|
||||
</rule>
|
||||
</pre>
|
||||
|
||||
<h3><a name="nwfwriteexample2nd">Second example custom filter</a></h3>
|
||||
<h3><a id="nwfwriteexample2nd">Second example custom filter</a></h3>
|
||||
<p>
|
||||
In this example we now want to build a similar filter as in the
|
||||
example above, but extend the list of requirements with an
|
||||
@ -2400,13 +2400,13 @@ modprobe ip_conntrack_ftp # if above is not available
|
||||
|
||||
</pre>
|
||||
|
||||
<h2><a name="nwflimits">Limitations</a></h2>
|
||||
<h2><a id="nwflimits">Limitations</a></h2>
|
||||
<p>
|
||||
The following sections list (current) limitations of the network
|
||||
filtering subsystem.
|
||||
</p>
|
||||
|
||||
<h3><a name="nwflimitsmigr">VM Migration</a></h3>
|
||||
<h3><a id="nwflimitsmigr">VM Migration</a></h3>
|
||||
<p>
|
||||
VM migration is only supported if the whole filter tree
|
||||
that is referenced by a virtual machine's top level filter
|
||||
@ -2424,7 +2424,7 @@ modprobe ip_conntrack_ftp # if above is not available
|
||||
0.8.1 or later in order not to lose the network traffic filters
|
||||
associated with an interface.
|
||||
</p>
|
||||
<h3><a name="nwflimitsvlan">VLAN filtering on Linux</a></h3>
|
||||
<h3><a id="nwflimitsvlan">VLAN filtering on Linux</a></h3>
|
||||
<p>
|
||||
VLAN (802.1Q) packets, if sent by a virtual machine, cannot be filtered
|
||||
with rules for protocol IDs <code>arp</code>, <code>rarp</code>,
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="SecretAttributes">Secret XML</a></h2>
|
||||
<h2><a id="SecretAttributes">Secret XML</a></h2>
|
||||
|
||||
<p>
|
||||
Secrets stored by libvirt may have attributes associated with them, using
|
||||
@ -47,7 +47,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="VolumeUsageType">Usage type "volume"</a></h3>
|
||||
<h3><a id="VolumeUsageType">Usage type "volume"</a></h3>
|
||||
|
||||
<p>
|
||||
This secret is associated with a volume, whether the format is either
|
||||
@ -120,7 +120,7 @@ Secret value set
|
||||
#
|
||||
</pre>
|
||||
|
||||
<h3><a name="CephUsageType">Usage type "ceph"</a></h3>
|
||||
<h3><a id="CephUsageType">Usage type "ceph"</a></h3>
|
||||
<p>
|
||||
This secret is associated with a Ceph RBD (rados block device).
|
||||
The <code><usage type='ceph'></code> element must contain
|
||||
@ -187,7 +187,7 @@ Secret value set
|
||||
</auth>
|
||||
</pre>
|
||||
|
||||
<h3><a name="iSCSIUsageType">Usage type "iscsi"</a></h3>
|
||||
<h3><a id="iSCSIUsageType">Usage type "iscsi"</a></h3>
|
||||
|
||||
<p>
|
||||
This secret is associated with an iSCSI target for CHAP authentication.
|
||||
@ -272,7 +272,7 @@ Secret value set
|
||||
</auth>
|
||||
</pre>
|
||||
|
||||
<h3><a name="tlsUsageType">Usage type "tls"</a></h3>
|
||||
<h3><a id="tlsUsageType">Usage type "tls"</a></h3>
|
||||
|
||||
<p>
|
||||
This secret may be used in order to provide the passphrase for the
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="SnapshotAttributes">Snapshot XML</a></h2>
|
||||
<h2><a id="SnapshotAttributes">Snapshot XML</a></h2>
|
||||
|
||||
<p>
|
||||
There are several types of snapshots:
|
||||
@ -243,7 +243,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a name="example">Examples</a></h2>
|
||||
<h2><a id="example">Examples</a></h2>
|
||||
|
||||
<p>Using this XML to create a disk snapshot of just vda on a qemu
|
||||
domain with two disks:</p>
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="StoragePool">Storage pool XML</a></h2>
|
||||
<h2><a id="StoragePool">Storage pool XML</a></h2>
|
||||
|
||||
<p>
|
||||
Although all storage pool backends share the same public APIs and
|
||||
@ -29,7 +29,7 @@
|
||||
3.1.0</span>). This corresponds to the
|
||||
storage backend drivers listed further along in this document.
|
||||
</p>
|
||||
<h3><a name="StoragePoolFirst">General metadata</a></h3>
|
||||
<h3><a id="StoragePoolFirst">General metadata</a></h3>
|
||||
|
||||
<pre>
|
||||
<pool type="iscsi">
|
||||
@ -66,7 +66,7 @@
|
||||
pool. <span class="since">Since 0.4.1</span></dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="StoragePoolSource">Source elements</a></h3>
|
||||
<h3><a id="StoragePoolSource">Source elements</a></h3>
|
||||
|
||||
<p>
|
||||
A single <code>source</code> element is contained within the top level
|
||||
@ -397,7 +397,7 @@
|
||||
is backend specific. <span class="since">Since 0.8.4</span></dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="StoragePoolTarget">Target elements</a></h3>
|
||||
<h3><a id="StoragePoolTarget">Target elements</a></h3>
|
||||
|
||||
<p>
|
||||
A single <code>target</code> element is contained within the top level
|
||||
@ -461,7 +461,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="StoragePoolExtents">Device extents</a></h3>
|
||||
<h3><a id="StoragePoolExtents">Device extents</a></h3>
|
||||
|
||||
<p>
|
||||
If a storage pool exposes information about its underlying
|
||||
@ -481,7 +481,7 @@
|
||||
device, measured in bytes. <span class="since">Since 0.4.1</span>
|
||||
</p>
|
||||
|
||||
<h2><a name="StorageVol">Storage volume XML</a></h2>
|
||||
<h2><a id="StorageVol">Storage volume XML</a></h2>
|
||||
<p>
|
||||
A storage volume will generally be either a file or a device
|
||||
node; <span class="since">since 1.2.0</span>, an optional
|
||||
@ -491,7 +491,7 @@
|
||||
XML format is available <span class="since">since 0.4.1</span>
|
||||
</p>
|
||||
|
||||
<h3><a name="StorageVolFirst">General metadata</a></h3>
|
||||
<h3><a id="StorageVolFirst">General metadata</a></h3>
|
||||
|
||||
<pre>
|
||||
<volume type='file'>
|
||||
@ -570,7 +570,7 @@
|
||||
on the local host. <span class="since">Since 0.4.1</span></dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="StorageVolTarget">Target elements</a></h3>
|
||||
<h3><a id="StorageVolTarget">Target elements</a></h3>
|
||||
|
||||
<p>
|
||||
A single <code>target</code> element is contained within the top level
|
||||
@ -686,7 +686,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="StorageVolBacking">Backing store elements</a></h3>
|
||||
<h3><a id="StorageVolBacking">Backing store elements</a></h3>
|
||||
|
||||
<p>
|
||||
A single <code>backingStore</code> element is contained within the top level
|
||||
@ -732,14 +732,14 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a name="examples">Example configuration</a></h2>
|
||||
<h2><a id="examples">Example configuration</a></h2>
|
||||
|
||||
<p>
|
||||
Here are a couple of examples, for a more complete set demonstrating
|
||||
every type of storage pool, consult the <a href="storage.html">storage driver page</a>
|
||||
</p>
|
||||
|
||||
<h3><a name="exampleFile">File based storage pool</a></h3>
|
||||
<h3><a id="exampleFile">File based storage pool</a></h3>
|
||||
|
||||
<pre>
|
||||
<pool type="dir">
|
||||
@ -749,7 +749,7 @@
|
||||
</target>
|
||||
</pool></pre>
|
||||
|
||||
<h3><a name="exampleISCSI">iSCSI based storage pool</a></h3>
|
||||
<h3><a id="exampleISCSI">iSCSI based storage pool</a></h3>
|
||||
|
||||
<pre>
|
||||
<pool type="iscsi">
|
||||
@ -766,7 +766,7 @@
|
||||
</target>
|
||||
</pool></pre>
|
||||
|
||||
<h3><a name="exampleVol">Storage volume</a></h3>
|
||||
<h3><a id="exampleVol">Storage volume</a></h3>
|
||||
|
||||
<pre>
|
||||
<volume>
|
||||
@ -784,7 +784,7 @@
|
||||
</target>
|
||||
</volume></pre>
|
||||
|
||||
<h3><a name="exampleLuks">Storage volume using LUKS</a></h3>
|
||||
<h3><a id="exampleLuks">Storage volume using LUKS</a></h3>
|
||||
|
||||
<pre>
|
||||
<volume>
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="StorageEncryption">Storage volume encryption XML</a></h2>
|
||||
<h2><a id="StorageEncryption">Storage volume encryption XML</a></h2>
|
||||
|
||||
<p>
|
||||
Storage volumes may be encrypted, the XML snippet described below is used
|
||||
@ -37,7 +37,7 @@
|
||||
secret value at the time of volume creation, and store it using the
|
||||
specified <code>uuid</code>.
|
||||
</p>
|
||||
<h3><a name="StorageEncryptionDefault">"default" format</a></h3>
|
||||
<h3><a id="StorageEncryptionDefault">"default" format</a></h3>
|
||||
<p>
|
||||
<code><encryption format="default"/></code> can be specified only
|
||||
when creating a qcow volume. If the volume is successfully created, the
|
||||
@ -47,7 +47,7 @@
|
||||
in later operations with the volume, or when setting up a domain that
|
||||
uses the volume.
|
||||
</p>
|
||||
<h3><a name="StorageEncryptionQcow">"qcow" format</a></h3>
|
||||
<h3><a id="StorageEncryptionQcow">"qcow" format</a></h3>
|
||||
<p>
|
||||
The <code>qcow</code> format specifies that the built-in encryption
|
||||
support in <code>qcow</code>- or <code>qcow2</code>-formatted volume
|
||||
@ -56,7 +56,7 @@
|
||||
the <code>secret</code> element is not present during volume creation,
|
||||
a secret is automatically generated and attached to the volume.
|
||||
</p>
|
||||
<h3><a name="StorageEncryptionLuks">"luks" format</a></h3>
|
||||
<h3><a id="StorageEncryptionLuks">"luks" format</a></h3>
|
||||
<p>
|
||||
The <code>luks</code> format is specific to a luks encrypted volume
|
||||
and the secret is used in order to either encrypt during volume creation
|
||||
@ -119,7 +119,7 @@
|
||||
</dl>
|
||||
|
||||
|
||||
<h2><a name="example">Examples</a></h2>
|
||||
<h2><a id="example">Examples</a></h2>
|
||||
|
||||
<p>
|
||||
Here is a simple example, specifying use of the <code>qcow</code> format:
|
||||
|
@ -14,7 +14,7 @@
|
||||
influence, within the community.
|
||||
</p>
|
||||
|
||||
<h2><a name="codeofconduct">Code of conduct</a></h2>
|
||||
<h2><a id="codeofconduct">Code of conduct</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt project community covers people from a wide variety of
|
||||
@ -49,7 +49,7 @@
|
||||
from them. Playing a blame game doesn't help anyone.</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="roles">Roles and responsibilities</a></h2>
|
||||
<h2><a id="roles">Roles and responsibilities</a></h2>
|
||||
|
||||
<h3><a href="users">Users</a></h3>
|
||||
|
||||
@ -91,7 +91,7 @@
|
||||
ways listed in the next section.
|
||||
</p>
|
||||
|
||||
<h3><a name="contributors">Contributors</a></h3>
|
||||
<h3><a id="contributors">Contributors</a></h3>
|
||||
|
||||
<p>
|
||||
The contributors are community members who have some concrete impact
|
||||
@ -156,7 +156,7 @@
|
||||
covered are found in the source repositories, or website in question.
|
||||
</p>
|
||||
|
||||
<h3><a name="committers">Committers</a></h3>
|
||||
<h3><a id="committers">Committers</a></h3>
|
||||
|
||||
<p>
|
||||
The committers are the subset of contributors who have direct access
|
||||
@ -227,7 +227,7 @@
|
||||
to retain their role as a committer.
|
||||
</p>
|
||||
|
||||
<h3><a name="secteam">Security team</a></h3>
|
||||
<h3><a id="secteam">Security team</a></h3>
|
||||
|
||||
<p>
|
||||
The security team consists of a subset of the project committers
|
||||
@ -252,7 +252,7 @@
|
||||
before disclosing a private issue.
|
||||
</p>
|
||||
|
||||
<h2><a name="roughconsensus">Rough consensus</a></h2>
|
||||
<h2><a id="roughconsensus">Rough consensus</a></h2>
|
||||
|
||||
<p>
|
||||
A core concept for governance of the project described above is
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="patches">General tips for contributing patches</a></h2>
|
||||
<h2><a id="patches">General tips for contributing patches</a></h2>
|
||||
<ol>
|
||||
<li>
|
||||
<p>Discuss any large changes on the mailing list first. Post patches
|
||||
@ -336,7 +336,7 @@
|
||||
Richard Jones' guide to working with open source projects</a>.
|
||||
</p>
|
||||
|
||||
<h2><a name="tooling">Tooling</a></h2>
|
||||
<h2><a id="tooling">Tooling</a></h2>
|
||||
|
||||
<p>
|
||||
libvirt includes support for some useful development tools right in its
|
||||
@ -356,7 +356,7 @@
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="naming">Naming conventions</a></h2>
|
||||
<h2><a id="naming">Naming conventions</a></h2>
|
||||
|
||||
<p>
|
||||
When reading libvirt code, a number of different naming conventions will
|
||||
@ -450,7 +450,7 @@
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h2><a name="indent">Code indentation</a></h2>
|
||||
<h2><a id="indent">Code indentation</a></h2>
|
||||
<p>
|
||||
Libvirt's C source code generally adheres to some basic code-formatting
|
||||
conventions. The existing code base is not totally consistent on this
|
||||
@ -487,7 +487,7 @@
|
||||
which will load the .lvimrc only when you edit libvirt code.
|
||||
</p>
|
||||
|
||||
<h2><a name="formatting">Code formatting (especially for new code)</a></h2>
|
||||
<h2><a id="formatting">Code formatting (especially for new code)</a></h2>
|
||||
|
||||
<p>
|
||||
With new code, we can be even more strict.
|
||||
@ -523,7 +523,7 @@
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a name="bracket_spacing">Bracket spacing</a></h2>
|
||||
<h2><a id="bracket_spacing">Bracket spacing</a></h2>
|
||||
|
||||
<p>
|
||||
The keywords <code>if</code>, <code>for</code>, <code>while</code>,
|
||||
@ -572,7 +572,7 @@
|
||||
int foo(int wizz); // Good
|
||||
</pre>
|
||||
|
||||
<h2><a name="comma">Commas</a></h2>
|
||||
<h2><a id="comma">Commas</a></h2>
|
||||
|
||||
<p>
|
||||
Commas should always be followed by a space or end of line, and
|
||||
@ -609,7 +609,7 @@
|
||||
};
|
||||
</pre>
|
||||
|
||||
<h2><a name="semicolon">Semicolons</a></h2>
|
||||
<h2><a id="semicolon">Semicolons</a></h2>
|
||||
|
||||
<p>
|
||||
Semicolons should never have a space beforehand. Inside the
|
||||
@ -638,7 +638,7 @@
|
||||
}
|
||||
</pre>
|
||||
|
||||
<h2><a name="curly_braces">Curly braces</a></h2>
|
||||
<h2><a id="curly_braces">Curly braces</a></h2>
|
||||
|
||||
<p>
|
||||
Omit the curly braces around an <code>if</code>, <code>while</code>,
|
||||
@ -819,7 +819,7 @@
|
||||
}
|
||||
</pre>
|
||||
|
||||
<h2><a name="preprocessor">Preprocessor</a></h2>
|
||||
<h2><a id="preprocessor">Preprocessor</a></h2>
|
||||
|
||||
<p>Macros defined with an ALL_CAPS name should generally be
|
||||
assumed to be unsafe with regards to arguments with side-effects
|
||||
@ -844,7 +844,7 @@
|
||||
#endif
|
||||
</pre>
|
||||
|
||||
<h2><a name="types">C types</a></h2>
|
||||
<h2><a id="types">C types</a></h2>
|
||||
|
||||
<p>
|
||||
Use the right type.
|
||||
@ -919,7 +919,7 @@
|
||||
it points to, or it is aliased to another pointer that is.
|
||||
</p>
|
||||
|
||||
<h2><a name="memalloc">Low level memory management</a></h2>
|
||||
<h2><a id="memalloc">Low level memory management</a></h2>
|
||||
|
||||
<p>
|
||||
Use of the malloc/free/realloc/calloc APIs is deprecated in the libvirt
|
||||
@ -1013,7 +1013,7 @@
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="file_handling">File handling</a></h2>
|
||||
<h2><a id="file_handling">File handling</a></h2>
|
||||
|
||||
<p>
|
||||
Usage of the <code>fdopen()</code>, <code>close()</code>, <code>fclose()</code>
|
||||
@ -1059,7 +1059,7 @@
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="string_comparision">String comparisons</a></h2>
|
||||
<h2><a id="string_comparision">String comparisons</a></h2>
|
||||
|
||||
<p>
|
||||
Do not use the strcmp, strncmp, etc functions directly. Instead use
|
||||
@ -1109,7 +1109,7 @@
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="string_copying">String copying</a></h2>
|
||||
<h2><a id="string_copying">String copying</a></h2>
|
||||
|
||||
<p>
|
||||
Do not use the strncpy function. According to the man page, it
|
||||
@ -1169,7 +1169,7 @@
|
||||
and usually considered a flaw.
|
||||
</p>
|
||||
|
||||
<h2><a name="strbuf">Variable length string buffer</a></h2>
|
||||
<h2><a id="strbuf">Variable length string buffer</a></h2>
|
||||
|
||||
<p>
|
||||
If there is a need for complex string concatenations, avoid using
|
||||
@ -1202,7 +1202,7 @@
|
||||
</pre>
|
||||
|
||||
|
||||
<h2><a name="includes">Include files</a></h2>
|
||||
<h2><a id="includes">Include files</a></h2>
|
||||
|
||||
<p>
|
||||
There are now quite a large number of include files, both libvirt
|
||||
@ -1251,7 +1251,7 @@
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a name="printf">Printf-style functions</a></h2>
|
||||
<h2><a id="printf">Printf-style functions</a></h2>
|
||||
|
||||
<p>
|
||||
Whenever you add a new printf-style function, i.e., one with a format
|
||||
@ -1280,7 +1280,7 @@
|
||||
does for snprintf.
|
||||
</p>
|
||||
|
||||
<h2><a name="goto">Use of goto</a></h2>
|
||||
<h2><a id="goto">Use of goto</a></h2>
|
||||
|
||||
<p>
|
||||
The use of goto is not forbidden, and goto is widely used
|
||||
@ -1363,7 +1363,7 @@ int foo()
|
||||
|
||||
|
||||
|
||||
<h2><a name="committers">Libvirt committer guidelines</a></h2>
|
||||
<h2><a id="committers">Libvirt committer guidelines</a></h2>
|
||||
|
||||
<p>
|
||||
The AUTHORS files indicates the list of people with commit access right
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="intro">Custom event scripts</a></h2>
|
||||
<h2><a id="intro">Custom event scripts</a></h2>
|
||||
<p>Beginning with libvirt 0.8.0, specific events on a host system will
|
||||
trigger custom scripts.</p>
|
||||
<p>These custom <b>hook</b> scripts are executed when any of the following
|
||||
@ -26,7 +26,7 @@
|
||||
(<span class="since">since 1.2.2</span>)<br/><br/></li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="location">Script location</a></h2>
|
||||
<h2><a id="location">Script location</a></h2>
|
||||
<p>The libvirt hook scripts are located in the directory
|
||||
<code>$SYSCONFDIR/libvirt/hooks/</code>.</p>
|
||||
<ul>
|
||||
@ -42,7 +42,7 @@
|
||||
them executable.</p>
|
||||
<br/>
|
||||
|
||||
<h2><a name="names">Script names</a></h2>
|
||||
<h2><a id="names">Script names</a></h2>
|
||||
<p>At present, there are five hook scripts that can be called:</p>
|
||||
<ul>
|
||||
<li><code>/etc/libvirt/hooks/daemon</code><br/><br/>
|
||||
@ -61,7 +61,7 @@
|
||||
</ul>
|
||||
<br/>
|
||||
|
||||
<h2><a name="structure">Script structure</a></h2>
|
||||
<h2><a id="structure">Script structure</a></h2>
|
||||
<p>The hook scripts are executed using standard Linux process creation
|
||||
functions. Therefore, they must begin with the declaration of the
|
||||
command interpreter to use.</p>
|
||||
@ -73,7 +73,7 @@
|
||||
binary, so you are welcome to use your favourite languages.</p>
|
||||
<br/>
|
||||
|
||||
<h2><a name="arguments">Script arguments</a></h2>
|
||||
<h2><a id="arguments">Script arguments</a></h2>
|
||||
<p>The hook scripts are called with specific command line arguments,
|
||||
depending upon the script, and the operation being performed.</p>
|
||||
<p>The guest hook scripts, qemu and lxc, are also given the <b>full</b>
|
||||
@ -128,10 +128,10 @@
|
||||
none.</li>
|
||||
</ol>
|
||||
|
||||
<h4><a name="arguments_specifics">Specifics</a></h4>
|
||||
<h4><a id="arguments_specifics">Specifics</a></h4>
|
||||
<p>This translates to the following specifics for each hook script:</p>
|
||||
|
||||
<h5><a name="daemon">/etc/libvirt/hooks/daemon</a></h5>
|
||||
<h5><a id="daemon">/etc/libvirt/hooks/daemon</a></h5>
|
||||
<ul>
|
||||
<li>When the libvirt daemon is started, this script is called as:<br/>
|
||||
<pre>/etc/libvirt/hooks/daemon - start - start</pre></li>
|
||||
@ -146,7 +146,7 @@
|
||||
with the "start" operation. There is no specific operation to indicate
|
||||
a "restart" is occurring.</p>
|
||||
|
||||
<h5><a name="qemu">/etc/libvirt/hooks/qemu</a></h5>
|
||||
<h5><a id="qemu">/etc/libvirt/hooks/qemu</a></h5>
|
||||
<ul>
|
||||
<li>Before a QEMU guest is started, the qemu hook script is
|
||||
called in three locations; if any location fails, the guest
|
||||
@ -206,7 +206,7 @@
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h5><a name="lxc">/etc/libvirt/hooks/lxc</a></h5>
|
||||
<h5><a id="lxc">/etc/libvirt/hooks/lxc</a></h5>
|
||||
<ul>
|
||||
<li>Before a LXC guest is started, the lxc hook script is
|
||||
called in three locations; if any location fails, the guest
|
||||
@ -240,7 +240,7 @@
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h5><a name="libxl">/etc/libvirt/hooks/libxl</a></h5>
|
||||
<h5><a id="libxl">/etc/libvirt/hooks/libxl</a></h5>
|
||||
<ul>
|
||||
<li>Before a Xen guest is started using libxl driver, the libxl hook
|
||||
script is called in three locations; if any location fails, the guest
|
||||
@ -284,7 +284,7 @@
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h5><a name="network">/etc/libvirt/hooks/network</a></h5>
|
||||
<h5><a id="network">/etc/libvirt/hooks/network</a></h5>
|
||||
<ul>
|
||||
<li><span class="since">Since 1.2.2</span>, before a network is started,
|
||||
this script is called as:<br/>
|
||||
@ -310,7 +310,7 @@
|
||||
|
||||
<br/>
|
||||
|
||||
<h2><a name="execution">Script execution</a></h2>
|
||||
<h2><a id="execution">Script execution</a></h2>
|
||||
<ul>
|
||||
<li>The "start" operation for the guest and network hook scripts,
|
||||
executes <b>prior</b> to the object (guest or network) being created.
|
||||
@ -335,7 +335,7 @@
|
||||
</ul>
|
||||
<br/>
|
||||
|
||||
<h2><a name="qemu_migration">QEMU guest migration</a></h2>
|
||||
<h2><a id="qemu_migration">QEMU guest migration</a></h2>
|
||||
<p>Migration of a QEMU guest involves running hook scripts on both the
|
||||
source and destination hosts:</p>
|
||||
<ol>
|
||||
@ -357,14 +357,14 @@
|
||||
</ol>
|
||||
<br/>
|
||||
|
||||
<h2><a name="recursive">Calling libvirt functions from within a hook script</a></h2>
|
||||
<h2><a id="recursive">Calling libvirt functions from within a hook script</a></h2>
|
||||
<p><b>DO NOT DO THIS!</b></p>
|
||||
<p>A hook script must not call back into libvirt, as the libvirt daemon
|
||||
is already waiting for the script to exit.</p>
|
||||
<p>A deadlock is likely to occur.</p>
|
||||
<br/>
|
||||
|
||||
<h2><a name="return_codes">Return codes and logging</a></h2>
|
||||
<h2><a id="return_codes">Return codes and logging</a></h2>
|
||||
<p>If a hook script returns with an exit code of 0, the libvirt daemon
|
||||
regards this as successful and performs no logging of it.</p>
|
||||
<p>However, if a hook script returns with a non zero exit code, the libvirt
|
||||
|
@ -12,7 +12,7 @@
|
||||
All code is required to use these APIs
|
||||
</p>
|
||||
|
||||
<h2><a name="posix">Problems with standard POSIX APIs</a></h2>
|
||||
<h2><a id="posix">Problems with standard POSIX APIs</a></h2>
|
||||
|
||||
<p>
|
||||
The POSIX specification includes a number of APIs for
|
||||
@ -62,7 +62,7 @@
|
||||
error prone, particularly wrt memory leak / OOM handling.
|
||||
</p>
|
||||
|
||||
<h2><a name="api">The libvirt command execution API</a></h2>
|
||||
<h2><a id="api">The libvirt command execution API</a></h2>
|
||||
|
||||
<p>
|
||||
There is now a high level API that provides a safe and
|
||||
@ -72,7 +72,7 @@
|
||||
header which can be imported using <code>#include "vircommand.h"</code>
|
||||
</p>
|
||||
|
||||
<h3><a name="initial">Defining commands in libvirt</a></h3>
|
||||
<h3><a id="initial">Defining commands in libvirt</a></h3>
|
||||
|
||||
<p>
|
||||
The first step is to declare what command is to be
|
||||
@ -92,7 +92,7 @@ virCommandPtr cmd = virCommandNew("/usr/bin/dnsmasq");
|
||||
reported at a later time.
|
||||
</p>
|
||||
|
||||
<h3><a name="args">Adding arguments to the command</a></h3>
|
||||
<h3><a id="args">Adding arguments to the command</a></h3>
|
||||
|
||||
<p>
|
||||
There are a number of APIs for adding arguments to a
|
||||
@ -150,7 +150,7 @@ virCommandPtr cmd2 = virCommandNewArgList("/usr/bin/dnsmasq",
|
||||
"--domain", "localdomain", NULL);
|
||||
</pre>
|
||||
|
||||
<h3><a name="env">Setting up the environment</a></h3>
|
||||
<h3><a id="env">Setting up the environment</a></h3>
|
||||
|
||||
<p>
|
||||
By default a command will inherit all environment variables
|
||||
@ -199,7 +199,7 @@ virCommandAddEnvPair(cmd, "TERM", "xterm");
|
||||
virCommandAddEnvString(cmd, "TERM=xterm");
|
||||
</pre>
|
||||
|
||||
<h3><a name="misc">Miscellaneous other options</a></h3>
|
||||
<h3><a id="misc">Miscellaneous other options</a></h3>
|
||||
|
||||
<p>
|
||||
Normally the spawned command will retain the current
|
||||
@ -229,7 +229,7 @@ virCommandSetPidFile(cmd, "/var/run/dnsmasq.pid");
|
||||
the intermediate process exits.
|
||||
</p>
|
||||
|
||||
<h3><a name="privs">Reducing command privileges</a></h3>
|
||||
<h3><a id="privs">Reducing command privileges</a></h3>
|
||||
|
||||
<p>
|
||||
Normally a command will inherit all privileges of
|
||||
@ -243,7 +243,7 @@ virCommandSetPidFile(cmd, "/var/run/dnsmasq.pid");
|
||||
virCommandClearCaps(cmd);
|
||||
</pre>
|
||||
|
||||
<h3><a name="fds">Managing file handles</a></h3>
|
||||
<h3><a id="fds">Managing file handles</a></h3>
|
||||
|
||||
<p>
|
||||
To prevent unintended resource leaks to child processes, the
|
||||
@ -329,7 +329,7 @@ virCommandSetErrorFD(cmd, &errfd);
|
||||
virCommandNonblockingFDs(cmd);
|
||||
</pre>
|
||||
|
||||
<h3><a name="buffers">Feeding & capturing strings to/from the child</a></h3>
|
||||
<h3><a id="buffers">Feeding & capturing strings to/from the child</a></h3>
|
||||
|
||||
<p>
|
||||
Often dealing with file handles for stdin/out/err is
|
||||
@ -382,7 +382,7 @@ virCommandSetErrorBuffer(cmd, &errors);
|
||||
case the child process interleaves output into a single string.
|
||||
</p>
|
||||
|
||||
<h3><a name="directory">Setting working directory</a></h3>
|
||||
<h3><a id="directory">Setting working directory</a></h3>
|
||||
|
||||
<p>
|
||||
Daemonized commands are always run with "/" as the current
|
||||
@ -395,7 +395,7 @@ virCommandSetErrorBuffer(cmd, &errors);
|
||||
virCommandSetWorkingDirectory(cmd, LOCALSTATEDIR);
|
||||
</pre>
|
||||
|
||||
<h3><a name="hooks">Any additional hooks</a></h3>
|
||||
<h3><a id="hooks">Any additional hooks</a></h3>
|
||||
|
||||
<p>
|
||||
If anything else is needed, it is possible to request a hook
|
||||
@ -409,7 +409,7 @@ virCommandSetWorkingDirectory(cmd, LOCALSTATEDIR);
|
||||
virCommandSetPreExecHook(cmd, hook, opaque);
|
||||
</pre>
|
||||
|
||||
<h3><a name="logging">Logging commands</a></h3>
|
||||
<h3><a id="logging">Logging commands</a></h3>
|
||||
|
||||
<p>
|
||||
Sometimes, it is desirable to log what command will be run, or
|
||||
@ -434,7 +434,7 @@ if (virCommandRun(cmd, NULL) < 0)
|
||||
return -1;
|
||||
</pre>
|
||||
|
||||
<h3><a name="sync">Running commands synchronously</a></h3>
|
||||
<h3><a id="sync">Running commands synchronously</a></h3>
|
||||
|
||||
<p>
|
||||
For most commands, the desired behaviour is to spawn
|
||||
@ -480,7 +480,7 @@ if (WIFEXITED(status) && WEXITSTATUS(status) == 1) {
|
||||
}
|
||||
</pre>
|
||||
|
||||
<h3><a name="async">Running commands asynchronously</a></h3>
|
||||
<h3><a id="async">Running commands asynchronously</a></h3>
|
||||
|
||||
<p>
|
||||
In certain complex scenarios, particularly special
|
||||
@ -530,7 +530,7 @@ if (WEXITSTATUS(status)...) {
|
||||
virCommandAbort to reap the process.
|
||||
</p>
|
||||
|
||||
<h3><a name="release">Releasing resources</a></h3>
|
||||
<h3><a id="release">Releasing resources</a></h3>
|
||||
|
||||
<p>
|
||||
Once the command has been executed, or if execution
|
||||
@ -550,7 +550,7 @@ virCommandFree(cmd);
|
||||
it will be forcibly killed and cleaned up (via waitpid).
|
||||
</p>
|
||||
|
||||
<h2><a name="example">Complete examples</a></h2>
|
||||
<h2><a id="example">Complete examples</a></h2>
|
||||
|
||||
<p>
|
||||
This shows a complete example usage of the APIs roughly
|
||||
|
@ -11,7 +11,7 @@
|
||||
libvirt. Both server and client.
|
||||
</p>
|
||||
|
||||
<h2><a name="event_loop">Event driven programming</a></h2>
|
||||
<h2><a id="event_loop">Event driven programming</a></h2>
|
||||
|
||||
<p>Traditionally, a program simply ran once, then terminated.
|
||||
This type of program was very common in the early days of
|
||||
@ -38,7 +38,7 @@
|
||||
file descriptor which is then watched for incoming events,
|
||||
e.g. messages. </p>
|
||||
|
||||
<h2><a name="api">The event loop API</a></h2>
|
||||
<h2><a id="api">The event loop API</a></h2>
|
||||
|
||||
<p>To work with event loop from our code we have plenty of
|
||||
APIs.</p>
|
||||
@ -62,7 +62,7 @@
|
||||
<p>For more information on these APIs continue reading <a
|
||||
href="../html/libvirt-libvirt-event.html">here</a>.</p>
|
||||
|
||||
<h2><a name="worker_pool">Worker pool</a></h2>
|
||||
<h2><a id="worker_pool">Worker pool</a></h2>
|
||||
|
||||
<p>Looking back at the image above we can see one big
|
||||
limitation. While processing a message event loop is blocked
|
||||
|
@ -12,7 +12,7 @@
|
||||
access to content.
|
||||
</p>
|
||||
|
||||
<h2><a name="goals">Goals</a></h2>
|
||||
<h2><a id="goals">Goals</a></h2>
|
||||
|
||||
<p>
|
||||
The high level goal is to prevent the same disk image being
|
||||
@ -36,7 +36,7 @@
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<h2><a name="requirement">Requirements</a></h2>
|
||||
<h2><a id="requirement">Requirements</a></h2>
|
||||
|
||||
<p>
|
||||
The high level goal leads to a set of requirements
|
||||
@ -67,7 +67,7 @@
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<h2><a name="design">Design</a></h2>
|
||||
<h2><a id="design">Design</a></h2>
|
||||
|
||||
<p>
|
||||
Within a lock manager the following series of operations
|
||||
@ -102,7 +102,7 @@
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="impl">Plugin Implementations</a></h2>
|
||||
<h2><a id="impl">Plugin Implementations</a></h2>
|
||||
|
||||
<p>
|
||||
Lock manager implementations are provided as LGPLv2+
|
||||
@ -132,7 +132,7 @@
|
||||
in the previously mentioned header file
|
||||
</p>
|
||||
|
||||
<h2><a name="qemuIntegrate">QEMU Driver integration</a></h2>
|
||||
<h2><a id="qemuIntegrate">QEMU Driver integration</a></h2>
|
||||
|
||||
<p>
|
||||
With the QEMU driver, the lock plugin will be set
|
||||
@ -149,7 +149,7 @@ lockManager="sanlock"
|
||||
for backwards compatibility
|
||||
</p>
|
||||
|
||||
<h2><a name="usagePatterns">Lock usage patterns</a></h2>
|
||||
<h2><a id="usagePatterns">Lock usage patterns</a></h2>
|
||||
|
||||
<p>
|
||||
The following pseudo code illustrates the common
|
||||
@ -157,7 +157,7 @@ lockManager="sanlock"
|
||||
manager plugin callbacks.
|
||||
</p>
|
||||
|
||||
<h3><a name="usageLockAcquire">Lock acquisition</a></h3>
|
||||
<h3><a id="usageLockAcquire">Lock acquisition</a></h3>
|
||||
|
||||
<p>
|
||||
Initial lock acquisition will be performed from the
|
||||
@ -205,7 +205,7 @@ if (virLockManagerAcquire(lock, NULL, 0) < 0);
|
||||
...abort...
|
||||
</pre>
|
||||
|
||||
<h3><a name="usageLockAttach">Lock release</a></h3>
|
||||
<h3><a id="usageLockAttach">Lock release</a></h3>
|
||||
|
||||
<p>
|
||||
The locks are all implicitly released when the process
|
||||
|
@ -26,7 +26,7 @@ $ ./configure --enable-test-oom
|
||||
</pre>
|
||||
|
||||
|
||||
<h2><a name="basicoom">Basic OOM testing support</a></h2>
|
||||
<h2><a id="basicoom">Basic OOM testing support</a></h2>
|
||||
|
||||
<p>
|
||||
The first step in validating OOM usage is to run a test suite
|
||||
@ -64,7 +64,7 @@ $ VIR_TEST_OOM=1 ./qemuxml2argvtest
|
||||
of memory allocations from that test case.
|
||||
</p>
|
||||
|
||||
<h3><a name="valgrind">Tracking failures with valgrind</a></h3>
|
||||
<h3><a id="valgrind">Tracking failures with valgrind</a></h3>
|
||||
|
||||
<p>
|
||||
The test suite should obviously *not* crash during OOM testing.
|
||||
@ -88,7 +88,7 @@ $ VIR_TEST_OOM=1 VIR_TEST_RANGE=5 ../run valgrind ./qemuxml2argvtest
|
||||
access.
|
||||
</p>
|
||||
|
||||
<h3><a name="stacktraces">Tracking failures with stack traces</a></h3>
|
||||
<h3><a id="stacktraces">Tracking failures with stack traces</a></h3>
|
||||
|
||||
<p>
|
||||
With some really difficult bugs valgrind is not sufficient to
|
||||
@ -191,7 +191,7 @@ _start
|
||||
??:?
|
||||
</pre>
|
||||
|
||||
<h3><a name="noncrash">Non-crash related problems</a></h3>
|
||||
<h3><a id="noncrash">Non-crash related problems</a></h3>
|
||||
|
||||
<p>
|
||||
Not all memory allocation bugs result in code crashing. Sometimes
|
||||
|
@ -17,7 +17,7 @@
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a name="protocol">RPC protocol</a></h2>
|
||||
<h2><a id="protocol">RPC protocol</a></h2>
|
||||
|
||||
<p>
|
||||
libvirt uses a simple, variable length, packet based RPC protocol.
|
||||
@ -193,14 +193,14 @@
|
||||
definition for the program+version in question
|
||||
</p>
|
||||
|
||||
<h3><a name="wireexamples">Wire examples</a></h3>
|
||||
<h3><a id="wireexamples">Wire examples</a></h3>
|
||||
|
||||
<p>
|
||||
The following diagrams illustrate some example packet exchanges
|
||||
between a client and server
|
||||
</p>
|
||||
|
||||
<h4><a name="wireexamplescall">Method call</a></h4>
|
||||
<h4><a id="wireexamplescall">Method call</a></h4>
|
||||
|
||||
<p>
|
||||
A single method call and successful
|
||||
@ -219,7 +219,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S (reply)
|
||||
+--+-----------------------+--------+
|
||||
</pre>
|
||||
|
||||
<h4><a name="wireexamplescallerr">Method call with error</a></h4>
|
||||
<h4><a id="wireexamplescallerr">Method call with error</a></h4>
|
||||
|
||||
<p>
|
||||
An unsuccessful method call will instead return an error object
|
||||
@ -235,7 +235,7 @@ C <-- |48| 8 | 1 | 3 | 2 | 1 | 0 | .o.oOo.o.oOo.o.oOo.o.oOo | <-- S (er
|
||||
+--+-----------------------+--------------------------+
|
||||
</pre>
|
||||
|
||||
<h4><a name="wireexamplescallup">Method call with upload stream</a></h4>
|
||||
<h4><a id="wireexamplescallup">Method call with upload stream</a></h4>
|
||||
|
||||
<p>
|
||||
A method call which also involves uploading some data over
|
||||
@ -272,7 +272,7 @@ C <-- |24| 8 | 1 | 3 | 3 | 1 | 0 | <-- S (stream finish)
|
||||
+--+-----------------------+
|
||||
</pre>
|
||||
|
||||
<h4><a name="wireexamplescallbi">Method call bidirectional stream</a></h4>
|
||||
<h4><a id="wireexamplescallbi">Method call bidirectional stream</a></h4>
|
||||
|
||||
<p>
|
||||
A method call which also involves a bi-directional stream will
|
||||
@ -328,7 +328,7 @@ C <-- |24| 8 | 1 | 3 | 3 | 1 | 0 | <-- S (stream finish)
|
||||
</pre>
|
||||
|
||||
|
||||
<h4><a name="wireexamplescallmany">Method calls overlapping</a></h4>
|
||||
<h4><a id="wireexamplescallmany">Method calls overlapping</a></h4>
|
||||
<pre>
|
||||
+--+-----------------------+-----------+
|
||||
C --> |38| 8 | 1 | 3 | 0 | 1 | 0 | .o.oOo.o. | --> S (call 1)
|
||||
@ -356,7 +356,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 4 | 0 | .o.oOo | <-- S (reply 4)
|
||||
+--+-----------------------+--------+
|
||||
</pre>
|
||||
|
||||
<h4><a name="wireexamplescallfd">Method call with passed FD</a></h4>
|
||||
<h4><a id="wireexamplescallfd">Method call with passed FD</a></h4>
|
||||
|
||||
<p>
|
||||
A single method call with 2 passed file descriptors and successful
|
||||
@ -378,14 +378,14 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S (reply)
|
||||
</pre>
|
||||
|
||||
|
||||
<h2><a name="security">RPC security</a></h2>
|
||||
<h2><a id="security">RPC security</a></h2>
|
||||
|
||||
<p>
|
||||
There are various things to consider to ensure an implementation
|
||||
of the RPC protocol can be satisfactorily secured
|
||||
</p>
|
||||
|
||||
<h3><a name="securitytls">Authentication/encryption</a></h3>
|
||||
<h3><a id="securitytls">Authentication/encryption</a></h3>
|
||||
|
||||
<p>
|
||||
The basic RPC protocol does not define or require any specific
|
||||
@ -399,7 +399,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S (reply)
|
||||
stream can of course be tunnelled over transports such as SSH.
|
||||
</p>
|
||||
|
||||
<h3><a name="securitylimits">Data limits</a></h3>
|
||||
<h3><a id="securitylimits">Data limits</a></h3>
|
||||
|
||||
<p>
|
||||
Although the protocol itself defines many arbitrary sized data values in the
|
||||
@ -411,7 +411,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S (reply)
|
||||
breaking compatibility of the RPC data on the wire.
|
||||
</p>
|
||||
|
||||
<h3><a name="securityvalidate">Data validation</a></h3>
|
||||
<h3><a id="securityvalidate">Data validation</a></h3>
|
||||
|
||||
<p>
|
||||
It is important that all data be fully validated before performing
|
||||
@ -427,7 +427,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S (reply)
|
||||
execution API (e.g. corresponding libvirt public API).
|
||||
</p>
|
||||
|
||||
<h2><a name="internals">RPC internal APIs</a></h2>
|
||||
<h2><a id="internals">RPC internal APIs</a></h2>
|
||||
|
||||
<p>
|
||||
The generic internal RPC library code lives in the <code>src/rpc/</code>
|
||||
@ -436,7 +436,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S (reply)
|
||||
purposes are:
|
||||
</p>
|
||||
|
||||
<h3><a name="apioverview">Overview of RPC objects</a></h3>
|
||||
<h3><a id="apioverview">Overview of RPC objects</a></h3>
|
||||
|
||||
<p>
|
||||
The following is a high level overview of the role of each
|
||||
@ -568,7 +568,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S (reply)
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="apiclientdispatch">Client RPC dispatch</a></h3>
|
||||
<h3><a id="apiclientdispatch">Client RPC dispatch</a></h3>
|
||||
|
||||
<p>
|
||||
The client RPC code must allow for multiple overlapping RPC method
|
||||
@ -601,7 +601,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S (reply)
|
||||
grabs the buck, and re-enabled when the buck is released.
|
||||
</p>
|
||||
|
||||
<h4><a name="apiclientdispatchex1">Example with buck passing</a></h4>
|
||||
<h4><a id="apiclientdispatchex1">Example with buck passing</a></h4>
|
||||
|
||||
<p>
|
||||
In the first example, a second thread issues an API call
|
||||
@ -649,7 +649,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S (reply)
|
||||
Return API2()
|
||||
</pre>
|
||||
|
||||
<h4><a name="apiclientdispatchex2">Example without buck passing</a></h4>
|
||||
<h4><a id="apiclientdispatchex2">Example without buck passing</a></h4>
|
||||
|
||||
<p>
|
||||
In this second example, a second thread issues an API call
|
||||
@ -699,7 +699,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S (reply)
|
||||
Return API1()
|
||||
</pre>
|
||||
|
||||
<h4><a name="apiclientdispatchex3">Example with async events</a></h4>
|
||||
<h4><a id="apiclientdispatchex3">Example with async events</a></h4>
|
||||
|
||||
<p>
|
||||
In this example, only one thread is present and it has to
|
||||
@ -739,7 +739,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S (reply)
|
||||
...
|
||||
</pre>
|
||||
|
||||
<h3><a name="apiserverdispatch">Server RPC dispatch</a></h3>
|
||||
<h3><a id="apiserverdispatch">Server RPC dispatch</a></h3>
|
||||
|
||||
<p>
|
||||
The RPC server code must support receipt of incoming RPC requests from
|
||||
@ -827,7 +827,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S (reply)
|
||||
queue.
|
||||
</p>
|
||||
|
||||
<h4><a name="apiserverdispatchex1">Example with overlapping methods</a></h4>
|
||||
<h4><a id="apiserverdispatchex1">Example with overlapping methods</a></h4>
|
||||
|
||||
<p>
|
||||
This example illustrates processing of two incoming methods with
|
||||
@ -874,7 +874,7 @@ C <-- |32| 8 | 1 | 3 | 1 | 1 | 0 | .o.oOo | <-- S (reply)
|
||||
...
|
||||
</pre>
|
||||
|
||||
<h4><a name="apiserverdispatchex2">Example with stream data</a></h4>
|
||||
<h4><a id="apiserverdispatchex2">Example with stream data</a></h4>
|
||||
|
||||
<p>
|
||||
This example illustrates processing of stream data
|
||||
|
@ -12,7 +12,7 @@
|
||||
plugin for virtual machine disk mutual exclusion.
|
||||
</p>
|
||||
|
||||
<h2><a name="background">virtlockd background</a></h2>
|
||||
<h2><a id="background">virtlockd background</a></h2>
|
||||
|
||||
<p>
|
||||
The virtlockd daemon is a single purpose binary which
|
||||
@ -26,7 +26,7 @@
|
||||
commonly used filesystems.
|
||||
</p>
|
||||
|
||||
<h2><a name="sanlock">virtlockd daemon setup</a></h2>
|
||||
<h2><a id="sanlock">virtlockd daemon setup</a></h2>
|
||||
|
||||
<p>
|
||||
In most OS, the virtlockd daemon itself will not require
|
||||
@ -53,7 +53,7 @@
|
||||
setup at all.
|
||||
</p>
|
||||
|
||||
<h2><a name="lockdplugin">libvirt lockd plugin configuration</a></h2>
|
||||
<h2><a id="lockdplugin">libvirt lockd plugin configuration</a></h2>
|
||||
|
||||
<p>
|
||||
Once the virtlockd daemon is running, or setup to autostart,
|
||||
@ -127,7 +127,7 @@ $ su - root
|
||||
the same locking mechanism
|
||||
</p>
|
||||
|
||||
<h2><a name="qemuconfig">QEMU/KVM driver configuration</a></h2>
|
||||
<h2><a id="qemuconfig">QEMU/KVM driver configuration</a></h2>
|
||||
|
||||
<p>
|
||||
The QEMU driver is capable of using the virtlockd plugin
|
||||
|
@ -13,7 +13,7 @@
|
||||
plugin for virtual machine disk mutual exclusion.
|
||||
</p>
|
||||
|
||||
<h2><a name="sanlock">Sanlock daemon setup</a></h2>
|
||||
<h2><a id="sanlock">Sanlock daemon setup</a></h2>
|
||||
|
||||
<p>
|
||||
On many operating systems, the <strong>sanlock</strong> plugin
|
||||
@ -68,7 +68,7 @@ SANLOCKOPTS="-w 0"
|
||||
steps as necessary.
|
||||
</p>
|
||||
|
||||
<h2><a name="sanlockplugin">libvirt sanlock plugin configuration</a></h2>
|
||||
<h2><a id="sanlockplugin">libvirt sanlock plugin configuration</a></h2>
|
||||
|
||||
<p>
|
||||
Once the sanlock daemon is running, the next step is to
|
||||
@ -91,7 +91,7 @@ $ su - root
|
||||
unique value for the host.
|
||||
</p>
|
||||
|
||||
<h2><a name="sanlockstorage">libvirt sanlock storage configuration</a></h2>
|
||||
<h2><a id="sanlockstorage">libvirt sanlock storage configuration</a></h2>
|
||||
|
||||
<p>
|
||||
The sanlock plugin needs to create leases in a directory
|
||||
@ -152,7 +152,7 @@ augtool -s set /files/etc/libvirt/qemu-sanlock.conf/group sanlock
|
||||
it should be sufficient to run the cleanup once a week.
|
||||
</p>
|
||||
|
||||
<h2><a name="qemuconfig">QEMU/KVM driver configuration</a></h2>
|
||||
<h2><a id="qemuconfig">QEMU/KVM driver configuration</a></h2>
|
||||
|
||||
<p>
|
||||
The QEMU/KVM driver is fully integrated with the lock
|
||||
@ -219,7 +219,7 @@ __LIBVIRT__DISKS__
|
||||
</pool>
|
||||
</pre>
|
||||
|
||||
<h2><a name="domainconfig">Domain configuration</a></h2>
|
||||
<h2><a id="domainconfig">Domain configuration</a></h2>
|
||||
|
||||
<p>
|
||||
In case sanlock loses access to disk locks for some reason, it will
|
||||
|
@ -15,7 +15,7 @@
|
||||
aware filesystem.
|
||||
</p>
|
||||
|
||||
<h2><a name="plugins">Lock manager plugins</a></h2>
|
||||
<h2><a id="plugins">Lock manager plugins</a></h2>
|
||||
|
||||
<p>
|
||||
The lock manager framework has a pluggable architecture,
|
||||
|
@ -12,7 +12,7 @@
|
||||
<ul id="toc"/>
|
||||
|
||||
<h2>
|
||||
<a name="log_library">Logging in the library</a>
|
||||
<a id="log_library">Logging in the library</a>
|
||||
</h2>
|
||||
<p>The logging functionalities in libvirt are based on 3 key concepts,
|
||||
similar to the one present in other generic logging facilities like
|
||||
@ -40,7 +40,7 @@
|
||||
</ul>
|
||||
|
||||
<h2>
|
||||
<a name="log_config">Configuring logging in the library</a>
|
||||
<a id="log_config">Configuring logging in the library</a>
|
||||
</h2>
|
||||
<p>The library configuration of logging is through 3 environment variables
|
||||
allowing to control the logging behaviour:</p>
|
||||
@ -61,7 +61,7 @@
|
||||
have an error in a filter or output string, some of the settings may be
|
||||
applied up to the point at which libvirt encountered the error.</p>
|
||||
<h2>
|
||||
<a name="log_daemon">Logging in the daemon</a>
|
||||
<a id="log_daemon">Logging in the daemon</a>
|
||||
</h2>
|
||||
<p>Similarly the daemon logging behaviour can be tuned using 3 config
|
||||
variables, stored in the configuration file:</p>
|
||||
@ -96,7 +96,7 @@
|
||||
for debugging purposes by sending the daemon a USR2 signal:</p>
|
||||
<pre>killall -USR2 libvirtd</pre>
|
||||
<h2>
|
||||
<a name="log_syntax">Syntax for filters and output values</a>
|
||||
<a id="log_syntax">Syntax for filters and output values</a>
|
||||
</h2>
|
||||
<p>The syntax for filters and outputs is the same for both types of
|
||||
variables.</p>
|
||||
@ -149,7 +149,7 @@ x:+name (log message + stack trace)</pre>
|
||||
but also log all debug and information included in the
|
||||
file <code>/tmp/libvirt.log</code></p>
|
||||
|
||||
<h2><a name="journald">Systemd journal fields</a></h2>
|
||||
<h2><a id="journald">Systemd journal fields</a></h2>
|
||||
|
||||
<p>
|
||||
When logging to the systemd journal, the following fields
|
||||
@ -176,7 +176,7 @@ x:+name (log message + stack trace)</pre>
|
||||
<dd>The libvirt error code (values from virErrorCode enum), if LIBVIRT_SOURCE="error"</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="journaldids">Well known message ID values</a></h3>
|
||||
<h3><a id="journaldids">Well known message ID values</a></h3>
|
||||
|
||||
<p>
|
||||
Certain areas of the code will emit log records tagged with well known
|
||||
@ -221,7 +221,7 @@ $ journalctl MESSAGE_ID=8ae2f3fb-2dbe-498e-8fbd-012d40afa361 --output=json
|
||||
</pre>
|
||||
|
||||
<h2>
|
||||
<a name="log_examples">Examples</a>
|
||||
<a id="log_examples">Examples</a>
|
||||
</h2>
|
||||
<p>For example setting up the following:</p>
|
||||
<pre>export LIBVIRT_DEBUG=1
|
||||
|
@ -13,7 +13,7 @@
|
||||
libvirt implements several options for migration.
|
||||
</p>
|
||||
|
||||
<h2><a name="transport">Network data transports</a></h2>
|
||||
<h2><a id="transport">Network data transports</a></h2>
|
||||
|
||||
<p>
|
||||
There are two options for the data transport used during migration, either
|
||||
@ -21,7 +21,7 @@
|
||||
over a libvirtd connection.
|
||||
</p>
|
||||
|
||||
<h3><a name="transportnative">Hypervisor native transport</a></h3>
|
||||
<h3><a id="transportnative">Hypervisor native transport</a></h3>
|
||||
<p>
|
||||
<em>Native</em> data transports may or may not support encryption, depending
|
||||
on the hypervisor in question, but will typically have the lowest computational costs
|
||||
@ -35,7 +35,7 @@
|
||||
<img class="diagram" src="migration-native.png" alt="Migration native path"/>
|
||||
</p>
|
||||
|
||||
<h3><a name="transporttunnel">libvirt tunnelled transport</a></h3>
|
||||
<h3><a id="transporttunnel">libvirt tunnelled transport</a></h3>
|
||||
<p>
|
||||
<em>Tunnelled</em> data transports will always be capable of strong encryption
|
||||
since they are able to leverage the capabilities built in to the libvirt RPC protocol.
|
||||
@ -53,7 +53,7 @@
|
||||
<img class="diagram" src="migration-tunnel.png" alt="Migration tunnel path"/>
|
||||
</p>
|
||||
|
||||
<h2><a name="flow">Communication control paths/flows</a></h2>
|
||||
<h2><a id="flow">Communication control paths/flows</a></h2>
|
||||
|
||||
<p>
|
||||
Migration of virtual machines requires close co-ordination of the two
|
||||
@ -61,7 +61,7 @@
|
||||
which may be on the source, the destination, or a third host.
|
||||
</p>
|
||||
|
||||
<h3><a name="flowmanageddirect">Managed direct migration</a></h3>
|
||||
<h3><a id="flowmanageddirect">Managed direct migration</a></h3>
|
||||
|
||||
<p>
|
||||
With <em>managed direct</em> migration, the libvirt client process
|
||||
@ -81,7 +81,7 @@
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a name="flowpeer2peer">Managed peer to peer migration</a></h3>
|
||||
<h3><a id="flowpeer2peer">Managed peer to peer migration</a></h3>
|
||||
|
||||
<p>
|
||||
With <em>peer to peer</em> migration, the libvirt client process only
|
||||
@ -103,7 +103,7 @@
|
||||
</p>
|
||||
|
||||
|
||||
<h3><a name="flowunmanageddirect">Unmanaged direct migration</a></h3>
|
||||
<h3><a id="flowunmanageddirect">Unmanaged direct migration</a></h3>
|
||||
|
||||
<p>
|
||||
With <em>unmanaged direct</em> migration, neither the libvirt client
|
||||
@ -119,7 +119,7 @@
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a name="security">Data security</a></h2>
|
||||
<h2><a id="security">Data security</a></h2>
|
||||
|
||||
<p>
|
||||
Since the migration data stream includes a complete copy of the guest
|
||||
@ -138,7 +138,7 @@
|
||||
facility should be used.
|
||||
</p>
|
||||
|
||||
<h2><a name="offline">Offline migration</a></h2>
|
||||
<h2><a id="offline">Offline migration</a></h2>
|
||||
|
||||
<p>
|
||||
Offline migration transfers inactive the definition of a domain
|
||||
@ -153,7 +153,7 @@
|
||||
offline migration.
|
||||
</p>
|
||||
|
||||
<h2><a name="uris">Migration URIs</a></h2>
|
||||
<h2><a id="uris">Migration URIs</a></h2>
|
||||
|
||||
<p>
|
||||
Initiating a guest migration requires the client application to
|
||||
@ -203,7 +203,7 @@
|
||||
to comply with local firewall policies.</li>
|
||||
</ol>
|
||||
|
||||
<h2><a name="config">Configuration file handling</a></h2>
|
||||
<h2><a id="config">Configuration file handling</a></h2>
|
||||
|
||||
<p>
|
||||
There are two types of virtual machine known to libvirt. A <em>transient</em>
|
||||
@ -446,10 +446,10 @@
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2><a name="scenarios">Migration scenarios</a></h2>
|
||||
<h2><a id="scenarios">Migration scenarios</a></h2>
|
||||
|
||||
|
||||
<h3><a name="scenarionativedirect">Native migration, client to two libvirtd servers</a></h3>
|
||||
<h3><a id="scenarionativedirect">Native migration, client to two libvirtd servers</a></h3>
|
||||
|
||||
<p>
|
||||
At an API level this requires use of virDomainMigrate, without the
|
||||
@ -479,7 +479,7 @@ virsh migrate web1 xen+tcp://desthost/system xenmigr:10.0.0.1/
|
||||
Supported by Xen, QEMU, VMware and VirtualBox drivers
|
||||
</p>
|
||||
|
||||
<h3><a name="scenarionativepeer2peer">Native migration, client to and peer2peer between, two libvirtd servers</a></h3>
|
||||
<h3><a id="scenarionativepeer2peer">Native migration, client to and peer2peer between, two libvirtd servers</a></h3>
|
||||
|
||||
<p>
|
||||
virDomainMigrate, with the VIR_MIGRATE_PEER2PEER flag set,
|
||||
@ -503,7 +503,7 @@ virsh migrate web1 xen+tcp://desthost/system xenmigr:10.0.0.1/
|
||||
Supported by QEMU driver
|
||||
</p>
|
||||
|
||||
<h3><a name="scenariotunnelpeer2peer1">Tunnelled migration, client and peer2peer between two libvirtd servers</a></h3>
|
||||
<h3><a id="scenariotunnelpeer2peer1">Tunnelled migration, client and peer2peer between two libvirtd servers</a></h3>
|
||||
|
||||
<p>
|
||||
virDomainMigrate, with the VIR_MIGRATE_PEER2PEER & VIR_MIGRATE_TUNNELLED
|
||||
@ -526,7 +526,7 @@ virsh migrate web1 xen+tcp://desthost/system xenmigr:10.0.0.1/
|
||||
Supported by QEMU driver
|
||||
</p>
|
||||
|
||||
<h3><a name="nativedirectunmanaged">Native migration, client to one libvirtd server</a></h3>
|
||||
<h3><a id="nativedirectunmanaged">Native migration, client to one libvirtd server</a></h3>
|
||||
|
||||
<p>
|
||||
virDomainMigrateToURI, without the VIR_MIGRATE_PEER2PEER flag set,
|
||||
@ -550,7 +550,7 @@ virsh migrate --direct web1 xenmigr://desthost/
|
||||
Supported by Xen driver
|
||||
</p>
|
||||
|
||||
<h3><a name="nativepeer2peer">Native migration, peer2peer between two libvirtd servers</a></h3>
|
||||
<h3><a id="nativepeer2peer">Native migration, peer2peer between two libvirtd servers</a></h3>
|
||||
|
||||
<p>
|
||||
virDomainMigrateToURI, with the VIR_MIGRATE_PEER2PEER flag set,
|
||||
@ -587,7 +587,7 @@ virsh migrate --p2p web1 qemu+ssh://desthost/system qemu+ssh://10.0.0.1/system
|
||||
Supported by the QEMU driver
|
||||
</p>
|
||||
|
||||
<h3><a name="scenariotunnelpeer2peer2">Tunnelled migration, peer2peer between two libvirtd servers</a></h3>
|
||||
<h3><a id="scenariotunnelpeer2peer2">Tunnelled migration, peer2peer between two libvirtd servers</a></h3>
|
||||
|
||||
<p>
|
||||
virDomainMigrateToURI, with the VIR_MIGRATE_PEER2PEER & VIR_MIGRATE_TUNNELLED
|
||||
|
@ -25,7 +25,7 @@
|
||||
users. This is where NSS module comes handy.
|
||||
</p>
|
||||
|
||||
<h2><a name="Installation">Installation</a></h2>
|
||||
<h2><a id="Installation">Installation</a></h2>
|
||||
|
||||
<p>
|
||||
Installing the module is really easy:
|
||||
@ -35,7 +35,7 @@
|
||||
# yum install libvirt-nss
|
||||
</pre>
|
||||
|
||||
<h2><a name="Configuration">Configuration</a></h2>
|
||||
<h2><a id="Configuration">Configuration</a></h2>
|
||||
|
||||
<p>
|
||||
Enabling the module is really easy. Just add <b>libvirt</b> into
|
||||
@ -62,7 +62,7 @@ hosts: files libvirt dns
|
||||
lookup given host name.
|
||||
</p>
|
||||
|
||||
<h2><a name="Sources">Sources of information</a></h2>
|
||||
<h2><a id="Sources">Sources of information</a></h2>
|
||||
|
||||
<p>
|
||||
As of <code>v3.0.0</code> release, libvirt offers two NSS modules
|
||||
@ -104,7 +104,7 @@ hosts: files libvirt libvirt_guest dns
|
||||
resolved).
|
||||
</p>
|
||||
|
||||
<h2><a name="Internals">How does it work?</a></h2>
|
||||
<h2><a id="Internals">How does it work?</a></h2>
|
||||
|
||||
<p>
|
||||
Whenever an Unix process wants to do a host name translation
|
||||
@ -139,7 +139,7 @@ hosts: files libvirt libvirt_guest dns
|
||||
should carefully chose the lookup order.
|
||||
</p>
|
||||
|
||||
<h2><a name="Limitations">Limitations</a></h2>
|
||||
<h2><a id="Limitations">Limitations</a></h2>
|
||||
|
||||
<ol>
|
||||
<li>The <code>libvirt</code> NSS module matches only hostnames provided by guest.
|
||||
|
@ -27,30 +27,30 @@
|
||||
<xsl:for-each select="/html:html/html:body/html:h2[count(html:a) = 1]">
|
||||
<xsl:variable name="thish2" select="."/>
|
||||
<li>
|
||||
<a href="#{html:a/@name}"><xsl:value-of select="html:a/text()"/></a>
|
||||
<a href="#{html:a/@id}"><xsl:value-of select="html:a/text()"/></a>
|
||||
<xsl:if test="count(./following-sibling::html:h3[preceding-sibling::html:h2[1] = $thish2 and count(html:a) = 1]) > 0">
|
||||
<ul>
|
||||
<xsl:for-each select="./following-sibling::html:h3[preceding-sibling::html:h2[1] = $thish2 and count(html:a) = 1]">
|
||||
<xsl:variable name="thish3" select="."/>
|
||||
<li>
|
||||
<a href="#{html:a/@name}"><xsl:value-of select="html:a/text()"/></a>
|
||||
<a href="#{html:a/@id}"><xsl:value-of select="html:a/text()"/></a>
|
||||
<xsl:if test="count(./following-sibling::html:h4[preceding-sibling::html:h3[1] = $thish3 and count(html:a) = 1]) > 0">
|
||||
<ul>
|
||||
<xsl:for-each select="./following-sibling::html:h4[preceding-sibling::html:h3[1] = $thish3 and count(html:a) = 1]">
|
||||
<xsl:variable name="thish4" select="."/>
|
||||
<li>
|
||||
<a href="#{html:a/@name}"><xsl:value-of select="html:a/text()"/></a>
|
||||
<a href="#{html:a/@id}"><xsl:value-of select="html:a/text()"/></a>
|
||||
<xsl:if test="count(./following-sibling::html:h5[preceding-sibling::html:h4[1] = $thish4 and count(html:a) = 1]) > 0">
|
||||
<ul>
|
||||
<xsl:for-each select="./following-sibling::html:h5[preceding-sibling::html:h4[1] = $thish4 and count(html:a) = 1]">
|
||||
<xsl:variable name="thish5" select="."/>
|
||||
<li>
|
||||
<a href="#{html:a/@name}"><xsl:value-of select="html:a/text()"/></a>
|
||||
<a href="#{html:a/@id}"><xsl:value-of select="html:a/text()"/></a>
|
||||
<xsl:if test="count(./following-sibling::html:h6[preceding-sibling::html:h5[1] = $thish5 and count(html:a) = 1]) > 0">
|
||||
<ul>
|
||||
<xsl:for-each select="./following-sibling::html:h6[preceding-sibling::html:h5[1] = $thish5 and count(html:a) = 1]">
|
||||
<li>
|
||||
<a href="#{html:a/@name}"><xsl:value-of select="html:a/text()"/></a>
|
||||
<a href="#{html:a/@id}"><xsl:value-of select="html:a/text()"/></a>
|
||||
</li>
|
||||
</xsl:for-each>
|
||||
</ul>
|
||||
@ -159,8 +159,8 @@
|
||||
<xsl:template match="html:h2 | html:h3 | html:h4 | html:h5 | html:h6" mode="content">
|
||||
<xsl:element name="{name()}">
|
||||
<xsl:apply-templates mode="copy" />
|
||||
<xsl:if test="./html:a/@name">
|
||||
<a class="headerlink" href="#{html:a/@name}" title="Permalink to this headline">¶</a>
|
||||
<xsl:if test="./html:a/@id">
|
||||
<a class="headerlink" href="#{html:a/@id}" title="Permalink to this headline">¶</a>
|
||||
</xsl:if>
|
||||
</xsl:element>
|
||||
</xsl:template>
|
||||
|
@ -10,7 +10,7 @@ machines through authenticated and encrypted connections.
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2>
|
||||
<a name="Remote_basic_usage">Basic usage</a>
|
||||
<a id="Remote_basic_usage">Basic usage</a>
|
||||
</h2>
|
||||
<p>
|
||||
On the remote machine, <code>libvirtd</code> should be running in general.
|
||||
@ -50,7 +50,7 @@ relating to failures in the remote transport itself. </li>
|
||||
much slower than, say, direct hypervisor calls. </li>
|
||||
</ul>
|
||||
<h2>
|
||||
<a name="Remote_transports">Transports</a>
|
||||
<a id="Remote_transports">Transports</a>
|
||||
</h2>
|
||||
<p>
|
||||
Remote libvirt supports a range of transports:
|
||||
@ -111,7 +111,7 @@ netcat is required on the remote side.</dd>
|
||||
The default transport, if no other is specified, is <code>tls</code>.
|
||||
</p>
|
||||
<h2>
|
||||
<a name="Remote_URI_reference">Remote URIs</a>
|
||||
<a id="Remote_URI_reference">Remote URIs</a>
|
||||
</h2>
|
||||
<p>
|
||||
See also: <a href="uri.html">documentation on ordinary ("local") URIs</a>.
|
||||
@ -158,7 +158,7 @@ Connect to a remote host using a ssh connection with the libssh driver
|
||||
and use a different known_hosts file.</li>
|
||||
</ul>
|
||||
<h3>
|
||||
<a name="Remote_URI_parameters">Extra parameters</a>
|
||||
<a id="Remote_URI_parameters">Extra parameters</a>
|
||||
</h3>
|
||||
<p>
|
||||
Extra parameters can be added to remote URIs as part
|
||||
@ -364,10 +364,10 @@ Note that parameter values must be
|
||||
</tr>
|
||||
</table>
|
||||
<h2>
|
||||
<a name="Remote_certificates">Generating TLS certificates</a>
|
||||
<a id="Remote_certificates">Generating TLS certificates</a>
|
||||
</h2>
|
||||
<h3>
|
||||
<a name="Remote_PKI">Public Key Infrastructure set up</a>
|
||||
<a id="Remote_PKI">Public Key Infrastructure set up</a>
|
||||
</h3>
|
||||
<p>
|
||||
If you are unsure how to create TLS certificates, skip to the
|
||||
@ -472,7 +472,7 @@ next section.
|
||||
<li> For the root user, the global default locations will always be used.</li>
|
||||
</ul>
|
||||
<h3>
|
||||
<a name="Remote_TLS_background">Background to TLS certificates</a>
|
||||
<a id="Remote_TLS_background">Background to TLS certificates</a>
|
||||
</h3>
|
||||
<p>
|
||||
Libvirt supports TLS certificates for verifying the identity
|
||||
@ -507,7 +507,7 @@ address. You may want to change this to make it less (or more)
|
||||
permissive, depending on your needs.
|
||||
</p>
|
||||
<h3>
|
||||
<a name="Remote_TLS_CA">Setting up a Certificate Authority (CA)</a>
|
||||
<a id="Remote_TLS_CA">Setting up a Certificate Authority (CA)</a>
|
||||
</h3>
|
||||
<p>
|
||||
You will need the <a href="http://www.gnu.org/software/gnutls/manual/html_node/Invoking-certtool.html">GnuTLS
|
||||
@ -578,7 +578,7 @@ key carefully as you will need it when you come to issue certificates
|
||||
for your clients and servers.
|
||||
</p>
|
||||
<h3>
|
||||
<a name="Remote_TLS_server_certificates">Issuing server certificates</a>
|
||||
<a id="Remote_TLS_server_certificates">Issuing server certificates</a>
|
||||
</h3>
|
||||
<p>
|
||||
For each server (libvirtd) you need to issue a certificate
|
||||
@ -661,7 +661,7 @@ which can be installed on the server as
|
||||
</li>
|
||||
</ul>
|
||||
<h3>
|
||||
<a name="Remote_TLS_client_certificates">Issuing client certificates</a>
|
||||
<a id="Remote_TLS_client_certificates">Issuing client certificates</a>
|
||||
</h3>
|
||||
<p>
|
||||
For each client (ie. any program linked with libvirt, such as
|
||||
@ -714,7 +714,7 @@ cp clientcert.pem /etc/pki/libvirt/clientcert.pem
|
||||
</li>
|
||||
</ol>
|
||||
<h3>
|
||||
<a name="Remote_TLS_troubleshooting">Troubleshooting TLS certificate problems</a>
|
||||
<a id="Remote_TLS_troubleshooting">Troubleshooting TLS certificate problems</a>
|
||||
</h3>
|
||||
<dl>
|
||||
<dt> failed to verify client's certificate </dt>
|
||||
@ -732,7 +732,7 @@ to analyze the setup on the client or server machines, preferably as root.
|
||||
It will try to point out the possible problems and provide solutions to
|
||||
fix the set up up to a point where you have secure remote access.</p>
|
||||
<h2>
|
||||
<a name="Remote_libvirtd_configuration">libvirtd configuration file</a>
|
||||
<a id="Remote_libvirtd_configuration">libvirtd configuration file</a>
|
||||
</h2>
|
||||
<p>
|
||||
Libvirtd (the remote daemon) is configured from a file called
|
||||
@ -900,7 +900,7 @@ Blank lines and comments beginning with <code>#</code> are ignored.
|
||||
</tr>
|
||||
</table>
|
||||
<h2>
|
||||
<a name="Remote_IPv6">IPv6 support</a>
|
||||
<a id="Remote_IPv6">IPv6 support</a>
|
||||
</h2>
|
||||
<p>
|
||||
The libvirtd service and libvirt remote client driver both use the
|
||||
@ -913,7 +913,7 @@ connection will be made, otherwise IPv4 will be used. In summary it
|
||||
should just 'do the right thing(tm)'.
|
||||
</p>
|
||||
<h2>
|
||||
<a name="Remote_limitations">Limitations</a>
|
||||
<a id="Remote_limitations">Limitations</a>
|
||||
</h2>
|
||||
<ul>
|
||||
<li> Fine-grained authentication: libvirt in general,
|
||||
|
@ -14,9 +14,9 @@
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a name="diskimage">Disk image handling</a></h2>
|
||||
<h2><a id="diskimage">Disk image handling</a></h2>
|
||||
|
||||
<h3><a name="diskimageformat">Disk image format probing</a></h3>
|
||||
<h3><a id="diskimageformat">Disk image format probing</a></h3>
|
||||
|
||||
<p>
|
||||
Historically there have been multiple flaws in QEMU and most
|
||||
@ -40,7 +40,7 @@
|
||||
are accessible to / originate from an untrusted source.
|
||||
</p>
|
||||
|
||||
<h3><a name="diskimagebacking">Disk image backing files</a></h3>
|
||||
<h3><a id="diskimagebacking">Disk image backing files</a></h3>
|
||||
|
||||
<p>
|
||||
If a management application allows users to upload pre-created
|
||||
@ -59,7 +59,7 @@
|
||||
file set. If a backing file is seen, reject the image.
|
||||
</p>
|
||||
|
||||
<h3><a name="diskimagesize">Disk image size validation</a></h3>
|
||||
<h3><a id="diskimagesize">Disk image size validation</a></h3>
|
||||
|
||||
<p>
|
||||
If an application allows users to upload pre-created disk
|
||||
@ -78,7 +78,7 @@
|
||||
limit.
|
||||
</p>
|
||||
|
||||
<h3><a name="diskimageaccess">Disk image data access</a></h3>
|
||||
<h3><a id="diskimageaccess">Disk image data access</a></h3>
|
||||
|
||||
<p>
|
||||
If an untrusted disk image is ever mounted on the host OS by
|
||||
@ -104,7 +104,7 @@
|
||||
tools and APIs for accessing disks
|
||||
</p>
|
||||
|
||||
<h2><a name="migration">Guest migration network</a></h2>
|
||||
<h2><a id="migration">Guest migration network</a></h2>
|
||||
|
||||
<p>
|
||||
Most hypervisors with support for guest migration between hosts
|
||||
@ -145,7 +145,7 @@
|
||||
RPC protocol connections.</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="storage">Storage encryption</a></h2>
|
||||
<h2><a id="storage">Storage encryption</a></h2>
|
||||
|
||||
<p>
|
||||
Virtual disk images will typically contain confidential data
|
||||
|
@ -15,7 +15,7 @@
|
||||
potential security issues.
|
||||
</p>
|
||||
|
||||
<h2><a name="reporting">Reporting security issues</a></h2>
|
||||
<h2><a id="reporting">Reporting security issues</a></h2>
|
||||
|
||||
<p>
|
||||
In the event that a bug in libvirt is found which is
|
||||
@ -37,7 +37,7 @@
|
||||
moderator and the reporter copied on any replies.
|
||||
</p>
|
||||
|
||||
<h2><a name="seclist">Security team</a></h2>
|
||||
<h2><a id="seclist">Security team</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt security team is made up of a subset of the libvirt
|
||||
@ -61,7 +61,7 @@
|
||||
described below.
|
||||
</p>
|
||||
|
||||
<h2><a name="embargo">Publication embargo policy</a></h2>
|
||||
<h2><a id="embargo">Publication embargo policy</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt security team operates a policy of
|
||||
@ -84,7 +84,7 @@
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a name="cve">CVE allocation</a></h2>
|
||||
<h2><a id="cve">CVE allocation</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt security team will associate each security issue with
|
||||
@ -92,7 +92,7 @@
|
||||
the vendor security engineers on the security team.
|
||||
</p>
|
||||
|
||||
<h2><a name="branches">Branch fixing policy</a></h2>
|
||||
<h2><a id="branches">Branch fixing policy</a></h2>
|
||||
|
||||
<p>
|
||||
The libvirt community maintains one or more stable release branches
|
||||
@ -103,7 +103,7 @@
|
||||
other release branches where applicable.
|
||||
</p>
|
||||
|
||||
<h2><a name="notification">Notification of issues</a></h2>
|
||||
<h2><a id="notification">Notification of issues</a></h2>
|
||||
|
||||
<p>
|
||||
When an embargo expires, security issues will be announced on both
|
||||
|
@ -85,7 +85,7 @@
|
||||
</p>
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="StorageBackendDir">Directory pool</a></h2>
|
||||
<h2><a id="StorageBackendDir">Directory pool</a></h2>
|
||||
<p>
|
||||
A pool with a type of <code>dir</code> provides the means to manage
|
||||
files within a directory. The files can be fully allocated raw files,
|
||||
@ -138,7 +138,7 @@
|
||||
|
||||
</p>
|
||||
|
||||
<h2><a name="StorageBackendFS">Filesystem pool</a></h2>
|
||||
<h2><a id="StorageBackendFS">Filesystem pool</a></h2>
|
||||
<p>
|
||||
This is a variant of the directory pool. Instead of creating a
|
||||
directory on an existing mounted filesystem though, it expects
|
||||
@ -212,7 +212,7 @@
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a name="StorageBackendNetFS">Network filesystem pool</a></h2>
|
||||
<h2><a id="StorageBackendNetFS">Network filesystem pool</a></h2>
|
||||
<p>
|
||||
This is a variant of the filesystem pool. Instead of requiring
|
||||
a local block device as the source, it requires the name of a
|
||||
@ -266,7 +266,7 @@
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a name="StorageBackendLogical">Logical volume pool</a></h2>
|
||||
<h2><a id="StorageBackendLogical">Logical volume pool</a></h2>
|
||||
<p>
|
||||
This provides a pool based on an LVM volume group. For a
|
||||
pre-defined LVM volume group, simply providing the group
|
||||
@ -303,7 +303,7 @@
|
||||
</p>
|
||||
|
||||
|
||||
<h2><a name="StorageBackendDisk">Disk pool</a></h2>
|
||||
<h2><a id="StorageBackendDisk">Disk pool</a></h2>
|
||||
<p>
|
||||
This provides a pool based on a physical disk. Volumes are created
|
||||
by adding partitions to the disk. Disk pools have constraints
|
||||
@ -394,7 +394,7 @@
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="StorageBackendISCSI">iSCSI pool</a></h2>
|
||||
<h2><a id="StorageBackendISCSI">iSCSI pool</a></h2>
|
||||
<p>
|
||||
This provides a pool based on an iSCSI target. Volumes must be
|
||||
pre-allocated on the iSCSI server, and cannot be created via
|
||||
@ -433,7 +433,7 @@
|
||||
The iSCSI volume pool does not use the volume format type element.
|
||||
</p>
|
||||
|
||||
<h2><a name="StorageBackendSCSI">SCSI pool</a></h2>
|
||||
<h2><a id="StorageBackendSCSI">SCSI pool</a></h2>
|
||||
<p>
|
||||
This provides a pool based on a SCSI HBA. Volumes are preexisting SCSI
|
||||
LUNs, and cannot be created via the libvirt APIs. Since /dev/XXX names
|
||||
@ -465,7 +465,7 @@
|
||||
The SCSI volume pool does not use the volume format type element.
|
||||
</p>
|
||||
|
||||
<h2><a name="StorageBackendMultipath">Multipath pool</a></h2>
|
||||
<h2><a id="StorageBackendMultipath">Multipath pool</a></h2>
|
||||
<p>
|
||||
This provides a pool that contains all the multipath devices on the
|
||||
host. Therefore, only one Multipath pool may be configured per host.
|
||||
@ -498,7 +498,7 @@
|
||||
The Multipath volume pool does not use the volume format type element.
|
||||
</p>
|
||||
|
||||
<h2><a name="StorageBackendRBD">RBD pool</a></h2>
|
||||
<h2><a id="StorageBackendRBD">RBD pool</a></h2>
|
||||
<p>
|
||||
This storage driver provides a pool which contains all RBD
|
||||
images in a RADOS pool. RBD (RADOS Block Device) is part
|
||||
@ -571,7 +571,7 @@
|
||||
The RBD pool does not use the volume format type element.
|
||||
</p>
|
||||
|
||||
<h2><a name="StorageBackendSheepdog">Sheepdog pool</a></h2>
|
||||
<h2><a id="StorageBackendSheepdog">Sheepdog pool</a></h2>
|
||||
<p>
|
||||
This provides a pool based on a Sheepdog Cluster.
|
||||
Sheepdog is a distributed storage system for QEMU/KVM.
|
||||
@ -630,7 +630,7 @@
|
||||
The Sheepdog pool does not use the volume format type element.
|
||||
</p>
|
||||
|
||||
<h2><a name="StorageBackendGluster">Gluster pool</a></h2>
|
||||
<h2><a id="StorageBackendGluster">Gluster pool</a></h2>
|
||||
<p>
|
||||
This provides a pool based on native Gluster access. Gluster is
|
||||
a distributed file system that can be exposed to the user via
|
||||
@ -716,7 +716,7 @@
|
||||
pool type.
|
||||
</p>
|
||||
|
||||
<h2><a name="StorageBackendZFS">ZFS pool</a></h2>
|
||||
<h2><a id="StorageBackendZFS">ZFS pool</a></h2>
|
||||
<p>
|
||||
This provides a pool based on the ZFS filesystem. Initially it was developed
|
||||
for FreeBSD, and <span class="since">since 1.3.2</span> experimental support
|
||||
@ -754,7 +754,7 @@
|
||||
<p>
|
||||
The ZFS volume pool does not use the volume format type element.
|
||||
</p>
|
||||
<h2><a name="StorageBackendVstorage">Vstorage pool</a></h2>
|
||||
<h2><a id="StorageBackendVstorage">Vstorage pool</a></h2>
|
||||
<p>
|
||||
This provides a pool based on Virtuozzo storage. Virtuozzo Storage is
|
||||
a highly available distributed software-defined storage with built-in
|
||||
|
@ -16,7 +16,7 @@ machine over the network.
|
||||
To this end, libvirt uses URIs as used on the Web and as defined in <a href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</a>. This page
|
||||
documents libvirt URIs.
|
||||
</p>
|
||||
<h2><a name="URI_libvirt">Specifying URIs to libvirt</a></h2>
|
||||
<h2><a id="URI_libvirt">Specifying URIs to libvirt</a></h2>
|
||||
|
||||
<p>
|
||||
The URI is passed as the <code>name</code> parameter to
|
||||
@ -33,7 +33,7 @@ documents libvirt URIs.
|
||||
virConnectPtr conn = virConnectOpenReadOnly (<b>"test:///default"</b>);
|
||||
</pre>
|
||||
<h2>
|
||||
<a name="URI_config">Configuring URI aliases</a>
|
||||
<a id="URI_config">Configuring URI aliases</a>
|
||||
</h2>
|
||||
|
||||
<p>
|
||||
@ -61,7 +61,7 @@ uri_aliases = [
|
||||
set, no alias lookup will be attempted.
|
||||
</p>
|
||||
|
||||
<h2><a name="URI_default">Default URI choice</a></h2>
|
||||
<h2><a id="URI_default">Default URI choice</a></h2>
|
||||
|
||||
<p>
|
||||
If the URI passed to <code>virConnectOpen*</code> is NULL, then libvirt will use the following
|
||||
@ -75,7 +75,7 @@ logic to determine what URI to use.
|
||||
</ol>
|
||||
|
||||
<h2>
|
||||
<a name="URI_virsh">Specifying URIs to virsh, virt-manager and virt-install</a>
|
||||
<a id="URI_virsh">Specifying URIs to virsh, virt-manager and virt-install</a>
|
||||
</h2>
|
||||
<p>
|
||||
In virsh use the <code>-c</code> or <code>--connect</code> option:
|
||||
@ -107,7 +107,7 @@ In virt-install use the <code>--connect=</code><i>URI</i> option:
|
||||
virt-install <b>--connect=test:///default</b> <i>[other options]</i>
|
||||
</pre>
|
||||
<h2>
|
||||
<a name="URI_xen">xen:/// URI</a>
|
||||
<a id="URI_xen">xen:/// URI</a>
|
||||
</h2>
|
||||
<p>
|
||||
<i>This section describes a feature which is new in libvirt >
|
||||
@ -118,7 +118,7 @@ To access a Xen hypervisor running on the local machine
|
||||
use the URI <code>xen:///</code>.
|
||||
</p>
|
||||
<h2>
|
||||
<a name="URI_qemu">qemu:///... QEMU and KVM URIs</a>
|
||||
<a id="URI_qemu">qemu:///... QEMU and KVM URIs</a>
|
||||
</h2>
|
||||
<p>
|
||||
To use QEMU support in libvirt you must be running the
|
||||
@ -150,7 +150,7 @@ KVM guests in the <a href="format.html#KVM1">guest XML as described
|
||||
here</a>.
|
||||
</p>
|
||||
<h2>
|
||||
<a name="URI_remote">Remote URIs</a>
|
||||
<a id="URI_remote">Remote URIs</a>
|
||||
</h2>
|
||||
<p>
|
||||
Remote URIs are formed by taking ordinary local URIs and adding a
|
||||
@ -213,7 +213,7 @@ remote URI reference</a> and <a href="remote.html">full documentation
|
||||
for libvirt remote support</a>.
|
||||
</p>
|
||||
<h2>
|
||||
<a name="URI_test">test:///... Test URIs</a>
|
||||
<a id="URI_test">test:///... Test URIs</a>
|
||||
</h2>
|
||||
<p>
|
||||
The test driver is a dummy hypervisor for test purposes.
|
||||
@ -227,10 +227,10 @@ a set of host definitions held in the named file.
|
||||
</li>
|
||||
</ul>
|
||||
<h2>
|
||||
<a name="URI_legacy">Other & legacy URI formats</a>
|
||||
<a id="URI_legacy">Other & legacy URI formats</a>
|
||||
</h2>
|
||||
<h3>
|
||||
<a name="URI_NULL">NULL and empty string URIs</a>
|
||||
<a id="URI_NULL">NULL and empty string URIs</a>
|
||||
</h3>
|
||||
<p>
|
||||
Libvirt allows you to pass a <code>NULL</code> pointer to
|
||||
@ -254,7 +254,7 @@ application wishes to connect specifically to a Xen hypervisor, then
|
||||
for future proofing it should choose a full <a href="#URI_xen"><code>xen:///</code> URI</a>.
|
||||
</p>
|
||||
<h3>
|
||||
<a name="URI_file">File paths (xend-unix-server)</a>
|
||||
<a id="URI_file">File paths (xend-unix-server)</a>
|
||||
</h3>
|
||||
<p>
|
||||
If XenD is running and configured in <code>/etc/xen/xend-config.sxp</code>:
|
||||
@ -271,7 +271,7 @@ using a file URI such as:
|
||||
virsh -c ///var/run/xend/xend-socket
|
||||
</pre>
|
||||
<h3>
|
||||
<a name="URI_http">Legacy: <code>http://...</code> (xend-http-server)</a>
|
||||
<a id="URI_http">Legacy: <code>http://...</code> (xend-http-server)</a>
|
||||
</h3>
|
||||
<p>
|
||||
If XenD is running and configured in <code>/etc/xen/xend-config.sxp</code>:
|
||||
@ -307,7 +307,7 @@ Notes:
|
||||
documentation as "unix server" or "http server".</li>
|
||||
</ol>
|
||||
<h3>
|
||||
<a name="URI_legacy_xen">Legacy: <code>"xen"</code></a>
|
||||
<a id="URI_legacy_xen">Legacy: <code>"xen"</code></a>
|
||||
</h3>
|
||||
<p>
|
||||
Another legacy URI is to specify name as the string
|
||||
@ -315,7 +315,7 @@ Another legacy URI is to specify name as the string
|
||||
hypervisor. However you should prefer a full <a href="#URI_xen"><code>xen:///</code> URI</a> in all future code.
|
||||
</p>
|
||||
<h3>
|
||||
<a name="URI_legacy_proxy">Legacy: Xen proxy</a>
|
||||
<a id="URI_legacy_proxy">Legacy: Xen proxy</a>
|
||||
</h3>
|
||||
<p>
|
||||
Libvirt continues to support connections to a separately running Xen
|
||||
|
@ -6,7 +6,7 @@
|
||||
|
||||
<ul id="toc"></ul>
|
||||
|
||||
<h2><a name="description">Description</a></h2>
|
||||
<h2><a id="description">Description</a></h2>
|
||||
|
||||
<p>
|
||||
The new <b>Virsh Command Reference</b>, for documenting the commands
|
||||
@ -24,7 +24,7 @@
|
||||
|
||||
<p> </p>
|
||||
|
||||
<h2><a name="viewing">Viewing Online</a></h2>
|
||||
<h2><a id="viewing">Viewing Online</a></h2>
|
||||
|
||||
<p>
|
||||
The latest version can be viewed directly online:
|
||||
@ -41,7 +41,7 @@
|
||||
|
||||
<p> </p>
|
||||
|
||||
<h2><a name="downloading">Downloading</a></h2>
|
||||
<h2><a id="downloading">Downloading</a></h2>
|
||||
|
||||
<p>
|
||||
The latest version of the Virsh Command Reference can be downloaded:
|
||||
@ -68,7 +68,7 @@
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="git">DocBook source GIT repository</a></h2>
|
||||
<h2><a id="git">DocBook source GIT repository</a></h2>
|
||||
<p>
|
||||
The DocBook source is maintained in a <a
|
||||
href="http://git-scm.com/">git</a> repository available on
|
||||
|
@ -12,7 +12,7 @@
|
||||
as well but we either haven't tested or received reports for them.
|
||||
</p>
|
||||
|
||||
<h2><a name="installer">Installation packages</a></h2>
|
||||
<h2><a id="installer">Installation packages</a></h2>
|
||||
|
||||
<p>
|
||||
Users who need pre-built Windows DLLs of libvirt are advised
|
||||
@ -29,7 +29,7 @@
|
||||
against libvirt.
|
||||
</p>
|
||||
|
||||
<h2><a name="conntypes">Connection types</a></h2>
|
||||
<h2><a id="conntypes">Connection types</a></h2>
|
||||
|
||||
<p>
|
||||
These connection types are known to work:
|
||||
@ -71,7 +71,7 @@
|
||||
be used in security sensitive environments.</b>
|
||||
</p>
|
||||
|
||||
<h2><a name="esx">Connecting to VMware ESX/vSphere</a></h2>
|
||||
<h2><a id="esx">Connecting to VMware ESX/vSphere</a></h2>
|
||||
|
||||
<p>
|
||||
Details on the capabilities, certificates, and connection string
|
||||
@ -81,7 +81,7 @@
|
||||
|
||||
<a href="http://libvirt.org/drvesx.html">http://libvirt.org/drvesx.html</a>
|
||||
|
||||
<h2><a name="tlscerts">TLS Certificates</a></h2>
|
||||
<h2><a id="tlscerts">TLS Certificates</a></h2>
|
||||
|
||||
<p>
|
||||
TLS certificates need to have been created and placed in the correct
|
||||
@ -141,21 +141,21 @@
|
||||
<li>C:\Users\someuser\AppData\Roaming\libvirt\pki\libvirt\private\clientkey.pem</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="feedback">Feedback</a></h2>
|
||||
<h2><a id="feedback">Feedback</a></h2>
|
||||
|
||||
<p>
|
||||
Feedback and suggestions on changes to make and what else to include
|
||||
<a href="contact.html">are desired</a>.
|
||||
</p>
|
||||
|
||||
<h2><a name="compiling">Compiling yourself</a></h2>
|
||||
<h2><a id="compiling">Compiling yourself</a></h2>
|
||||
|
||||
<p>
|
||||
Libvirt can be compiled on Windows using the free
|
||||
<a href="http://www.mingw.org/">MinGW compiler</a>.
|
||||
</p>
|
||||
|
||||
<h3><a name="msys_setup">MSYS Build script</a></h3>
|
||||
<h3><a id="msys_setup">MSYS Build script</a></h3>
|
||||
|
||||
<p>
|
||||
The easiest way is to use the <b>msys_setup</b> script, developed by
|
||||
@ -165,7 +165,7 @@
|
||||
|
||||
<a href="https://github.com/photron/msys_setup">https://github.com/photron/msys_setup</a>
|
||||
|
||||
<h3><a name="cross-compile">Cross compiling</a></h3>
|
||||
<h3><a id="cross-compile">Cross compiling</a></h3>
|
||||
|
||||
<p>
|
||||
You can also cross-compile to a Windows target from a Fedora machine
|
||||
@ -174,7 +174,7 @@
|
||||
(which includes a working libvirt specfile).
|
||||
</p>
|
||||
|
||||
<h3><a name="configure">By hand</a></h3>
|
||||
<h3><a id="configure">By hand</a></h3>
|
||||
|
||||
<p>
|
||||
Use these options when following the instructions on the
|
||||
|
Loading…
Reference in New Issue
Block a user