mirror of https://gitee.com/openkylin/libvirt.git
Cleanup whitespace in docs
This patch is the result of running the following command in the docs directory: sed -i 's/\t/ /g; s/\s*$//' *.html.in * docs/*.html.in:convert tabs into 8 spaces and remove trailing whitespace
This commit is contained in:
Matthew Booth
Daniel Veillard
parent
bb4ec5550b
commit
c6d5ac174e
|
|
@ -84,7 +84,7 @@
|
|||
which is garanteed to be unique for long term usage and across a
|
||||
set of nodes.</li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2><a name="Functions" id="Functions">Functions and naming
|
||||
conventions</a></h2>
|
||||
<p> The naming of the functions present in the library is usually
|
||||
|
|
@ -93,7 +93,7 @@
|
|||
<p> For each first class object you will find apis
|
||||
for the following actions:</p>
|
||||
<ul>
|
||||
<li><b>Lookup</b>:...LookupByName,
|
||||
<li><b>Lookup</b>:...LookupByName,
|
||||
<li><b>Enumeration</b>:virConnectList... and virConnectNumOf...:
|
||||
those are used to enumerate a set of object available to an given
|
||||
hypervisor connection like:
|
||||
|
|
@ -119,7 +119,7 @@
|
|||
<li><b>Destruction</b>: ... </li>
|
||||
</ul>
|
||||
<p> For more in-depth details of the storage related APIs see
|
||||
<a href="storage.html">the storage management page</a>,
|
||||
<a href="storage.html">the storage management page</a>,
|
||||
<h2><a name="Driver" id="Driver">The libvirt drivers</a></h2>
|
||||
<p></p>
|
||||
<p class="image">
|
||||
|
|
|
|||
|
|
@ -145,20 +145,20 @@
|
|||
|
||||
<ol class="ordinarylist">
|
||||
<li>SHOULD log a message with VIR_DEBUG() indicating that it is
|
||||
being called and its parameters;</li>
|
||||
being called and its parameters;</li>
|
||||
<li>MUST call virResetLastError();</li>
|
||||
<li>SHOULD confirm that the connection is valid with
|
||||
VIR_IS_CONNECT(conn);</li>
|
||||
VIR_IS_CONNECT(conn);</li>
|
||||
<li><strong>SECURITY: If the API requires a connection with write
|
||||
privileges, MUST confirm that the connection flags do not
|
||||
indicate that the connection is read-only;</strong></li>
|
||||
privileges, MUST confirm that the connection flags do not
|
||||
indicate that the connection is read-only;</strong></li>
|
||||
<li>SHOULD do basic validation of the parameters that are being
|
||||
passed in;</li>
|
||||
passed in;</li>
|
||||
<li>MUST confirm that the driver for this connection exists and that
|
||||
it implements this function;</li>
|
||||
it implements this function;</li>
|
||||
<li>MUST call the internal API;</li>
|
||||
<li>SHOULD log a message with VIR_DEBUG() indicating that it is
|
||||
returning, its return value, and status.</li>
|
||||
returning, its return value, and status.</li>
|
||||
<li>MUST return status to the caller.</li>
|
||||
</ol>
|
||||
|
||||
|
|
|
|||
|
|
@ -21,42 +21,42 @@
|
|||
<dl>
|
||||
<dt>virsh</dt>
|
||||
<dd>
|
||||
An interactive shell, and batch scriptable tool for performing
|
||||
management tasks on all libvirt managed domains, networks and
|
||||
storage. This is part of the libvirt core distribution.
|
||||
An interactive shell, and batch scriptable tool for performing
|
||||
management tasks on all libvirt managed domains, networks and
|
||||
storage. This is part of the libvirt core distribution.
|
||||
</dd>
|
||||
<dt><a href="http://virt-manager.org/">virt-install</a></dt>
|
||||
<dd>
|
||||
Provides a way to provision new virtual machines from a
|
||||
OS distribution install tree. It supports provisioning from
|
||||
local CD images, and the network over NFS, HTTP and FTP.
|
||||
Provides a way to provision new virtual machines from a
|
||||
OS distribution install tree. It supports provisioning from
|
||||
local CD images, and the network over NFS, HTTP and FTP.
|
||||
</dd>
|
||||
<dt><a href="http://virt-manager.org/">virt-clone</a></dt>
|
||||
<dd>
|
||||
Allows the disk image(s) and configuration for an existing
|
||||
virtual machine to be cloned to form a new virtual machine.
|
||||
It automates copying of data across to new disk images, and
|
||||
updates the UUID, Mac address and name in the configuration
|
||||
Allows the disk image(s) and configuration for an existing
|
||||
virtual machine to be cloned to form a new virtual machine.
|
||||
It automates copying of data across to new disk images, and
|
||||
updates the UUID, Mac address and name in the configuration
|
||||
</dd>
|
||||
<dt><a href="http://virt-manager.org/">virt-image</a></dt>
|
||||
<dd>
|
||||
Provides a way to deploy virtual appliances. It defines a
|
||||
simplified portable XML format describing the pre-requisites
|
||||
of a virtual machine. At time of deployment this is translated
|
||||
into the domain XML format for execution under any libvirt
|
||||
hypervisor meeting the pre-requisites.
|
||||
Provides a way to deploy virtual appliances. It defines a
|
||||
simplified portable XML format describing the pre-requisites
|
||||
of a virtual machine. At time of deployment this is translated
|
||||
into the domain XML format for execution under any libvirt
|
||||
hypervisor meeting the pre-requisites.
|
||||
</dd>
|
||||
<dt><a href="http://et.redhat.com/~rjones/virt-df/">virt-df</a></dt>
|
||||
<dd>
|
||||
Examine the utilization of each filesystem in a virtual machine
|
||||
from the comfort of the host machine. This tool peeks into the
|
||||
guest disks and determines how much space is used. It can cope
|
||||
with common Linux filesystems and LVM volumes.
|
||||
Examine the utilization of each filesystem in a virtual machine
|
||||
from the comfort of the host machine. This tool peeks into the
|
||||
guest disks and determines how much space is used. It can cope
|
||||
with common Linux filesystems and LVM volumes.
|
||||
</dd>
|
||||
<dt><a href="http://et.redhat.com/~rjones/virt-top/">virt-top</a></dt>
|
||||
<dd>
|
||||
Watch the CPU, memory, network and disk utilization of all
|
||||
virtual machines running on a host.
|
||||
Watch the CPU, memory, network and disk utilization of all
|
||||
virtual machines running on a host.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
|
@ -65,17 +65,17 @@
|
|||
<dl>
|
||||
<dt><a href="http://virt-manager.org/">virt-manager</a></dt>
|
||||
<dd>
|
||||
A general purpose desktop management tool, able to manage
|
||||
virtual machines across both local and remotely accessed
|
||||
hypervisors. It is targeted at home and small office usage
|
||||
upto managing 10-20 hosts and their VMs.
|
||||
A general purpose desktop management tool, able to manage
|
||||
virtual machines across both local and remotely accessed
|
||||
hypervisors. It is targeted at home and small office usage
|
||||
upto managing 10-20 hosts and their VMs.
|
||||
</dd>
|
||||
<dt><a href="http://virt-manager.org/">virt-viewer</a></dt>
|
||||
<dd>
|
||||
A lightweight tool for accessing the graphical console
|
||||
associated with a virtual machine. It can securely connect
|
||||
to remote consoles supporting the VNC protocol. Also provides
|
||||
an optional mozilla browser plugin.
|
||||
A lightweight tool for accessing the graphical console
|
||||
associated with a virtual machine. It can securely connect
|
||||
to remote consoles supporting the VNC protocol. Also provides
|
||||
an optional mozilla browser plugin.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
|
@ -84,18 +84,18 @@
|
|||
<dl>
|
||||
<dt><a href="http://ovirt.org/">oVirt</a></dt>
|
||||
<dd>
|
||||
oVirt provides the ability to manage large numbers of virtual
|
||||
machines across an entire data center of hosts. It integrates
|
||||
with FreeIPA for Kerberos authentication, and in the future,
|
||||
certificate management.
|
||||
oVirt provides the ability to manage large numbers of virtual
|
||||
machines across an entire data center of hosts. It integrates
|
||||
with FreeIPA for Kerberos authentication, and in the future,
|
||||
certificate management.
|
||||
</dd>
|
||||
<dt><a href="http://community.abiquo.com/display/AbiCloud">AbiCloud</a></dt>
|
||||
<dd>
|
||||
AbiCloud is an open source cloud platform manager which allows to
|
||||
easily deploy a private cloud in your datacenter. One of the key
|
||||
differences of AbiCloud is the web rich interface for managing the
|
||||
infrastructure. You can deploy a new service just dragging and
|
||||
dropping a VM.
|
||||
AbiCloud is an open source cloud platform manager which allows to
|
||||
easily deploy a private cloud in your datacenter. One of the key
|
||||
differences of AbiCloud is the web rich interface for managing the
|
||||
infrastructure. You can deploy a new service just dragging and
|
||||
dropping a VM.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
|
@ -104,10 +104,10 @@
|
|||
<dl>
|
||||
<dt><a href="http://et.redhat.com/~rjones/virt-p2v/">virt-p2v</a></dt>
|
||||
<dd>
|
||||
A tool for converting a physical machine into a virtual machine. It
|
||||
is a LiveCD which is booted on the machine to be converted. It collects
|
||||
a little information from the user and then copies the disks over to
|
||||
a remote machine and defines the XML for a domain to run the guest.
|
||||
A tool for converting a physical machine into a virtual machine. It
|
||||
is a LiveCD which is booted on the machine to be converted. It collects
|
||||
a little information from the user and then copies the disks over to
|
||||
a remote machine and defines the XML for a domain to run the guest.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
|
@ -115,13 +115,13 @@
|
|||
<dl>
|
||||
<dt><a href="http://honk.sigxcpu.org/projects/libvirt/#munin">for munin</a></dt>
|
||||
<dd>
|
||||
The plugins provided by Guido Günther allow to monitor various things
|
||||
The plugins provided by Guido Günther allow to monitor various things
|
||||
like network and block I/O with
|
||||
<a href="http://munin.projects.linpro.no/">Munin</a>.
|
||||
</dd>
|
||||
<dt><a href="http://collectd.org/plugins/libvirt.shtml">for collectd</a></dt>
|
||||
<dd>
|
||||
The libvirt-plugin is part of <a href="http://collectd.org/">collectd</a>
|
||||
The libvirt-plugin is part of <a href="http://collectd.org/">collectd</a>
|
||||
and gather statistics about virtualized guests on a system. This
|
||||
way, you can collect CPU, network interface and block device usage
|
||||
for each guest without installing collectd on the guest systems.
|
||||
|
|
@ -130,8 +130,8 @@
|
|||
</dd>
|
||||
<dt><a href="http://et.redhat.com/~rjones/nagios-virt/">nagios-virt</a></dt>
|
||||
<dd>
|
||||
Nagios-virt is a configuration tool for adding monitoring of your
|
||||
virtualised domains to <a href="http://www.nagios.org/">Nagios</a>.
|
||||
Nagios-virt is a configuration tool for adding monitoring of your
|
||||
virtualised domains to <a href="http://www.nagios.org/">Nagios</a>.
|
||||
You can use this tool to either set up a new Nagios installation for
|
||||
your Xen or QEMU/KVM guests, or to integrate with your existing Nagios
|
||||
installation.
|
||||
|
|
|
|||
|
|
@ -11,26 +11,26 @@
|
|||
|
||||
<ul>
|
||||
<li><strong>VLAN 1</strong>. This virtual network has connectivity
|
||||
to <code>LAN 2</code> with traffic forwarded and NATed.
|
||||
to <code>LAN 2</code> with traffic forwarded and NATed.
|
||||
</li>
|
||||
<li><strong>VLAN 2</strong>. This virtual network is completely
|
||||
isolated from any physical LAN.
|
||||
isolated from any physical LAN.
|
||||
</li>
|
||||
<li><strong>Guest A</strong>. The first network interface is bridged
|
||||
to the physical <code>LAN 1</code>. The second interface is connected
|
||||
to a virtual network <code>VLAN 1</code>.
|
||||
to the physical <code>LAN 1</code>. The second interface is connected
|
||||
to a virtual network <code>VLAN 1</code>.
|
||||
</li>
|
||||
<li><strong>Guest B</strong>. The first network interface is connected
|
||||
to a virtual network <code>VLAN 1</code>, giving it limited NAT
|
||||
based connectivity to LAN2. It has a second network interface
|
||||
connected to <code>VLAN 2</code>. It acts a router allowing limited
|
||||
traffic between the two VLANs, thus giving <code>Guest C</code>
|
||||
connectivity to the physical <code>LAN 2</code>.
|
||||
</li>
|
||||
to a virtual network <code>VLAN 1</code>, giving it limited NAT
|
||||
based connectivity to LAN2. It has a second network interface
|
||||
connected to <code>VLAN 2</code>. It acts a router allowing limited
|
||||
traffic between the two VLANs, thus giving <code>Guest C</code>
|
||||
connectivity to the physical <code>LAN 2</code>.
|
||||
</li>
|
||||
<li><strong>Guest C</strong>. The only network interface is connected
|
||||
to a virtual network <code>VLAN 2</code>. It has no direct connectivity
|
||||
to a physical LAN, relying on <code>Guest B</codE> to route traffic
|
||||
on its behalf.
|
||||
to a virtual network <code>VLAN 2</code>. It has no direct connectivity
|
||||
to a physical LAN, relying on <code>Guest B</codE> to route traffic
|
||||
on its behalf.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
|
|
|||
|
|
@ -7,16 +7,16 @@
|
|||
</p>
|
||||
<ol>
|
||||
<li>
|
||||
<strong>Volume</strong> - a single storage volume which can
|
||||
be assigned to a guest, or used for creating further pools. A
|
||||
volume is either a block device, a raw file, or a special format
|
||||
file.
|
||||
<strong>Volume</strong> - a single storage volume which can
|
||||
be assigned to a guest, or used for creating further pools. A
|
||||
volume is either a block device, a raw file, or a special format
|
||||
file.
|
||||
</li>
|
||||
<li>
|
||||
<strong>Pool</strong> - provides a means for taking a chunk
|
||||
of storage and carving it up into volumes. A pool can be used to
|
||||
manage things such as a physical disk, a NFS server, a iSCSI target,
|
||||
a host adapter, an LVM group.
|
||||
<strong>Pool</strong> - provides a means for taking a chunk
|
||||
of storage and carving it up into volumes. A pool can be used to
|
||||
manage things such as a physical disk, a NFS server, a iSCSI target,
|
||||
a host adapter, an LVM group.
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
|
|
|
|||
|
|
@ -30,26 +30,26 @@
|
|||
<h2>Linux Distribution specific bug reports</h2>
|
||||
<ul>
|
||||
<li>
|
||||
If you are using official binaries from a <strong>Fedora distribution</strong>, enter
|
||||
tickets against the <code>Fedora</code> product and the <code>libvirt</code>
|
||||
component.
|
||||
<ul>
|
||||
<li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&product=Fedora">View Fedora libvirt tickets</a></li>
|
||||
<li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&component=libvirt">New Fedora libvirt ticket</a></li>
|
||||
</ul>
|
||||
If you are using official binaries from a <strong>Fedora distribution</strong>, enter
|
||||
tickets against the <code>Fedora</code> product and the <code>libvirt</code>
|
||||
component.
|
||||
<ul>
|
||||
<li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&product=Fedora">View Fedora libvirt tickets</a></li>
|
||||
<li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&component=libvirt">New Fedora libvirt ticket</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
If you are using official binaries from <strong>Red Hat Enterprise Linux distribution</strong>,
|
||||
tickets against the <code>Red Hat Enterprise Linux 5</code> product and
|
||||
the <code>libvirt</code> component.
|
||||
<ul>
|
||||
<li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&product=Red%20Hat%20Enterprise%20Linux%205">View Red Hat Enterprise Linux libvirt tickets</a></li>
|
||||
<li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%205&component=libvirt">New Red Hat Enterprise Linux libvirt ticket</a></li>
|
||||
</ul>
|
||||
If you are using official binaries from <strong>Red Hat Enterprise Linux distribution</strong>,
|
||||
tickets against the <code>Red Hat Enterprise Linux 5</code> product and
|
||||
the <code>libvirt</code> component.
|
||||
<ul>
|
||||
<li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&product=Red%20Hat%20Enterprise%20Linux%205">View Red Hat Enterprise Linux libvirt tickets</a></li>
|
||||
<li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%205&component=libvirt">New Red Hat Enterprise Linux libvirt ticket</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
If you are using official binaries from another Linux distribution first
|
||||
follow their own bug reporting guidelines.
|
||||
If you are using official binaries from another Linux distribution first
|
||||
follow their own bug reporting guidelines.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
|
@ -65,7 +65,7 @@
|
|||
|
||||
<ul>
|
||||
<li>The version number of the libvirt build, or date of the CVS
|
||||
checkout</li>
|
||||
checkout</li>
|
||||
<li>The hardware architecture being used</li>
|
||||
<li>The name of the hypervisor (Xen, QEMU, KVM)</li>
|
||||
<li>The XML config of the guest domain if relevant</li>
|
||||
|
|
|
|||
|
|
@ -13,24 +13,24 @@ start it using
|
|||
<p></p>
|
||||
<pre>
|
||||
<domain type='lxc'>
|
||||
<name>vm1</name>
|
||||
<memory>500000</memory>
|
||||
<os>
|
||||
<type>exe</type>
|
||||
<init>/bin/sh</init>
|
||||
</os>
|
||||
<vcpu>1</vcpu>
|
||||
<clock offset='utc'/>
|
||||
<on_poweroff>destroy</on_poweroff>
|
||||
<on_reboot>restart</on_reboot>
|
||||
<on_crash>destroy</on_crash>
|
||||
<devices>
|
||||
<emulator>/usr/libexec/libvirt_lxc</emulator>
|
||||
<interface type='network'>
|
||||
<source network='default'/>
|
||||
</interface>
|
||||
<console type='pty' />
|
||||
</devices>
|
||||
<name>vm1</name>
|
||||
<memory>500000</memory>
|
||||
<os>
|
||||
<type>exe</type>
|
||||
<init>/bin/sh</init>
|
||||
</os>
|
||||
<vcpu>1</vcpu>
|
||||
<clock offset='utc'/>
|
||||
<on_poweroff>destroy</on_poweroff>
|
||||
<on_reboot>restart</on_reboot>
|
||||
<on_crash>destroy</on_crash>
|
||||
<devices>
|
||||
<emulator>/usr/libexec/libvirt_lxc</emulator>
|
||||
<interface type='network'>
|
||||
<source network='default'/>
|
||||
</interface>
|
||||
<console type='pty' />
|
||||
</devices>
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
|
|
@ -42,28 +42,28 @@ debootstrap, whatever) under /opt/vm-1-root:
|
|||
<p></p>
|
||||
<pre>
|
||||
<domain type='lxc'>
|
||||
<name>vm1</name>
|
||||
<memory>32768</memory>
|
||||
<os>
|
||||
<type>exe</type>
|
||||
<init>/init</init>
|
||||
</os>
|
||||
<vcpu>1</vcpu>
|
||||
<clock offset='utc'/>
|
||||
<on_poweroff>destroy</on_poweroff>
|
||||
<on_reboot>restart</on_reboot>
|
||||
<on_crash>destroy</on_crash>
|
||||
<devices>
|
||||
<emulator>/usr/libexec/libvirt_lxc</emulator>
|
||||
<filesystem type='mount'>
|
||||
<source dir='/opt/vm-1-root'/>
|
||||
<target dir='/'/>
|
||||
</filesystem>
|
||||
<interface type='network'>
|
||||
<source network='default'/>
|
||||
</interface>
|
||||
<console type='pty' />
|
||||
</devices>
|
||||
<name>vm1</name>
|
||||
<memory>32768</memory>
|
||||
<os>
|
||||
<type>exe</type>
|
||||
<init>/init</init>
|
||||
</os>
|
||||
<vcpu>1</vcpu>
|
||||
<clock offset='utc'/>
|
||||
<on_poweroff>destroy</on_poweroff>
|
||||
<on_reboot>restart</on_reboot>
|
||||
<on_crash>destroy</on_crash>
|
||||
<devices>
|
||||
<emulator>/usr/libexec/libvirt_lxc</emulator>
|
||||
<filesystem type='mount'>
|
||||
<source dir='/opt/vm-1-root'/>
|
||||
<target dir='/'/>
|
||||
</filesystem>
|
||||
<interface type='network'>
|
||||
<source network='default'/>
|
||||
</interface>
|
||||
<console type='pty' />
|
||||
</devices>
|
||||
</domain>
|
||||
</pre>
|
||||
|
||||
|
|
|
|||
|
|
@ -18,9 +18,9 @@ tools and VM description files.</p>
|
|||
<ul>
|
||||
<li>
|
||||
<p style="margin-bottom: 0in">A working OpenNebula installation,
|
||||
version 1.2 or higher.
|
||||
</p>
|
||||
</li>
|
||||
version 1.2 or higher.
|
||||
</p>
|
||||
</li>
|
||||
</ul>
|
||||
<h2>
|
||||
<a name="uris"></a>Connections to OpenNebula driver</h2>
|
||||
|
|
@ -38,9 +38,9 @@ connection Uris for the driver are:
|
|||
<p>There are some limitations on the XML attributes that may be
|
||||
specified when interfacing OpenNebula. The following xml example
|
||||
details the attributes and options supported by the OpenNebula
|
||||
driver:</p>
|
||||
driver:</p>
|
||||
|
||||
<h3>Paravirtualized guest direct kernel boot
|
||||
<h3>Paravirtualized guest direct kernel boot
|
||||
</h3>
|
||||
<pre> <domain type='one'>
|
||||
<name>vm01</name>
|
||||
|
|
@ -80,7 +80,7 @@ driver:</p>
|
|||
<mac address='00:16:3e:5d:c7:9e'/>
|
||||
</interface>
|
||||
|
||||
<!--ONE Network-->
|
||||
<!--ONE Network-->
|
||||
<interface type='network'>
|
||||
<source network='onenetwork'/>
|
||||
</interface>
|
||||
|
|
@ -93,7 +93,7 @@ attach the interface to a previously configured network (named
|
|||
<tt>onenetwork</tt>) within the <a href="http://opennebula.org/">OpenNebula</a> system, typically with the
|
||||
<tt>onevnet</tt> CLI command.</p>
|
||||
|
||||
<p><b>Note</b>: OpenNebula supports the simultaneous use of different hypervisors, so you can specify any os type (linux or hvm) supported by your cluster.
|
||||
<p><b>Note</b>: OpenNebula supports the simultaneous use of different hypervisors, so you can specify any os type (linux or hvm) supported by your cluster.
|
||||
</p>
|
||||
|
||||
<h2>Links</h2>
|
||||
|
|
|
|||
|
|
@ -14,23 +14,23 @@
|
|||
|
||||
<ul>
|
||||
<li>
|
||||
<strong>QEMU emulators</strong>: The driver will probe <code>/usr/bin</code>
|
||||
for the presence of <code>qemu</code>, <code>qemu-system-x86_64</code>,
|
||||
<code>qemu-system-mips</code>,<code>qemu-system-mipsel</code>,
|
||||
<code>qemu-system-sparc</code>,<code>qemu-system-ppc</code>. The results
|
||||
of this can be seen from the capabilities XML output.
|
||||
<strong>QEMU emulators</strong>: The driver will probe <code>/usr/bin</code>
|
||||
for the presence of <code>qemu</code>, <code>qemu-system-x86_64</code>,
|
||||
<code>qemu-system-mips</code>,<code>qemu-system-mipsel</code>,
|
||||
<code>qemu-system-sparc</code>,<code>qemu-system-ppc</code>. The results
|
||||
of this can be seen from the capabilities XML output.
|
||||
</li>
|
||||
<li>
|
||||
<strong>KVM hypervisor</strong>: The driver will probe <code>/usr/bin</code>
|
||||
for the presence of <code>qemu-kvm</code> and <code>/dev/kvm</code> device
|
||||
node. If both are found, then KVM fullyvirtualized, hardware accelerated
|
||||
guests will be available.
|
||||
<strong>KVM hypervisor</strong>: The driver will probe <code>/usr/bin</code>
|
||||
for the presence of <code>qemu-kvm</code> and <code>/dev/kvm</code> device
|
||||
node. If both are found, then KVM fullyvirtualized, hardware accelerated
|
||||
guests will be available.
|
||||
</li>
|
||||
<li>
|
||||
<strong>Xenner hypervisor</strong>: The driver will probe <code>/usr/bin</code>
|
||||
for the presence of <code>xenner</code> and <code>/dev/kvm</code> device
|
||||
node. If both are found, then Xen paravirtualized guests can be run using
|
||||
the KVM hardware acceleration.
|
||||
<strong>Xenner hypervisor</strong>: The driver will probe <code>/usr/bin</code>
|
||||
for the presence of <code>xenner</code> and <code>/dev/kvm</code> device
|
||||
node. If both are found, then Xen paravirtualized guests can be run using
|
||||
the KVM hardware acceleration.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
|
@ -556,7 +556,7 @@ $ virsh domxml-to-native qemu-argv demo.xml
|
|||
|
||||
<h3>Xen paravirtualized guests with hardware acceleration</h3>
|
||||
|
||||
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -18,31 +18,31 @@
|
|||
|
||||
<ul>
|
||||
<li>
|
||||
<strong>XenD</strong>: Access to the Xen daemon is a mandatory
|
||||
requirement for the libvirt Xen driver. It requires that the UNIX
|
||||
socket interface be enabled in the <code>/etc/xen/xend-config.sxp</code>
|
||||
configuration file. Specifically the config settings
|
||||
<code>(xend-unix-server yes)</code>. This path is usually restricted
|
||||
to only allow the <code>root</code> user access. As an alternative,
|
||||
the HTTP interface can be used, however, this has significant security
|
||||
implications.
|
||||
<strong>XenD</strong>: Access to the Xen daemon is a mandatory
|
||||
requirement for the libvirt Xen driver. It requires that the UNIX
|
||||
socket interface be enabled in the <code>/etc/xen/xend-config.sxp</code>
|
||||
configuration file. Specifically the config settings
|
||||
<code>(xend-unix-server yes)</code>. This path is usually restricted
|
||||
to only allow the <code>root</code> user access. As an alternative,
|
||||
the HTTP interface can be used, however, this has significant security
|
||||
implications.
|
||||
</li>
|
||||
<li>
|
||||
<strong>XenStoreD</strong>: Access to the Xenstore daemon enables
|
||||
more efficient codepaths for looking up domain information which
|
||||
lowers the CPU overhead of management.
|
||||
<strong>XenStoreD</strong>: Access to the Xenstore daemon enables
|
||||
more efficient codepaths for looking up domain information which
|
||||
lowers the CPU overhead of management.
|
||||
</li>
|
||||
<li>
|
||||
<strong>Hypercalls</strong>: The ability to make direct hypercalls
|
||||
allows the most efficient codepaths in the driver to be used for
|
||||
monitoring domain status.
|
||||
<strong>Hypercalls</strong>: The ability to make direct hypercalls
|
||||
allows the most efficient codepaths in the driver to be used for
|
||||
monitoring domain status.
|
||||
</li>
|
||||
<li>
|
||||
<strong>XM config</strong>: When using Xen releases prior to 3.0.4,
|
||||
there is no inactive domain management in XenD. For such releases,
|
||||
libvirt will automatically process XM configuration files kept in
|
||||
the <code>/etc/xen</code> directory. It is important not to place
|
||||
any other non-config files in this directory.
|
||||
<strong>XM config</strong>: When using Xen releases prior to 3.0.4,
|
||||
there is no inactive domain management in XenD. For such releases,
|
||||
libvirt will automatically process XM configuration files kept in
|
||||
the <code>/etc/xen</code> directory. It is important not to place
|
||||
any other non-config files in this directory.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
|
|
|||
|
|
@ -37,17 +37,17 @@
|
|||
<dl>
|
||||
<dt><code>name</code></dt>
|
||||
<dd>The content of the <code>name</code> element provides
|
||||
a short name for the virtual machine. This name should
|
||||
consist only of alpha-numeric characters and is required
|
||||
to be unique within the scope of a single host. It is
|
||||
often used to form the filename for storing the persistent
|
||||
configuration file. <span class="since">Since 0.0.1</span></dd>
|
||||
a short name for the virtual machine. This name should
|
||||
consist only of alpha-numeric characters and is required
|
||||
to be unique within the scope of a single host. It is
|
||||
often used to form the filename for storing the persistent
|
||||
configuration file. <span class="since">Since 0.0.1</span></dd>
|
||||
<dt><code>uuid</code></dt>
|
||||
<dd>The content of the <code>uuid</code> element provides
|
||||
a globally unique identifier for the virtual machine.
|
||||
The format must be RFC 4122 compliant, eg <code>3e3fce45-4f53-4fa7-bb32-11f34168b82b</code>.
|
||||
If omitted when defining/creating a new machine, a random
|
||||
UUID is generated. <span class="since">Since 0.0.1</span></dd>
|
||||
a globally unique identifier for the virtual machine.
|
||||
The format must be RFC 4122 compliant, eg <code>3e3fce45-4f53-4fa7-bb32-11f34168b82b</code>.
|
||||
If omitted when defining/creating a new machine, a random
|
||||
UUID is generated. <span class="since">Since 0.0.1</span></dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsOS">Operating system booting</a></h3>
|
||||
|
|
@ -78,24 +78,24 @@
|
|||
<dl>
|
||||
<dt><code>type</code></dt>
|
||||
<dd>The content of the <code>type</code> element specifies the
|
||||
type of operating system to be booted in the virtual machine.
|
||||
<code>hvm</code> indicates that the OS is one designed to run
|
||||
on bare metal, so requires full virtualization. <code>linux</code>
|
||||
(badly named!) refers to an OS that supports the Xen 3 hypervisor
|
||||
guest ABI. There are also two optional attributes, <code>arch</code>
|
||||
specifying the CPU architecture to virtualization, and <code>machine</code>
|
||||
referring to the machine type. The <a href="formatcaps.html">Capabilities XML</a>
|
||||
provides details on allowed values for these. <span class="since">Since 0.0.1</span></dd>
|
||||
type of operating system to be booted in the virtual machine.
|
||||
<code>hvm</code> indicates that the OS is one designed to run
|
||||
on bare metal, so requires full virtualization. <code>linux</code>
|
||||
(badly named!) refers to an OS that supports the Xen 3 hypervisor
|
||||
guest ABI. There are also two optional attributes, <code>arch</code>
|
||||
specifying the CPU architecture to virtualization, and <code>machine</code>
|
||||
referring to the machine type. The <a href="formatcaps.html">Capabilities XML</a>
|
||||
provides details on allowed values for these. <span class="since">Since 0.0.1</span></dd>
|
||||
<dt><code>loader</code></dt>
|
||||
<dd>The optional <code>loader</code> tag refers to a firmware blob
|
||||
used to assist the domain creation process. At this time, it is
|
||||
only needed by Xen fully virtualized domains. <span class="since">Since 0.1.0</span></dd>
|
||||
used to assist the domain creation process. At this time, it is
|
||||
only needed by Xen fully virtualized domains. <span class="since">Since 0.1.0</span></dd>
|
||||
<dt><code>boot</code></dt>
|
||||
<dd>The <code>dev</code> attribute takes one of the values "fd", "hd",
|
||||
"cdrom" or "network" and is used to specify the next boot device
|
||||
to consider. The <code>boot</code> element can be repeated multiple
|
||||
times to setup a priority list of boot devices to try in turn.
|
||||
<span class="since">Since 0.1.3</span>
|
||||
"cdrom" or "network" and is used to specify the next boot device
|
||||
to consider. The <code>boot</code> element can be repeated multiple
|
||||
times to setup a priority list of boot devices to try in turn.
|
||||
<span class="since">Since 0.1.3</span>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
|
@ -111,22 +111,22 @@
|
|||
|
||||
<pre>
|
||||
...
|
||||
<bootloader>/usr/bin/pygrub</bootloader>
|
||||
<bootloader_args>--append single</bootloader_args>
|
||||
<bootloader>/usr/bin/pygrub</bootloader>
|
||||
<bootloader_args>--append single</bootloader_args>
|
||||
...</pre>
|
||||
|
||||
<dl>
|
||||
<dt><code>bootloader</code></dt>
|
||||
<dd>The content of the <code>bootloader</code> element provides
|
||||
a fully qualified path to the bootloader executable in the
|
||||
host OS. This bootloader will be run to choose which kernel
|
||||
to boot. The required output of the bootloader is dependent
|
||||
on the hypervisor in use. <span class="since">Since 0.1.0</span></dd>
|
||||
a fully qualified path to the bootloader executable in the
|
||||
host OS. This bootloader will be run to choose which kernel
|
||||
to boot. The required output of the bootloader is dependent
|
||||
on the hypervisor in use. <span class="since">Since 0.1.0</span></dd>
|
||||
<dt><code>bootloader_args</code></dt>
|
||||
<dd>The optional <code>bootloader_args</code> element allows
|
||||
command line arguments to be passed to the bootloader.
|
||||
<span class="since">Since 0.2.3</span>
|
||||
</dd>
|
||||
command line arguments to be passed to the bootloader.
|
||||
<span class="since">Since 0.2.3</span>
|
||||
</dd>
|
||||
|
||||
</dl>
|
||||
|
||||
|
|
@ -141,64 +141,64 @@
|
|||
|
||||
<pre>
|
||||
...
|
||||
<os>
|
||||
<os>
|
||||
<type>hvm</type>
|
||||
<loader>/usr/lib/xen/boot/hvmloader</loader>
|
||||
<kernel>/root/f8-i386-vmlinuz</kernel>
|
||||
<initrd>/root/f8-i386-initrd</initrd>
|
||||
<cmdline>console=ttyS0 ks=http://example.com/f8-i386/os/</cmdline>
|
||||
</os>
|
||||
...</pre>
|
||||
</os>
|
||||
...</pre>
|
||||
|
||||
<dl>
|
||||
<dt><code>type</code></dt>
|
||||
<dd>This element has the same semantics as described earlier in the
|
||||
<a href="#elementsOSBIOS">BIOS boot section</a></dd>
|
||||
<a href="#elementsOSBIOS">BIOS boot section</a></dd>
|
||||
<dt><code>loader</code></dt>
|
||||
<dd>This element has the same semantics as described earlier in the
|
||||
<a href="#elementsOSBIOS">BIOS boot section</a></dd>
|
||||
<a href="#elementsOSBIOS">BIOS boot section</a></dd>
|
||||
<dt><code>kernel</code></dt>
|
||||
<dd>The contents of this element specify the fully-qualified path
|
||||
to the kernel image in the host OS.</dd>
|
||||
to the kernel image in the host OS.</dd>
|
||||
<dt><code>initrd</code></dt>
|
||||
<dd>The contents of this element specify the fully-qualified path
|
||||
to the (optional) ramdisk image in the host OS.</dd>
|
||||
to the (optional) ramdisk image in the host OS.</dd>
|
||||
<dt><code>cmdline</code></dt>
|
||||
<dd>The contents of this element specify arguments to be passed to
|
||||
the kernel (or installer) at boottime. This is often used to
|
||||
specify an alternate primary console (eg serial port), or the
|
||||
installation media source / kickstart file</dd>
|
||||
the kernel (or installer) at boottime. This is often used to
|
||||
specify an alternate primary console (eg serial port), or the
|
||||
installation media source / kickstart file</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsResources">Basic resources</a></h3>
|
||||
|
||||
<pre>
|
||||
...
|
||||
<memory>524288</memory>
|
||||
<currentMemory>524288</currentMemory>
|
||||
<memoryBacking>
|
||||
<hugepages/>
|
||||
<memory>524288</memory>
|
||||
<currentMemory>524288</currentMemory>
|
||||
<memoryBacking>
|
||||
<hugepages/>
|
||||
</memoryBacking>
|
||||
<vcpu>1</vcpu>
|
||||
...</pre>
|
||||
<vcpu>1</vcpu>
|
||||
...</pre>
|
||||
|
||||
<dl>
|
||||
<dt><code>memory</code></dt>
|
||||
<dd>The maximum allocation of memory for the guest at boot time.
|
||||
The units for this value are kilobytes (i.e. blocks of 1024 bytes)</dd>
|
||||
The units for this value are kilobytes (i.e. blocks of 1024 bytes)</dd>
|
||||
<dt><code>currentMemory</code></dt>
|
||||
<dd>The actual allocation of memory for the guest. This value
|
||||
be less than the maximum allocation, to allow for ballooning
|
||||
up the guests memory on the fly. If this is omitted, it defaults
|
||||
to the same value as the <code>memory<code> element</dd>
|
||||
be less than the maximum allocation, to allow for ballooning
|
||||
up the guests memory on the fly. If this is omitted, it defaults
|
||||
to the same value as the <code>memory<code> element</dd>
|
||||
<dt><code>memoryBacking</code></dt>
|
||||
<dd>The optional <code>memoryBacking</code> element, may have an
|
||||
<code>hugepages</code> element set within it. This tells the
|
||||
hypervisor that the guest should have its memory allocated using
|
||||
hugepages instead of the normal native page size.</dd>
|
||||
<code>hugepages</code> element set within it. This tells the
|
||||
hypervisor that the guest should have its memory allocated using
|
||||
hugepages instead of the normal native page size.</dd>
|
||||
<dt><code>vcpu</code></dt>
|
||||
<dd>The content of this element defines the number of virtual
|
||||
CPUs allocated for the guest OS.</dd>
|
||||
CPUs allocated for the guest OS.</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsLifecycle">Lifecycle control</a></h3>
|
||||
|
|
@ -214,21 +214,21 @@
|
|||
|
||||
<pre>
|
||||
...
|
||||
<on_poweroff>destroy</on_poweroff>
|
||||
<on_reboot>restart</on_reboot>
|
||||
<on_crash>restart</on_crash>
|
||||
...</pre>
|
||||
<on_poweroff>destroy</on_poweroff>
|
||||
<on_reboot>restart</on_reboot>
|
||||
<on_crash>restart</on_crash>
|
||||
...</pre>
|
||||
|
||||
<dl>
|
||||
<dt><code>on_poweroff</code></dt>
|
||||
<dd>The content of this element specifies the action to take when
|
||||
the guest requests a poweroff.</dd>
|
||||
the guest requests a poweroff.</dd>
|
||||
<dt><code>on_reboot</code></dt>
|
||||
<dd>The content of this element specifies the action to take when
|
||||
the guest requests a reboot.</dd>
|
||||
the guest requests a reboot.</dd>
|
||||
<dt><code>on_crash</code></dt>
|
||||
<dd>The content of this element specifies the action to take when
|
||||
the guest crashes.</dd>
|
||||
the guest crashes.</dd>
|
||||
</dl>
|
||||
|
||||
<p>
|
||||
|
|
@ -238,16 +238,16 @@
|
|||
<dl>
|
||||
<dt><code>destroy</code></dt>
|
||||
<dd>The domain will be terminated completely and all resources
|
||||
released</dd>
|
||||
released</dd>
|
||||
<dt><code>restart</code></dt>
|
||||
<dd>The domain will be terminated, and then restarted with
|
||||
the same configuration</dd>
|
||||
the same configuration</dd>
|
||||
<dt><code>preserve</code></dt>
|
||||
<dd>The domain will be terminated, and its resource preserved
|
||||
to allow analysis.</dd>
|
||||
to allow analysis.</dd>
|
||||
<dt><code>rename-restart</code></dt>
|
||||
<dd>The domain will be terminated, and then restarted with
|
||||
a new name</dd>
|
||||
a new name</dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsFeatures">Hypervisor features</a></h3>
|
||||
|
|
@ -259,12 +259,12 @@
|
|||
|
||||
<pre>
|
||||
...
|
||||
<features>
|
||||
<pae/>
|
||||
<acpi/>
|
||||
<apic/>
|
||||
</features>
|
||||
...</pre>
|
||||
<features>
|
||||
<pae/>
|
||||
<acpi/>
|
||||
<apic/>
|
||||
</features>
|
||||
...</pre>
|
||||
|
||||
<p>
|
||||
All features are listed within the <code>features</code>
|
||||
|
|
@ -277,10 +277,10 @@
|
|||
<dl>
|
||||
<dt><code>pae</code></dt>
|
||||
<dd>Physical address extension mode allows 32-bit guests
|
||||
to address more than 4 GB of memory.</dd>
|
||||
to address more than 4 GB of memory.</dd>
|
||||
<dt><code>acpi</code></dt>
|
||||
<dd>ACPI is useful for power management, for example, with
|
||||
KVM guests it is required for graceful shutdown to work.
|
||||
KVM guests it is required for graceful shutdown to work.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
|
@ -296,13 +296,13 @@
|
|||
<pre>
|
||||
...
|
||||
<clock offset="localtime"/>
|
||||
...</pre>
|
||||
...</pre>
|
||||
|
||||
<dl>
|
||||
<dt><code>clock</code></dt>
|
||||
<dd>The <code>offset</code> attribute takes either "utc" or
|
||||
"localtime" to specify how the guest clock is initialized
|
||||
in relation to the host OS.
|
||||
"localtime" to specify how the guest clock is initialized
|
||||
in relation to the host OS.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
|
@ -318,17 +318,17 @@
|
|||
<pre>
|
||||
...
|
||||
<devices>
|
||||
<emulator>/usr/lib/xen/bin/qemu-dm</emulator>
|
||||
<emulator>/usr/lib/xen/bin/qemu-dm</emulator>
|
||||
...</pre>
|
||||
|
||||
<dl>
|
||||
<dt><code>emulator</code></dt>
|
||||
<dd>
|
||||
The contents of the <code>emulator</code> element specify
|
||||
the fully qualified path to the device model emulator binary.
|
||||
The <a href="formatcaps.html">capabilities XML</a> specifies
|
||||
the recommended default emulator to use for each particular
|
||||
domain type / architecture combination.
|
||||
The contents of the <code>emulator</code> element specify
|
||||
the fully qualified path to the device model emulator binary.
|
||||
The <a href="formatcaps.html">capabilities XML</a> specifies
|
||||
the recommended default emulator to use for each particular
|
||||
domain type / architecture combination.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
|
@ -342,47 +342,47 @@
|
|||
|
||||
<pre>
|
||||
...
|
||||
<disk type='file'>
|
||||
<driver name="tap" type="aio">
|
||||
<source file='/var/lib/xen/images/fv0'/>
|
||||
<target dev='hda' bus='ide'/>
|
||||
<disk type='file'>
|
||||
<driver name="tap" type="aio">
|
||||
<source file='/var/lib/xen/images/fv0'/>
|
||||
<target dev='hda' bus='ide'/>
|
||||
<encryption type='...'>
|
||||
...
|
||||
</encryption>
|
||||
</disk>
|
||||
...</pre>
|
||||
</disk>
|
||||
...</pre>
|
||||
|
||||
<dl>
|
||||
<dt><code>disk</code></dt>
|
||||
<dd>The <code>disk</code> element is the main container for describing
|
||||
disks. The <code>type</code> attribute is either "file" or "block"
|
||||
and refers to the underlying source for the disk. The optional
|
||||
<code>device</code> attribute indicates how the disk is to be exposed
|
||||
to the guest OS. Possible values for this attribute are "floppy", "disk"
|
||||
and "cdrom", defaulting to "disk".
|
||||
<span class="since">Since 0.0.3; "device" attribute since 0.1.4</span></dd>
|
||||
disks. The <code>type</code> attribute is either "file" or "block"
|
||||
and refers to the underlying source for the disk. The optional
|
||||
<code>device</code> attribute indicates how the disk is to be exposed
|
||||
to the guest OS. Possible values for this attribute are "floppy", "disk"
|
||||
and "cdrom", defaulting to "disk".
|
||||
<span class="since">Since 0.0.3; "device" attribute since 0.1.4</span></dd>
|
||||
<dt><code>source</code></dt>
|
||||
<dd>If the disk <code>type</code> is "file", then the <code>file</code> attribute
|
||||
specifies the fully-qualified path to the file holding the disk. If the disk
|
||||
<code>type</code> is "block", then the <code>dev</code> attribute specifies
|
||||
the path to the host device to serve as the disk. <span class="since">Since 0.0.3</span></dd>
|
||||
specifies the fully-qualified path to the file holding the disk. If the disk
|
||||
<code>type</code> is "block", then the <code>dev</code> attribute specifies
|
||||
the path to the host device to serve as the disk. <span class="since">Since 0.0.3</span></dd>
|
||||
<dt><code>target</code></dt>
|
||||
<dd>The <code>target</code> element controls the bus / device under which the
|
||||
disk is exposed to the guest OS. The <code>dev</code> attribute indicates
|
||||
the "logical" device name. The actual device name specified is not guaranteed to map to
|
||||
the device name in the guest OS. Treat it as a device ordering hint.
|
||||
The optional <code>bus</code> attribute specifies the type of disk device
|
||||
to emulate; possible values are driver specific, with typical values being
|
||||
"ide", "scsi", "virtio", "xen" or "usb". If omitted, the bus type is
|
||||
inferred from the style of the device name. eg, a device named 'sda'
|
||||
will typically be exported using a SCSI bus.
|
||||
<span class="since">Since 0.0.3; <code>bus</code> attribute since 0.4.3;
|
||||
disk is exposed to the guest OS. The <code>dev</code> attribute indicates
|
||||
the "logical" device name. The actual device name specified is not guaranteed to map to
|
||||
the device name in the guest OS. Treat it as a device ordering hint.
|
||||
The optional <code>bus</code> attribute specifies the type of disk device
|
||||
to emulate; possible values are driver specific, with typical values being
|
||||
"ide", "scsi", "virtio", "xen" or "usb". If omitted, the bus type is
|
||||
inferred from the style of the device name. eg, a device named 'sda'
|
||||
will typically be exported using a SCSI bus.
|
||||
<span class="since">Since 0.0.3; <code>bus</code> attribute since 0.4.3;
|
||||
"usb" attribute value since after 0.4.4</span></dd>
|
||||
<dt><code>driver</code></dt>
|
||||
<dd>If the hypervisor supports multiple backend drivers, then the optional
|
||||
<code>driver</code> element allows them to be selected. The <code>name</code>
|
||||
attribute is the primary backend driver name, while the optional <code>type</code>
|
||||
attribute provides the sub-type. <span class="since">Since 0.1.8</span>
|
||||
<code>driver</code> element allows them to be selected. The <code>name</code>
|
||||
attribute is the primary backend driver name, while the optional <code>type</code>
|
||||
attribute provides the sub-type. <span class="since">Since 0.1.8</span>
|
||||
</dd>
|
||||
<dt><code>encryption</code></dt>
|
||||
<dd>If present, specifies how the volume is encrypted. See
|
||||
|
|
@ -401,22 +401,22 @@
|
|||
|
||||
<pre>
|
||||
...
|
||||
<hostdev mode='subsystem' type='usb'>
|
||||
<source>
|
||||
<vendor id='0x1234'/>
|
||||
<product id='0xbeef'/>
|
||||
</source>
|
||||
</hostdev>
|
||||
...</pre>
|
||||
<hostdev mode='subsystem' type='usb'>
|
||||
<source>
|
||||
<vendor id='0x1234'/>
|
||||
<product id='0xbeef'/>
|
||||
</source>
|
||||
</hostdev>
|
||||
...</pre>
|
||||
<p>or:</p>
|
||||
<pre>
|
||||
...
|
||||
<hostdev mode='subsystem' type='pci'>
|
||||
<source>
|
||||
<address bus='0x06' slot='0x02' function='0x0'/>
|
||||
</source>
|
||||
</hostdev>
|
||||
...</pre>
|
||||
<hostdev mode='subsystem' type='pci'>
|
||||
<source>
|
||||
<address bus='0x06' slot='0x02' function='0x0'/>
|
||||
</source>
|
||||
</hostdev>
|
||||
...</pre>
|
||||
|
||||
<dl>
|
||||
<dt><code>hostdev</code></dt>
|
||||
|
|
@ -457,12 +457,12 @@
|
|||
|
||||
<pre>
|
||||
...
|
||||
<interface type='bridge'>
|
||||
<source bridge='xenbr0'/>
|
||||
<mac address='00:16:3e:5d:c7:9e'/>
|
||||
<script path='vif-bridge'/>
|
||||
</interface>
|
||||
...</pre>
|
||||
<interface type='bridge'>
|
||||
<source bridge='xenbr0'/>
|
||||
<mac address='00:16:3e:5d:c7:9e'/>
|
||||
<script path='vif-bridge'/>
|
||||
</interface>
|
||||
...</pre>
|
||||
|
||||
<h5><a name="elementsNICSVirtual">Virtual network</a></h5>
|
||||
|
||||
|
|
@ -663,16 +663,16 @@ qemu-kvm -net nic,model=? /dev/null
|
|||
|
||||
<pre>
|
||||
...
|
||||
<input type='mouse' bus='usb'/>
|
||||
...</pre>
|
||||
<input type='mouse' bus='usb'/>
|
||||
...</pre>
|
||||
|
||||
<dl>
|
||||
<dt><code>input</code></dt>
|
||||
<dd>The <code>input</code> element has one mandatory attribute, the <code>type</code>
|
||||
whose value can be either 'mouse' or 'tablet'. The latter provides absolute
|
||||
cursor movement, while the former uses relative movement. The optional
|
||||
<code>bus</code> attribute can be used to refine the exact device type.
|
||||
It takes values "xen" (paravirtualized), "ps2" and "usb".</dd>
|
||||
whose value can be either 'mouse' or 'tablet'. The latter provides absolute
|
||||
cursor movement, while the former uses relative movement. The optional
|
||||
<code>bus</code> attribute can be used to refine the exact device type.
|
||||
It takes values "xen" (paravirtualized), "ps2" and "usb".</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
|
|
@ -687,11 +687,11 @@ qemu-kvm -net nic,model=? /dev/null
|
|||
|
||||
<pre>
|
||||
...
|
||||
<graphics type='sdl' display=':0.0'/>
|
||||
<graphics type='vnc' port='5904'/>
|
||||
<graphics type='rdp' autoport='yes' multiUser='yes' />
|
||||
<graphics type='desktop' fullscreen='yes'/>
|
||||
...</pre>
|
||||
<graphics type='sdl' display=':0.0'/>
|
||||
<graphics type='vnc' port='5904'/>
|
||||
<graphics type='rdp' autoport='yes' multiUser='yes' />
|
||||
<graphics type='desktop' fullscreen='yes'/>
|
||||
...</pre>
|
||||
|
||||
<dl>
|
||||
<dt><code>graphics</code></dt>
|
||||
|
|
@ -775,16 +775,16 @@ qemu-kvm -net nic,model=? /dev/null
|
|||
<pre>
|
||||
...
|
||||
<parallel type='pty'>
|
||||
<source path='/dev/pts/2'/>
|
||||
<target port='0'/>
|
||||
<source path='/dev/pts/2'/>
|
||||
<target port='0'/>
|
||||
</parallel>
|
||||
<serial type='pty'>
|
||||
<source path='/dev/pts/3'/>
|
||||
<target port='0'/>
|
||||
<source path='/dev/pts/3'/>
|
||||
<target port='0'/>
|
||||
</serial>
|
||||
<console type='pty'>
|
||||
<source path='/dev/pts/4'/>
|
||||
<target port='0'/>
|
||||
<source path='/dev/pts/4'/>
|
||||
<target port='0'/>
|
||||
</console>
|
||||
</devices>
|
||||
</domain></pre>
|
||||
|
|
@ -797,17 +797,17 @@ qemu-kvm -net nic,model=? /dev/null
|
|||
<dd>Represents a serial port</dd>
|
||||
<dt><code>console</code></dt>
|
||||
<dd>Represents the primary console. This can be the paravirtualized
|
||||
console with Xen guests, or duplicates the primary serial port
|
||||
for fully virtualized guests without a paravirtualized console.</dd>
|
||||
console with Xen guests, or duplicates the primary serial port
|
||||
for fully virtualized guests without a paravirtualized console.</dd>
|
||||
<dt><code>source</code></dt>
|
||||
<dd>The attributes available for the <code>source</code> element
|
||||
vary according to the <code>type</code> attribute on the parent
|
||||
tag. Allowed variations will be described below</dd>
|
||||
vary according to the <code>type</code> attribute on the parent
|
||||
tag. Allowed variations will be described below</dd>
|
||||
<dt><code>target</code></dt>
|
||||
<dd>The port number of the character device is specified via the
|
||||
<code>port</code> attribute, numbered starting from 1. There is
|
||||
usually only one console device, and 0, 1 or 2 serial devices
|
||||
or parallel devices.
|
||||
<code>port</code> attribute, numbered starting from 1. There is
|
||||
usually only one console device, and 0, 1 or 2 serial devices
|
||||
or parallel devices.
|
||||
</dl>
|
||||
|
||||
<h5><a name="elementsCharSTDIO">Domain logfile</a></h5>
|
||||
|
|
@ -1061,45 +1061,45 @@ qemu-kvm -net nic,model=? /dev/null
|
|||
<dl>
|
||||
<dt><code>model</code></dt>
|
||||
<dd>
|
||||
<p>
|
||||
<p>
|
||||
The required <code>model</code> attribute specifies what real
|
||||
watchdog device is emulated. Valid values are specific to the
|
||||
underlying hypervisor.
|
||||
</p>
|
||||
<p>
|
||||
QEMU and KVM support:
|
||||
</p>
|
||||
<ul>
|
||||
<li> 'i6300esb' — the recommended device,
|
||||
emulating a PCI Intel 6300ESB </li>
|
||||
<li> 'ib700' — emulating an ISA iBase IB700 </li>
|
||||
</ul>
|
||||
watchdog device is emulated. Valid values are specific to the
|
||||
underlying hypervisor.
|
||||
</p>
|
||||
<p>
|
||||
QEMU and KVM support:
|
||||
</p>
|
||||
<ul>
|
||||
<li> 'i6300esb' — the recommended device,
|
||||
emulating a PCI Intel 6300ESB </li>
|
||||
<li> 'ib700' — emulating an ISA iBase IB700 </li>
|
||||
</ul>
|
||||
</dd>
|
||||
<dt><code>action</code></dt>
|
||||
<dd>
|
||||
<p>
|
||||
<p>
|
||||
The optional <code>action</code> attribute describes what
|
||||
action to take when the watchdog expires. Valid values are
|
||||
specific to the underlying hypervisor.
|
||||
</p>
|
||||
<p>
|
||||
QEMU and KVM support:
|
||||
</p>
|
||||
<ul>
|
||||
<li>'reset' — default, forcefully reset the guest</li>
|
||||
<li>'shutdown' — gracefully shutdown the guest
|
||||
(not recommended) </li>
|
||||
<li>'poweroff' — forcefully power off the guest</li>
|
||||
<li>'pause' — pause the guest</li>
|
||||
<li>'none' — do nothing</li>
|
||||
</ul>
|
||||
<p>
|
||||
Note that the 'shutdown' action requires that the guest
|
||||
is responsive to ACPI signals. In the sort of situations
|
||||
where the watchdog has expired, guests are usually unable
|
||||
to respond to ACPI signals. Therefore using 'shutdown'
|
||||
is not recommended.
|
||||
</p>
|
||||
action to take when the watchdog expires. Valid values are
|
||||
specific to the underlying hypervisor.
|
||||
</p>
|
||||
<p>
|
||||
QEMU and KVM support:
|
||||
</p>
|
||||
<ul>
|
||||
<li>'reset' — default, forcefully reset the guest</li>
|
||||
<li>'shutdown' — gracefully shutdown the guest
|
||||
(not recommended) </li>
|
||||
<li>'poweroff' — forcefully power off the guest</li>
|
||||
<li>'pause' — pause the guest</li>
|
||||
<li>'none' — do nothing</li>
|
||||
</ul>
|
||||
<p>
|
||||
Note that the 'shutdown' action requires that the guest
|
||||
is responsive to ACPI signals. In the sort of situations
|
||||
where the watchdog has expired, guests are usually unable
|
||||
to respond to ACPI signals. Therefore using 'shutdown'
|
||||
is not recommended.
|
||||
</p>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
|
|
|||
|
|
@ -35,17 +35,17 @@
|
|||
<dl>
|
||||
<dt><code>name</code></dt>
|
||||
<dd>The content of the <code>name</code> element provides
|
||||
a short name for the virtual network. This name should
|
||||
consist only of alpha-numeric characters and is required
|
||||
to be unique within the scope of a single host. It is
|
||||
used to form the filename for storing the persistent
|
||||
configuration file. <span class="since">Since 0.3.0</span></dd>
|
||||
a short name for the virtual network. This name should
|
||||
consist only of alpha-numeric characters and is required
|
||||
to be unique within the scope of a single host. It is
|
||||
used to form the filename for storing the persistent
|
||||
configuration file. <span class="since">Since 0.3.0</span></dd>
|
||||
<dt><code>uuid</code></dt>
|
||||
<dd>The content of the <code>uuid</code> element provides
|
||||
a globally unique identifier for the virtual network.
|
||||
The format must be RFC 4122 compliant, eg <code>3e3fce45-4f53-4fa7-bb32-11f34168b82b</code>.
|
||||
If omitted when defining/creating a new network, a random
|
||||
UUID is generated. <span class="since">Since 0.3.0</span></dd>
|
||||
a globally unique identifier for the virtual network.
|
||||
The format must be RFC 4122 compliant, eg <code>3e3fce45-4f53-4fa7-bb32-11f34168b82b</code>.
|
||||
If omitted when defining/creating a new network, a random
|
||||
UUID is generated. <span class="since">Since 0.3.0</span></dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="elementsConnect">Connectivity</a></h3>
|
||||
|
|
@ -58,32 +58,32 @@
|
|||
<pre>
|
||||
...
|
||||
<bridge name="virbr0" />
|
||||
<forward mode="nat" dev="eth0"/>
|
||||
...</pre>
|
||||
<forward mode="nat" dev="eth0"/>
|
||||
...</pre>
|
||||
|
||||
<dl>
|
||||
<dt><code>bridge</code></dt>
|
||||
<dd>The <code>name</code> attribute on the <code>bridge</code> element
|
||||
defines the name of a bridge device which will be used to construct
|
||||
the virtual network. The virtual machines will be connected to this
|
||||
bridge device allowing them to talk to each other. The bridge device
|
||||
may also be connected to the LAN. It is recommended that bridge
|
||||
device names started with the prefix <code>vir</code>, but the name
|
||||
<code>virbr0</code> is reserved for the "default" virtual network.
|
||||
This element should always be provided when defining a new network.
|
||||
<span class="since">Since 0.3.0</span>
|
||||
defines the name of a bridge device which will be used to construct
|
||||
the virtual network. The virtual machines will be connected to this
|
||||
bridge device allowing them to talk to each other. The bridge device
|
||||
may also be connected to the LAN. It is recommended that bridge
|
||||
device names started with the prefix <code>vir</code>, but the name
|
||||
<code>virbr0</code> is reserved for the "default" virtual network.
|
||||
This element should always be provided when defining a new network.
|
||||
<span class="since">Since 0.3.0</span>
|
||||
</dd>
|
||||
<dt><code>forward</code></dt>
|
||||
<dd>Inclusion of the <code>forward</code> element indicates that
|
||||
the virtual network is to be connected to the physical LAN. If
|
||||
no attributes are set, NAT forwarding will be used for connectivity.
|
||||
Firewall rules will allow forwarding to any other network device whether
|
||||
ethernet, wireless, dialup, or VPN. If the <code>dev</code> attribute
|
||||
is set, the firewall rules will restrict forwarding to the named
|
||||
device only. If the <code>mode</code> attribute is set to <code>route</code>
|
||||
then the traffic will not have NAT applied. This presumes that the
|
||||
local LAN router has suitable routing table entries to return traffic
|
||||
to this host. <span class="since">Since 0.3.0; 'mode' attribute since
|
||||
the virtual network is to be connected to the physical LAN. If
|
||||
no attributes are set, NAT forwarding will be used for connectivity.
|
||||
Firewall rules will allow forwarding to any other network device whether
|
||||
ethernet, wireless, dialup, or VPN. If the <code>dev</code> attribute
|
||||
is set, the firewall rules will restrict forwarding to the named
|
||||
device only. If the <code>mode</code> attribute is set to <code>route</code>
|
||||
then the traffic will not have NAT applied. This presumes that the
|
||||
local LAN router has suitable routing table entries to return traffic
|
||||
to this host. <span class="since">Since 0.3.0; 'mode' attribute since
|
||||
0.4.2</span></dd>
|
||||
</dl>
|
||||
|
||||
|
|
@ -96,50 +96,50 @@
|
|||
|
||||
<pre>
|
||||
...
|
||||
<ip address="192.168.122.1" netmask="255.255.255.0">
|
||||
<dhcp>
|
||||
<range start="192.168.122.100" end="192.168.122.254" />
|
||||
<host mac="00:16:3e:77:e2:ed" name="foo.example.com" ip="192.168.122.10" />
|
||||
<host mac="00:16:3e:3e:a9:1a" name="bar.example.com" ip="192.168.122.11" />
|
||||
</dhcp>
|
||||
</ip>
|
||||
<ip address="192.168.122.1" netmask="255.255.255.0">
|
||||
<dhcp>
|
||||
<range start="192.168.122.100" end="192.168.122.254" />
|
||||
<host mac="00:16:3e:77:e2:ed" name="foo.example.com" ip="192.168.122.10" />
|
||||
<host mac="00:16:3e:3e:a9:1a" name="bar.example.com" ip="192.168.122.11" />
|
||||
</dhcp>
|
||||
</ip>
|
||||
</network></pre>
|
||||
|
||||
<dl>
|
||||
<dt><code>ip</code></dt>
|
||||
<dd>The <code>address</code> attribute defines an IPv4 address in
|
||||
dotted-decimal format, that will be configured on the bridge
|
||||
device associated with the virtual network. To the guests this
|
||||
address will be their default route. The <code>netmask</code>
|
||||
attribute defines the significant bits of the network address,
|
||||
again specified in dotted-decimal format. <span class="since">Since 0.3.0</span>
|
||||
dotted-decimal format, that will be configured on the bridge
|
||||
device associated with the virtual network. To the guests this
|
||||
address will be their default route. The <code>netmask</code>
|
||||
attribute defines the significant bits of the network address,
|
||||
again specified in dotted-decimal format. <span class="since">Since 0.3.0</span>
|
||||
</dd><dt><code>tftp</code></dt><dd>Immediately within
|
||||
the <code>ip</code> element there is an optional <code>tftp</code>
|
||||
element. The presence of this element and of its attribute
|
||||
<code>root</code> enables TFTP services. The attribute specifies
|
||||
the path to the root directory served via TFTP.
|
||||
<span class="since">Since 0.7.1</span>
|
||||
the <code>ip</code> element there is an optional <code>tftp</code>
|
||||
element. The presence of this element and of its attribute
|
||||
<code>root</code> enables TFTP services. The attribute specifies
|
||||
the path to the root directory served via TFTP.
|
||||
<span class="since">Since 0.7.1</span>
|
||||
</dd><dt><code>dhcp</code></dt><dd>Also within the <code>ip</code> element there is an
|
||||
optional <code>dhcp</code> element. The presence of this element
|
||||
enables DHCP services on the virtual network. It will further
|
||||
contain one or more <code>range</code> elements.
|
||||
<span class="since">Since 0.3.0</span>
|
||||
optional <code>dhcp</code> element. The presence of this element
|
||||
enables DHCP services on the virtual network. It will further
|
||||
contain one or more <code>range</code> elements.
|
||||
<span class="since">Since 0.3.0</span>
|
||||
</dd>
|
||||
<dt><code>range</code></dt>
|
||||
<dd>The <code>start</code> and <code>end</code> attributes on the
|
||||
<code>range</code> element specify the boundaries of a pool of
|
||||
IPv4 addresses to be provided to DHCP clients. These two addresses
|
||||
must lie within the scope of the network defined on the parent
|
||||
<code>ip</code> element. <span class="since">Since 0.3.0</span>
|
||||
<code>range</code> element specify the boundaries of a pool of
|
||||
IPv4 addresses to be provided to DHCP clients. These two addresses
|
||||
must lie within the scope of the network defined on the parent
|
||||
<code>ip</code> element. <span class="since">Since 0.3.0</span>
|
||||
</dd>
|
||||
<dt><code>host</code></dt>
|
||||
<dd>Within the <code>dhcp</code> element there may be zero or more
|
||||
<code>host</code> elements; these specify hosts which will be given
|
||||
<code>host</code> elements; these specify hosts which will be given
|
||||
names and predefined IP addresses by the built-in DHCP server. Any
|
||||
such element must specify the MAC address of the host to be assigned
|
||||
a given name (via the <code>mac</code> attribute), the IP to be
|
||||
a given name (via the <code>mac</code> attribute), the IP to be
|
||||
assigned to that host (via the <code>ip</code> attribute), and the
|
||||
name to be given that host by the DHCP server (via the
|
||||
name to be given that host by the DHCP server (via the
|
||||
<code>name</code> attribute). <span class="since">Since 0.4.5</span>
|
||||
</dd><dt><code>bootp</code></dt><dd>The optional <code>bootp</code>
|
||||
element specifies BOOTP options to be provided by the DHCP server.
|
||||
|
|
@ -170,14 +170,14 @@
|
|||
|
||||
<pre>
|
||||
<network>
|
||||
<name>default</name>
|
||||
<bridge name="virbr0" />
|
||||
<forward mode="nat"/>
|
||||
<ip address="192.168.122.1" netmask="255.255.255.0">
|
||||
<dhcp>
|
||||
<range start="192.168.122.2" end="192.168.122.254" />
|
||||
</dhcp>
|
||||
</ip>
|
||||
<name>default</name>
|
||||
<bridge name="virbr0" />
|
||||
<forward mode="nat"/>
|
||||
<ip address="192.168.122.1" netmask="255.255.255.0">
|
||||
<dhcp>
|
||||
<range start="192.168.122.2" end="192.168.122.254" />
|
||||
</dhcp>
|
||||
</ip>
|
||||
</network></pre>
|
||||
|
||||
<h3><a name="examplesRoute">Routed network config</a></h3>
|
||||
|
|
@ -193,14 +193,14 @@
|
|||
|
||||
<pre>
|
||||
<network>
|
||||
<name>local</name>
|
||||
<bridge name="virbr1" />
|
||||
<forward mode="route" dev="eth1"/>
|
||||
<ip address="192.168.122.1" netmask="255.255.255.0">
|
||||
<dhcp>
|
||||
<range start="192.168.122.2" end="192.168.122.254" />
|
||||
</dhcp>
|
||||
</ip>
|
||||
<name>local</name>
|
||||
<bridge name="virbr1" />
|
||||
<forward mode="route" dev="eth1"/>
|
||||
<ip address="192.168.122.1" netmask="255.255.255.0">
|
||||
<dhcp>
|
||||
<range start="192.168.122.2" end="192.168.122.254" />
|
||||
</dhcp>
|
||||
</ip>
|
||||
</network></pre>
|
||||
|
||||
<h3><a name="examplesPrivate">Isolated network config</a></h3>
|
||||
|
|
@ -215,13 +215,13 @@
|
|||
|
||||
<pre>
|
||||
<network>
|
||||
<name>private</name>
|
||||
<bridge name="virbr2" />
|
||||
<ip address="192.168.152.1" netmask="255.255.255.0">
|
||||
<dhcp>
|
||||
<range start="192.168.152.2" end="192.168.152.254" />
|
||||
</dhcp>
|
||||
</ip>
|
||||
<name>private</name>
|
||||
<bridge name="virbr2" />
|
||||
<ip address="192.168.152.1" netmask="255.255.255.0">
|
||||
<dhcp>
|
||||
<range start="192.168.152.2" end="192.168.152.254" />
|
||||
</dhcp>
|
||||
</ip>
|
||||
</network></pre>
|
||||
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -37,10 +37,10 @@
|
|||
</dd>
|
||||
<dt><code>usage</code></dt>
|
||||
<dd>
|
||||
Specifies what this secret is used for. A mandatory
|
||||
<code>type</code> attribute specifies the usage category, currently
|
||||
only <code>volume</code> is defined. Specific usage categories are
|
||||
described below.
|
||||
Specifies what this secret is used for. A mandatory
|
||||
<code>type</code> attribute specifies the usage category, currently
|
||||
only <code>volume</code> is defined. Specific usage categories are
|
||||
described below.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
|
|
|||
|
|
@ -34,27 +34,27 @@
|
|||
<dl>
|
||||
<dt><code>name</code></dt>
|
||||
<dd>Providing a name for the pool which is unique to the host.
|
||||
This is mandatory when defining a pool. <span class="since">Since 0.4.1</span></dd>
|
||||
This is mandatory when defining a pool. <span class="since">Since 0.4.1</span></dd>
|
||||
<dt><code>uuid</code></dt>
|
||||
<dd>Providing an identifier for the pool which is globally unique.
|
||||
This is optional when defining a pool, a UUID will be generated if
|
||||
omitted. <span class="since">Since 0.4.1</span></dd>
|
||||
This is optional when defining a pool, a UUID will be generated if
|
||||
omitted. <span class="since">Since 0.4.1</span></dd>
|
||||
<dt><code>allocation</code></dt>
|
||||
<dd>Providing the total storage allocation for the pool. This may
|
||||
be larger than the sum of the allocation of all volumes due to
|
||||
metadata overhead. This value is in bytes. This is not applicable
|
||||
when creating a pool. <span class="since">Since 0.4.1</span></dd>
|
||||
be larger than the sum of the allocation of all volumes due to
|
||||
metadata overhead. This value is in bytes. This is not applicable
|
||||
when creating a pool. <span class="since">Since 0.4.1</span></dd>
|
||||
<dt><code>capacity</code></dt>
|
||||
<dd>Providing the total storage capacity for the pool. Due to
|
||||
underlying device constraints it may not be possible to use the
|
||||
full capacity for storage volumes. This value is in bytes. This
|
||||
is not applicable when creating a pool. <span class="since">Since 0.4.1</span></dd>
|
||||
underlying device constraints it may not be possible to use the
|
||||
full capacity for storage volumes. This value is in bytes. This
|
||||
is not applicable when creating a pool. <span class="since">Since 0.4.1</span></dd>
|
||||
<dt><code>available</code></dt>
|
||||
<dd>Providing the free space available for allocating new volumes
|
||||
in the pool. Due to underlying device constraints it may not be
|
||||
possible to allocate the entire free space to a single volume.
|
||||
This value is in bytes. This is not applicable when creating a
|
||||
pool. <span class="since">Since 0.4.1</span></dd>
|
||||
in the pool. Due to underlying device constraints it may not be
|
||||
possible to allocate the entire free space to a single volume.
|
||||
This value is in bytes. This is not applicable when creating a
|
||||
pool. <span class="since">Since 0.4.1</span></dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="StoragePoolSource">Source elements</a></h3>
|
||||
|
|
@ -71,38 +71,38 @@
|
|||
<host name="iscsi.example.com"/>
|
||||
<device path="demo-target"/>
|
||||
</source>
|
||||
...</pre>
|
||||
...</pre>
|
||||
|
||||
<dl>
|
||||
<dt><code>device</code></dt>
|
||||
<dd>Provides the source for pools backed by physical devices.
|
||||
May be repeated multiple times depending on backend driver. Contains
|
||||
a single attribute <code>path</code> which is the fully qualified
|
||||
path to the block device node. <span class="since">Since 0.4.1</span></dd>
|
||||
May be repeated multiple times depending on backend driver. Contains
|
||||
a single attribute <code>path</code> which is the fully qualified
|
||||
path to the block device node. <span class="since">Since 0.4.1</span></dd>
|
||||
<dt><code>directory</code></dt>
|
||||
<dd>Provides the source for pools backed by directories. May
|
||||
only occur once. Contains a single attribute <code>path</code>
|
||||
which is the fully qualified path to the block device node.
|
||||
<span class="since">Since 0.4.1</span></dd>
|
||||
only occur once. Contains a single attribute <code>path</code>
|
||||
which is the fully qualified path to the block device node.
|
||||
<span class="since">Since 0.4.1</span></dd>
|
||||
<dt><code>host</code></dt>
|
||||
<dd>Provides the source for pools backed by storage from a
|
||||
remote server. Will be used in combination with a <code>directory</code>
|
||||
or <code>device</code> element. Contains an attribute <code>name</code>
|
||||
which is the hostname or IP address of the server. May optionally
|
||||
contain a <code>port</code> attribute for the protocol specific
|
||||
port number. <span class="since">Since 0.4.1</span></dd>
|
||||
remote server. Will be used in combination with a <code>directory</code>
|
||||
or <code>device</code> element. Contains an attribute <code>name</code>
|
||||
which is the hostname or IP address of the server. May optionally
|
||||
contain a <code>port</code> attribute for the protocol specific
|
||||
port number. <span class="since">Since 0.4.1</span></dd>
|
||||
<dt><code>name</code></dt>
|
||||
<dd>Provides the source for pools backed by storage from a
|
||||
named element (e.g., a logical volume group name).
|
||||
remote server. Contains a string identifier.
|
||||
<span class="since">Since 0.4.5</span></dd>
|
||||
named element (e.g., a logical volume group name).
|
||||
remote server. Contains a string identifier.
|
||||
<span class="since">Since 0.4.5</span></dd>
|
||||
<dt><code>format</code></dt>
|
||||
<dd>Provides information about the format of the pool. This
|
||||
contains a single attribute <code>type</code> whose value is
|
||||
backend specific. This is typically used to indicate filesystem
|
||||
type, or network filesystem type, or partition table type, or
|
||||
LVM metadata type. All drivers are required to have a default
|
||||
value for this, so it is optional. <span class="since">Since 0.4.1</span></dd>
|
||||
contains a single attribute <code>type</code> whose value is
|
||||
backend specific. This is typically used to indicate filesystem
|
||||
type, or network filesystem type, or partition table type, or
|
||||
LVM metadata type. All drivers are required to have a default
|
||||
value for this, so it is optional. <span class="since">Since 0.4.1</span></dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="StoragePoolTarget">Target elements</a></h3>
|
||||
|
|
@ -133,27 +133,27 @@
|
|||
<dl>
|
||||
<dt><code>path</code></dt>
|
||||
<dd>Provides the location at which the pool will be mapped into
|
||||
the local filesystem namespace. For a filesystem/directory based
|
||||
pool it will be the name of the directory in which volumes will
|
||||
be created. For device based pools it will be the name of the directory in which
|
||||
devices nodes exist. For the latter <code>/dev/</code> may seem
|
||||
like the logical choice, however, devices nodes there are not
|
||||
guaranteed stable across reboots, since they are allocated on
|
||||
demand. It is preferable to use a stable location such as one
|
||||
of the <code>/dev/disk/by-{path,id,uuid,label</code> locations.
|
||||
<span class="since">Since 0.4.1</span>
|
||||
the local filesystem namespace. For a filesystem/directory based
|
||||
pool it will be the name of the directory in which volumes will
|
||||
be created. For device based pools it will be the name of the directory in which
|
||||
devices nodes exist. For the latter <code>/dev/</code> may seem
|
||||
like the logical choice, however, devices nodes there are not
|
||||
guaranteed stable across reboots, since they are allocated on
|
||||
demand. It is preferable to use a stable location such as one
|
||||
of the <code>/dev/disk/by-{path,id,uuid,label</code> locations.
|
||||
<span class="since">Since 0.4.1</span>
|
||||
</dd>
|
||||
<dt><code>permissions</code></dt>
|
||||
<dd>Provides information about the default permissions to use
|
||||
when creating volumes. This is currently only useful for directory
|
||||
or filesystem based pools, where the volumes allocated are simple
|
||||
files. For pools where the volumes are device nodes, the hotplug
|
||||
scripts determine permissions. It contains 4 child elements. The
|
||||
<code>mode</code> element contains the octal permission set. The
|
||||
<code>owner</code> element contains the numeric user ID. The <code>group</code>
|
||||
element contains the numeric group ID. The <code>label</code> element
|
||||
contains the MAC (eg SELinux) label string.
|
||||
<span class="since">Since 0.4.1</span>
|
||||
when creating volumes. This is currently only useful for directory
|
||||
or filesystem based pools, where the volumes allocated are simple
|
||||
files. For pools where the volumes are device nodes, the hotplug
|
||||
scripts determine permissions. It contains 4 child elements. The
|
||||
<code>mode</code> element contains the octal permission set. The
|
||||
<code>owner</code> element contains the numeric user ID. The <code>group</code>
|
||||
element contains the numeric group ID. The <code>label</code> element
|
||||
contains the MAC (eg SELinux) label string.
|
||||
<span class="since">Since 0.4.1</span>
|
||||
</dd>
|
||||
<dt><code>encryption</code></dt>
|
||||
<dd>If present, specifies how the volume is encrypted. See
|
||||
|
|
@ -192,41 +192,41 @@
|
|||
|
||||
<pre>
|
||||
<volume>
|
||||
<name>sparse.img</name>
|
||||
<key>/var/lib/xen/images/sparse.img</key>
|
||||
<name>sparse.img</name>
|
||||
<key>/var/lib/xen/images/sparse.img</key>
|
||||
<allocation>0</allocation>
|
||||
<capacity unit="T">1</capacity>
|
||||
<capacity unit="T">1</capacity>
|
||||
...</pre>
|
||||
|
||||
<dl>
|
||||
<dt><code>name</code></dt>
|
||||
<dd>Providing a name for the volume which is unique to the pool.
|
||||
This is mandatory when defining a volume. <span class="since">Since 0.4.1</span></dd>
|
||||
This is mandatory when defining a volume. <span class="since">Since 0.4.1</span></dd>
|
||||
<dt><code>key</code></dt>
|
||||
<dd>Providing an identifier for the volume which is globally unique.
|
||||
This is optional when defining a volume, a key will be generated if
|
||||
omitted. <span class="since">Since 0.4.1</span></dd>
|
||||
This is optional when defining a volume, a key will be generated if
|
||||
omitted. <span class="since">Since 0.4.1</span></dd>
|
||||
<dt><code>allocation</code></dt>
|
||||
<dd>Providing the total storage allocation for the volume. This
|
||||
may be smaller than the logical capacity if the volume is sparsely
|
||||
allocated. It may also be larger than the logical capacity if the
|
||||
volume has substantial metadata overhead. This value is in bytes.
|
||||
If omitted when creating a volume, the volume will be fully
|
||||
allocated at time of creation. If set to a value smaller than the
|
||||
capacity, the pool has the <strong>option</strong> of deciding
|
||||
to sparsely allocate a volume. It does not have to honour requests
|
||||
for sparse allocation though. <span class="since">Since 0.4.1</span></dd>
|
||||
may be smaller than the logical capacity if the volume is sparsely
|
||||
allocated. It may also be larger than the logical capacity if the
|
||||
volume has substantial metadata overhead. This value is in bytes.
|
||||
If omitted when creating a volume, the volume will be fully
|
||||
allocated at time of creation. If set to a value smaller than the
|
||||
capacity, the pool has the <strong>option</strong> of deciding
|
||||
to sparsely allocate a volume. It does not have to honour requests
|
||||
for sparse allocation though. <span class="since">Since 0.4.1</span></dd>
|
||||
<dt><code>capacity</code></dt>
|
||||
<dd>Providing the logical capacity for the volume. This value is
|
||||
in bytes. This is compulsory when creating a volume.
|
||||
<span class="since">Since 0.4.1</span></dd>
|
||||
in bytes. This is compulsory when creating a volume.
|
||||
<span class="since">Since 0.4.1</span></dd>
|
||||
<dt><code>source</code></dt>
|
||||
<dd>Provides information about the underlying storage allocation
|
||||
of the volume. This may not be available for some pool types.
|
||||
<span class="since">Since 0.4.1</span></dd>
|
||||
of the volume. This may not be available for some pool types.
|
||||
<span class="since">Since 0.4.1</span></dd>
|
||||
<dt><code>target</code></dt>
|
||||
<dd>Provides information about the representation of the volume
|
||||
on the local host. <span class="since">Since 0.4.1</span></dd>
|
||||
on the local host. <span class="since">Since 0.4.1</span></dd>
|
||||
</dl>
|
||||
|
||||
<h3><a name="StorageVolTarget">Target elements</a></h3>
|
||||
|
|
@ -240,7 +240,7 @@
|
|||
|
||||
<pre>
|
||||
...
|
||||
<target>
|
||||
<target>
|
||||
<path>/var/lib/virt/images/sparse.img</path>
|
||||
<format type='qcow2'/>
|
||||
<permissions>
|
||||
|
|
@ -249,33 +249,33 @@
|
|||
<mode>0744</mode>
|
||||
<label>virt_image_t</label>
|
||||
</permissions>
|
||||
</target></pre>
|
||||
</target></pre>
|
||||
|
||||
<dl>
|
||||
<dt><code>path</code></dt>
|
||||
<dd>Provides the location at which the volume can be accessed on
|
||||
the local filesystem, as an absolute path. This is a readonly
|
||||
attribute, so shouldn't be specified when creating a volume.
|
||||
<span class="since">Since 0.4.1</span></dd>
|
||||
the local filesystem, as an absolute path. This is a readonly
|
||||
attribute, so shouldn't be specified when creating a volume.
|
||||
<span class="since">Since 0.4.1</span></dd>
|
||||
<dt><code>format</code></dt>
|
||||
<dd>Provides information about the pool specific volume format.
|
||||
For disk pools it will provide the partition type. For filesystem
|
||||
or directory pools it will provide the file format type, eg cow,
|
||||
qcow, vmdk, raw. If omitted when creating a volume, the pool's
|
||||
default format will be used. The actual format is specified via
|
||||
the <code>type</code> attribute. Consult the pool-specific docs for
|
||||
For disk pools it will provide the partition type. For filesystem
|
||||
or directory pools it will provide the file format type, eg cow,
|
||||
qcow, vmdk, raw. If omitted when creating a volume, the pool's
|
||||
default format will be used. The actual format is specified via
|
||||
the <code>type</code> attribute. Consult the pool-specific docs for
|
||||
the list of valid values. <span class="since">Since 0.4.1</span></dd>
|
||||
<dt><code>permissions</code></dt>
|
||||
<dd>Provides information about the default permissions to use
|
||||
when creating volumes. This is currently only useful for directory
|
||||
or filesystem based pools, where the volumes allocated are simple
|
||||
files. For pools where the volumes are device nodes, the hotplug
|
||||
scripts determine permissions. It contains 4 child elements. The
|
||||
<code>mode</code> element contains the octal permission set. The
|
||||
<code>owner</code> element contains the numeric user ID. The <code>group</code>
|
||||
element contains the numeric group ID. The <code>label</code> element
|
||||
contains the MAC (eg SELinux) label string.
|
||||
<span class="since">Since 0.4.1</span>
|
||||
when creating volumes. This is currently only useful for directory
|
||||
or filesystem based pools, where the volumes allocated are simple
|
||||
files. For pools where the volumes are device nodes, the hotplug
|
||||
scripts determine permissions. It contains 4 child elements. The
|
||||
<code>mode</code> element contains the octal permission set. The
|
||||
<code>owner</code> element contains the numeric user ID. The <code>group</code>
|
||||
element contains the numeric group ID. The <code>label</code> element
|
||||
contains the MAC (eg SELinux) label string.
|
||||
<span class="since">Since 0.4.1</span>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
|
@ -305,25 +305,25 @@
|
|||
<dl>
|
||||
<dt><code>path</code></dt>
|
||||
<dd>Provides the location at which the backing store can be accessed on
|
||||
the local filesystem, as an absolute path. If omitted, there is no
|
||||
the local filesystem, as an absolute path. If omitted, there is no
|
||||
backing store for this volume.
|
||||
<span class="since">Since 0.6.0</span></dd>
|
||||
<span class="since">Since 0.6.0</span></dd>
|
||||
<dt><code>format</code></dt>
|
||||
<dd>Provides information about the pool specific backing store format.
|
||||
For disk pools it will provide the partition type. For filesystem
|
||||
or directory pools it will provide the file format type, eg cow,
|
||||
qcow, vmdk, raw. Consult the pool-specific docs for the list of valid
|
||||
For disk pools it will provide the partition type. For filesystem
|
||||
or directory pools it will provide the file format type, eg cow,
|
||||
qcow, vmdk, raw. Consult the pool-specific docs for the list of valid
|
||||
values. Most file formats require a backing store of the same format,
|
||||
however, the qcow2 format allows a different backing store format.
|
||||
<span class="since">Since 0.6.0</span></dd>
|
||||
<dt><code>permissions</code></dt>
|
||||
<dd>Provides information about the permissions of the backing file.
|
||||
It contains 4 child elements. The
|
||||
<code>mode</code> element contains the octal permission set. The
|
||||
<code>owner</code> element contains the numeric user ID. The <code>group</code>
|
||||
element contains the numeric group ID. The <code>label</code> element
|
||||
contains the MAC (eg SELinux) label string.
|
||||
<span class="since">Since 0.6.0</span>
|
||||
<code>mode</code> element contains the octal permission set. The
|
||||
<code>owner</code> element contains the numeric user ID. The <code>group</code>
|
||||
element contains the numeric group ID. The <code>label</code> element
|
||||
contains the MAC (eg SELinux) label string.
|
||||
<span class="since">Since 0.6.0</span>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
|
@ -362,10 +362,10 @@
|
|||
|
||||
<pre>
|
||||
<volume>
|
||||
<name>sparse.img</name>
|
||||
<allocation>0</allocation>
|
||||
<capacity unit="T">1</capacity>
|
||||
<target>
|
||||
<name>sparse.img</name>
|
||||
<allocation>0</allocation>
|
||||
<capacity unit="T">1</capacity>
|
||||
<target>
|
||||
<path>/var/lib/virt/images/sparse.img</path>
|
||||
<permissions>
|
||||
<owner>0744</owner>
|
||||
|
|
@ -373,7 +373,7 @@
|
|||
<mode>0744</mode>
|
||||
<label>virt_image_t</label>
|
||||
</permissions>
|
||||
</target>
|
||||
</target>
|
||||
</volume></pre>
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -8,50 +8,50 @@
|
|||
|
||||
<ol>
|
||||
<li>Discuss any large changes on the mailing list first. Post patches
|
||||
early and listen to feedback.</li>
|
||||
early and listen to feedback.</li>
|
||||
|
||||
<li><p>Post patches in unified diff format. A command similar to this
|
||||
should work:</p>
|
||||
<pre>
|
||||
should work:</p>
|
||||
<pre>
|
||||
diff -urp libvirt.orig/ libvirt.modified/ > libvirt-myfeature.patch
|
||||
</pre>
|
||||
<p>
|
||||
or:
|
||||
</p>
|
||||
<pre>
|
||||
<p>
|
||||
or:
|
||||
</p>
|
||||
<pre>
|
||||
cvs diff -up > libvirt-myfeature.patch
|
||||
</pre></li>
|
||||
<li>Split large changes into a series of smaller patches, self-contained
|
||||
if possible, with an explanation of each patch and an explanation of how
|
||||
the sequence of patches fits together.</li>
|
||||
if possible, with an explanation of each patch and an explanation of how
|
||||
the sequence of patches fits together.</li>
|
||||
<li>Make sure your patches apply against libvirt CVS. Developers
|
||||
only follow CVS and don't care much about released versions.</li>
|
||||
only follow CVS and don't care much about released versions.</li>
|
||||
<li><p>Run the automated tests on your code before submitting any changes.
|
||||
In particular, configure with compile warnings set to -Werror:</p>
|
||||
<pre>
|
||||
In particular, configure with compile warnings set to -Werror:</p>
|
||||
<pre>
|
||||
./configure --enable-compile-warnings=error
|
||||
</pre>
|
||||
<p>
|
||||
and run the tests:
|
||||
</p>
|
||||
<pre>
|
||||
<p>
|
||||
and run the tests:
|
||||
</p>
|
||||
<pre>
|
||||
make check
|
||||
make syntax-check
|
||||
make -C tests valgrind
|
||||
</pre>
|
||||
<p>
|
||||
The latter test checks for memory leaks.
|
||||
</p>
|
||||
<p>
|
||||
The latter test checks for memory leaks.
|
||||
</p>
|
||||
|
||||
<li>Update tests and/or documentation, particularly if you are adding
|
||||
a new feature or changing the output of a program.</li>
|
||||
a new feature or changing the output of a program.</li>
|
||||
</ol>
|
||||
|
||||
<p>
|
||||
There is more on this subject, including lots of links to background
|
||||
reading on the subject, on
|
||||
<a href="http://et.redhat.com/~rjones/how-to-supply-code-to-open-source-projects/">
|
||||
Richard Jones' guide to working with open source projects</a>
|
||||
Richard Jones' guide to working with open source projects</a>
|
||||
</p>
|
||||
|
||||
|
||||
|
|
@ -77,8 +77,8 @@
|
|||
(setq c-indent-level 4)
|
||||
(setq c-basic-offset 4))
|
||||
(add-hook 'c-mode-hook
|
||||
'(lambda () (if (string-match "/libvirt" (buffer-file-name))
|
||||
(libvirt-c-mode))))
|
||||
'(lambda () (if (string-match "/libvirt" (buffer-file-name))
|
||||
(libvirt-c-mode))))
|
||||
</pre>
|
||||
|
||||
<h2><a name="formatting">Code formatting (especially for new code)</a></h2>
|
||||
|
|
@ -118,30 +118,30 @@
|
|||
<ul>
|
||||
<li>If you're using "int" or "long", odds are good that there's a better type.</li>
|
||||
<li>If a variable is counting something, be sure to declare it with an
|
||||
unsigned type.</li>
|
||||
unsigned type.</li>
|
||||
<li>If it's memory-size-related, use size_t (use ssize_t only if required).</li>
|
||||
<li>If it's file-size related, use uintmax_t, or maybe off_t.</li>
|
||||
<li>If it's file-offset related (i.e., signed), use off_t.</li>
|
||||
<li>If it's just counting small numbers use "unsigned int";
|
||||
(on all but oddball embedded systems, you can assume that that
|
||||
type is at least four bytes wide).</li>
|
||||
(on all but oddball embedded systems, you can assume that that
|
||||
type is at least four bytes wide).</li>
|
||||
<li>If a variable has boolean semantics, give it the "bool" type
|
||||
and use the corresponding "true" and "false" macros. It's ok
|
||||
to include <stdbool.h>, since libvirt's use of gnulib ensures
|
||||
that it exists and is usable.</li>
|
||||
and use the corresponding "true" and "false" macros. It's ok
|
||||
to include <stdbool.h>, since libvirt's use of gnulib ensures
|
||||
that it exists and is usable.</li>
|
||||
<li>In the unusual event that you require a specific width, use a
|
||||
standard type like int32_t, uint32_t, uint64_t, etc.</li>
|
||||
standard type like int32_t, uint32_t, uint64_t, etc.</li>
|
||||
<li>While using "bool" is good for readability, it comes with minor caveats:
|
||||
<ul>
|
||||
<li>Don't use "bool" in places where the type size must be constant across
|
||||
all systems, like public interfaces and on-the-wire protocols. Note
|
||||
that it would be possible (albeit wasteful) to use "bool" in libvirt's
|
||||
logical wire protocol, since XDR maps that to its lower-level bool_t
|
||||
type, which *is* fixed-size.</li>
|
||||
<li>Don't compare a bool variable against the literal, "true",
|
||||
since a value with a logical non-false value need not be "1".
|
||||
I.e., don't write "if (seen == true) ...". Rather, write "if (seen)...".</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>Don't use "bool" in places where the type size must be constant across
|
||||
all systems, like public interfaces and on-the-wire protocols. Note
|
||||
that it would be possible (albeit wasteful) to use "bool" in libvirt's
|
||||
logical wire protocol, since XDR maps that to its lower-level bool_t
|
||||
type, which *is* fixed-size.</li>
|
||||
<li>Don't compare a bool variable against the literal, "true",
|
||||
since a value with a logical non-false value need not be "1".
|
||||
I.e., don't write "if (seen == true) ...". Rather, write "if (seen)...".</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
|
@ -250,14 +250,14 @@
|
|||
|
||||
<ul>
|
||||
<li><p>For strict equality:</p>
|
||||
<pre>
|
||||
<pre>
|
||||
STREQ(a,b)
|
||||
STRNEQ(a,b)
|
||||
</pre>
|
||||
</li>
|
||||
|
||||
<li><p>For case sensitive equality:</p>
|
||||
<pre>
|
||||
<pre>
|
||||
STRCASEEQ(a,b)
|
||||
STRCASENEQ(a,b)
|
||||
</pre>
|
||||
|
|
@ -265,7 +265,7 @@
|
|||
|
||||
<li><p>For strict equality of a substring:</p>
|
||||
|
||||
<pre>
|
||||
<pre>
|
||||
STREQLEN(a,b,n)
|
||||
STRNEQLEN(a,b,n)
|
||||
</pre>
|
||||
|
|
@ -273,7 +273,7 @@
|
|||
|
||||
<li><p>For case sensitive equality of a substring:</p>
|
||||
|
||||
<pre>
|
||||
<pre>
|
||||
STRCASEEQLEN(a,b,n)
|
||||
STRCASENEQLEN(a,b,n)
|
||||
</pre>
|
||||
|
|
@ -281,7 +281,7 @@
|
|||
|
||||
<li><p>For strict equality of a prefix:</p>
|
||||
|
||||
<pre>
|
||||
<pre>
|
||||
STRPREFIX(a,b)
|
||||
</pre>
|
||||
</li>
|
||||
|
|
@ -379,7 +379,7 @@
|
|||
|
||||
<pre>
|
||||
int virAsprintf(char **strp, const char *fmt, ...)
|
||||
ATTRIBUTE_FORMAT(printf, 2, 3);
|
||||
ATTRIBUTE_FORMAT(printf, 2, 3);
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
|
|
@ -416,16 +416,16 @@
|
|||
</p>
|
||||
<ul>
|
||||
<li>if a recently commited patch breaks compilation on a platform
|
||||
or for a given driver then it's fine to commit a minimal fix
|
||||
directly without getting the review feedback first</li>
|
||||
or for a given driver then it's fine to commit a minimal fix
|
||||
directly without getting the review feedback first</li>
|
||||
<li>if make check or make syntax-chek breaks, if there is
|
||||
an obvious fix, it's fine to commit immediately.
|
||||
The patch should still be sent to the list (or tell what the fix was if
|
||||
trivial) and 'make check syntax-check' should pass too before commiting
|
||||
anything</li>
|
||||
an obvious fix, it's fine to commit immediately.
|
||||
The patch should still be sent to the list (or tell what the fix was if
|
||||
trivial) and 'make check syntax-check' should pass too before commiting
|
||||
anything</li>
|
||||
<li>
|
||||
fixes for documentation and code comments can be managed
|
||||
in the same way, but still make sure they get reviewed if non-trivial.
|
||||
fixes for documentation and code comments can be managed
|
||||
in the same way, but still make sure they get reviewed if non-trivial.
|
||||
</li>
|
||||
</ul>
|
||||
</body>
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ updated on <i>2008-06-05</i>.
|
|||
<td> x </td>
|
||||
<td> ≥ 0.3.0 </td>
|
||||
<td> x </td>
|
||||
<td> x </td>
|
||||
<td> x </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td> virConnectGetType </td>
|
||||
|
|
|
|||
|
|
@ -7,26 +7,26 @@
|
|||
|
||||
<ul>
|
||||
<li>
|
||||
A toolkit to interact with the virtualization capabilities
|
||||
of recent versions of Linux (and other OSes).
|
||||
A toolkit to interact with the virtualization capabilities
|
||||
of recent versions of Linux (and other OSes).
|
||||
</li>
|
||||
<li>
|
||||
Free software available under the
|
||||
<a href="http://www.opensource.org/licenses/lgpl-license.html">GNU
|
||||
Lesser General Public License</a>.
|
||||
Free software available under the
|
||||
<a href="http://www.opensource.org/licenses/lgpl-license.html">GNU
|
||||
Lesser General Public License</a>.
|
||||
</li>
|
||||
|
||||
<li>
|
||||
A long term stable C API
|
||||
A long term stable C API
|
||||
</li>
|
||||
<li>
|
||||
A set of bindings for common languages
|
||||
A set of bindings for common languages
|
||||
</li>
|
||||
<li>
|
||||
A <a href="CIM/">CIM provider</a> for the DMTF virtualization schema
|
||||
A <a href="CIM/">CIM provider</a> for the DMTF virtualization schema
|
||||
</li>
|
||||
<li>
|
||||
A <a href="/qpid/">QMF agent</a> for the AMQP/QPid messaging system
|
||||
A <a href="/qpid/">QMF agent</a> for the AMQP/QPid messaging system
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
|
@ -34,29 +34,29 @@
|
|||
|
||||
<ul>
|
||||
<li>
|
||||
The <a href="http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html">Xen</a> hypervisor
|
||||
on Linux and Solaris hosts.
|
||||
The <a href="http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html">Xen</a> hypervisor
|
||||
on Linux and Solaris hosts.
|
||||
</li>
|
||||
<li>
|
||||
The <a href="http://bellard.org/qemu/">QEMU</a> emulator
|
||||
The <a href="http://bellard.org/qemu/">QEMU</a> emulator
|
||||
</li>
|
||||
<li>
|
||||
The <a href="http://kvm.qumranet.com/kvmwiki">KVM</a> Linux hypervisor
|
||||
The <a href="http://kvm.qumranet.com/kvmwiki">KVM</a> Linux hypervisor
|
||||
</li>
|
||||
<li>
|
||||
The <a href="http://lxc.sourceforge.net/">LXC</a> Linux container system
|
||||
The <a href="http://lxc.sourceforge.net/">LXC</a> Linux container system
|
||||
</li>
|
||||
<li>
|
||||
The <a href="http://openvz.org/">OpenVZ</a> Linux container system
|
||||
The <a href="http://openvz.org/">OpenVZ</a> Linux container system
|
||||
</li>
|
||||
<li>
|
||||
The <a href="http://user-mode-linux.sourceforge.net/">User Mode Linux</a> paravirtualized kernel
|
||||
The <a href="http://user-mode-linux.sourceforge.net/">User Mode Linux</a> paravirtualized kernel
|
||||
</li>
|
||||
<li>
|
||||
The <a href="http://www.virtualbox.org/">VirtualBox</a> hypervisor
|
||||
The <a href="http://www.virtualbox.org/">VirtualBox</a> hypervisor
|
||||
</li>
|
||||
<li>
|
||||
Storage on IDE/SCSI/USB disks, FibreChannel, LVM, iSCSI, NFS and filesystems
|
||||
Storage on IDE/SCSI/USB disks, FibreChannel, LVM, iSCSI, NFS and filesystems
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
|
|
|||
|
|
@ -1157,8 +1157,8 @@ and check the <a href="ChangeLog.html">ChangeLog</a> to gauge progress.</p>
|
|||
<ul>
|
||||
<li>Bug fixes: QEmu network serialization (Kaitlin Rupert), internal
|
||||
memory allocation fixes (Chris Lalancette Jim Meyering), virsh
|
||||
large file config problem (Jim Meyering), xen list APIs when
|
||||
max is zero, string escape problems in the xm driver </li>
|
||||
large file config problem (Jim Meyering), xen list APIs when
|
||||
max is zero, string escape problems in the xm driver </li>
|
||||
<li>Improvements: add autogen to tarballs, improve iSCSI support
|
||||
(Chris Lalancette), localization updates </li>
|
||||
<li>Cleanups: const-ness fixed (Daniel P. Berrange), string helpers
|
||||
|
|
@ -1168,60 +1168,60 @@ and check the <a href="ChangeLog.html">ChangeLog</a> to gauge progress.</p>
|
|||
<ul>
|
||||
<li>New features: Linux Container start and stop (Dave Leskovec),
|
||||
Network interface model settings (Daniel Berrange),serial and parallel
|
||||
device support for QEmu and Xen (Daniel Berrange),
|
||||
device support for QEmu and Xen (Daniel Berrange),
|
||||
Sound support for QEmu and Xen (Cole Robinson), vCPU settings for
|
||||
QEmu (Cole Robinson), support for NUMA and vCPU pinning in QEmu
|
||||
(Daniel Berrange), new virDomainBlockPeek API (Richard Jones)</li>
|
||||
QEmu (Cole Robinson), support for NUMA and vCPU pinning in QEmu
|
||||
(Daniel Berrange), new virDomainBlockPeek API (Richard Jones)</li>
|
||||
<li>Documentation: coding guidelines (Jim Meyering and Richard Jones),
|
||||
small man page missing entries and cleanup,
|
||||
Web site revamp (Daniel Berrange),
|
||||
typo fixes (Atsushi SAKAI), more docs on network XML format
|
||||
(Daniel Berrange), libvirt Wiki (Daniel Berrange),
|
||||
policykit config docs (Cole Robinson), XML domain docs revamp
|
||||
(Daniel Berrange), docs for remote listen-tls/tcp fixes (Kenneth
|
||||
Nagin), </li>
|
||||
Web site revamp (Daniel Berrange),
|
||||
typo fixes (Atsushi SAKAI), more docs on network XML format
|
||||
(Daniel Berrange), libvirt Wiki (Daniel Berrange),
|
||||
policykit config docs (Cole Robinson), XML domain docs revamp
|
||||
(Daniel Berrange), docs for remote listen-tls/tcp fixes (Kenneth
|
||||
Nagin), </li>
|
||||
<li>Bug fixes: save change to config file for Xen (Ryan Scott),
|
||||
fix /var/run/libvirt/ group ownership (Anton Protopopov),
|
||||
ancient libparted workaround (Soren Hansen), out of bount
|
||||
array access (Daniel Berrange), remote check bug (Dave Leskovec),
|
||||
LXC signal and daemon restart problems (Dave Leskovec), bus selection
|
||||
logic fix in the daemon config (Daniel Berrange), 2 memory leaks
|
||||
in the daemon (Jim Meyering), daemon pid file logic bug fix
|
||||
(Daniel Berrange), python generator fixes (Daniel Berrange),
|
||||
ivarious leaks and memory problem pointed by valgrind (Daniel
|
||||
Berrange), iptables forwarding cleanup (Daniel Berrange),
|
||||
Xen cpuset value checking (Hiroyuki Kaguchi), container process
|
||||
checks for LXC (Dave Leskovec), let xend check block device syntax
|
||||
(Hiroyuki Kaguchi), UUIDString for python fixes (Cole Robinson)</li>
|
||||
ancient libparted workaround (Soren Hansen), out of bount
|
||||
array access (Daniel Berrange), remote check bug (Dave Leskovec),
|
||||
LXC signal and daemon restart problems (Dave Leskovec), bus selection
|
||||
logic fix in the daemon config (Daniel Berrange), 2 memory leaks
|
||||
in the daemon (Jim Meyering), daemon pid file logic bug fix
|
||||
(Daniel Berrange), python generator fixes (Daniel Berrange),
|
||||
ivarious leaks and memory problem pointed by valgrind (Daniel
|
||||
Berrange), iptables forwarding cleanup (Daniel Berrange),
|
||||
Xen cpuset value checking (Hiroyuki Kaguchi), container process
|
||||
checks for LXC (Dave Leskovec), let xend check block device syntax
|
||||
(Hiroyuki Kaguchi), UUIDString for python fixes (Cole Robinson)</li>
|
||||
<li>Improvements: fixes for MinGW compilation (Richard Jones),
|
||||
autostart for running Xen domains (Cole Robinson),
|
||||
control of listening IP for daemon (Stefan de Konink),
|
||||
various Xenner related fixes and improvements (Daniel Berrange)
|
||||
autostart status printed in virsh domainfo (Shigeki Sakamoto),
|
||||
better error messages for xend driver (Richard Jones)</li>
|
||||
control of listening IP for daemon (Stefan de Konink),
|
||||
various Xenner related fixes and improvements (Daniel Berrange)
|
||||
autostart status printed in virsh domainfo (Shigeki Sakamoto),
|
||||
better error messages for xend driver (Richard Jones)</li>
|
||||
<li>Code cleanups: OpenVZ compilation (Richard Jones), conn dom and
|
||||
net fields deprecation in error structures (Richard Jones),
|
||||
Xen-ism on UUID (Richard Jones), add missing .pod to dist (Richard
|
||||
Jones), tab cleanup from sources (Jim Meyering), remove unused field
|
||||
in virsh control structure (Richard Jones), compilation without
|
||||
pthread.h (Jim Meyering), cleanup of tests (Daniel Berrange),
|
||||
syntax-check improvements (Jim Meyering), python cleanup,
|
||||
remove dependancy on libc is_* character tests (Jim Meyering),
|
||||
format related cleanups (Jim Meyering), cleanup of the buffer
|
||||
internal APIs (Daniel Berrange), conversion to the new memory
|
||||
allocation API (Daniel Berrange), lcov coverage testing
|
||||
(Daniel Berrange), gnulib updates (Jim Meyering), compatibility
|
||||
fix with RHEL 5 (Daniel Berrange), SuSE compatibility fix (Jim
|
||||
Fehlig), const'ification of a number of structures (Jim Meyering),
|
||||
string comparison macro cleanups (Daniel Berrange), character
|
||||
range testing cleanups and assorted bug fixes (Jim Meyering),
|
||||
QEmu test fixes (Daniel Berrange), configure macro cleanup (Daniel
|
||||
Berrange), refactor QEmu command line building code (Daniel Berrange),
|
||||
type punning warning in remote code (Richard Jones), refactoring
|
||||
of internal headers (Richard Jones), generic out of memory
|
||||
testing and associated bug fixes (Daniel Berrange), don't raise
|
||||
internal error for unsupported features (Kaitlin Rupert),
|
||||
missing driver entry points (Daniel Berrange)</li>
|
||||
Xen-ism on UUID (Richard Jones), add missing .pod to dist (Richard
|
||||
Jones), tab cleanup from sources (Jim Meyering), remove unused field
|
||||
in virsh control structure (Richard Jones), compilation without
|
||||
pthread.h (Jim Meyering), cleanup of tests (Daniel Berrange),
|
||||
syntax-check improvements (Jim Meyering), python cleanup,
|
||||
remove dependancy on libc is_* character tests (Jim Meyering),
|
||||
format related cleanups (Jim Meyering), cleanup of the buffer
|
||||
internal APIs (Daniel Berrange), conversion to the new memory
|
||||
allocation API (Daniel Berrange), lcov coverage testing
|
||||
(Daniel Berrange), gnulib updates (Jim Meyering), compatibility
|
||||
fix with RHEL 5 (Daniel Berrange), SuSE compatibility fix (Jim
|
||||
Fehlig), const'ification of a number of structures (Jim Meyering),
|
||||
string comparison macro cleanups (Daniel Berrange), character
|
||||
range testing cleanups and assorted bug fixes (Jim Meyering),
|
||||
QEmu test fixes (Daniel Berrange), configure macro cleanup (Daniel
|
||||
Berrange), refactor QEmu command line building code (Daniel Berrange),
|
||||
type punning warning in remote code (Richard Jones), refactoring
|
||||
of internal headers (Richard Jones), generic out of memory
|
||||
testing and associated bug fixes (Daniel Berrange), don't raise
|
||||
internal error for unsupported features (Kaitlin Rupert),
|
||||
missing driver entry points (Daniel Berrange)</li>
|
||||
</ul>
|
||||
<h3>0.4.2: Apr 8 2008</h3>
|
||||
<ul>
|
||||
|
|
|
|||
|
|
@ -22,28 +22,28 @@
|
|||
|
||||
<ul>
|
||||
<li>
|
||||
The <a href="http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html">Xen</a> hypervisor
|
||||
The <a href="http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html">Xen</a> hypervisor
|
||||
</li>
|
||||
<li>
|
||||
The <a href="http://bellard.org/qemu/">QEMU</a> emulator
|
||||
The <a href="http://bellard.org/qemu/">QEMU</a> emulator
|
||||
</li>
|
||||
<li>
|
||||
The <a href="http://kvm.qumranet.com/kvmwiki">KVM</a> Linux hypervisor
|
||||
The <a href="http://kvm.qumranet.com/kvmwiki">KVM</a> Linux hypervisor
|
||||
</li>
|
||||
<li>
|
||||
The <a href="http://lxc.sourceforge.net/">LXC</a> Linux container system
|
||||
The <a href="http://lxc.sourceforge.net/">LXC</a> Linux container system
|
||||
</li>
|
||||
<li>
|
||||
The <a href="http://openvz.org/">OpenVZ</a> Linux container system
|
||||
The <a href="http://openvz.org/">OpenVZ</a> Linux container system
|
||||
</li>
|
||||
<li>
|
||||
The <a href="http://virt.kernelnewbies.org/lguest">lGuest</a> paravirtualized hypervisor
|
||||
The <a href="http://virt.kernelnewbies.org/lguest">lGuest</a> paravirtualized hypervisor
|
||||
</li>
|
||||
<li>
|
||||
The <a href="http://virt.kernelnewbies.org/Linux-VServer">Linux-VServer</a> container system
|
||||
The <a href="http://virt.kernelnewbies.org/Linux-VServer">Linux-VServer</a> container system
|
||||
</li>
|
||||
<li>
|
||||
The <a href="http://virt.kernelnewbies.org/UML">User Mode Linux</a> paravirtualized hypervisor
|
||||
The <a href="http://virt.kernelnewbies.org/UML">User Mode Linux</a> paravirtualized hypervisor
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
|
@ -51,13 +51,13 @@
|
|||
|
||||
<ul>
|
||||
<li>
|
||||
<a href="http://virt.kernelnewbies.org/">Kernel Newbies Virtualization guide</a>
|
||||
<a href="http://virt.kernelnewbies.org/">Kernel Newbies Virtualization guide</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="http://www-128.ibm.com/developerworks/linux/library/l-linuxvirt/?ca=dgr-lnxw01Virtual-Linux">IBM developerworks virtualization guide</a>
|
||||
<a href="http://www-128.ibm.com/developerworks/linux/library/l-linuxvirt/?ca=dgr-lnxw01Virtual-Linux">IBM developerworks virtualization guide</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="http://en.wikipedia.org/wiki/Virtualization">Wikipedia Virtualization</a>
|
||||
<a href="http://en.wikipedia.org/wiki/Virtualization">Wikipedia Virtualization</a>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
|
|
|||
|
|
@ -202,10 +202,10 @@
|
|||
<a href="html/libvirt-virterror.html">virterror</a>
|
||||
<span>error handling interfaces for the libvirt library</span>
|
||||
</li>
|
||||
<li>
|
||||
<a href="hvsupport.html">Driver support</a>
|
||||
<span>matrix of API support per hypervisor per release</span>
|
||||
</li>
|
||||
<li>
|
||||
<a href="hvsupport.html">Driver support</a>
|
||||
<span>matrix of API support per hypervisor per release</span>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
|
|
@ -226,10 +226,10 @@
|
|||
<a href="internals.html">Internals</a>
|
||||
<span>Working on the internals of libvirt API, driver and daemon code</span>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="hacking.html">Contributor guidelines</a>
|
||||
<span>General hacking guidelines for contributors</span>
|
||||
</li>
|
||||
<li>
|
||||
<a href="hacking.html">Contributor guidelines</a>
|
||||
<span>General hacking guidelines for contributors</span>
|
||||
</li>
|
||||
<li>
|
||||
<a href="api_extension.html">API extensions</a>
|
||||
<span>Adding new public libvirt APIs</span>
|
||||
|
|
|
|||
Loading…
Reference in New Issue