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
<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:
<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">
<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>
<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>
<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>
<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>
<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>
<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.
</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.
<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>
</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>
<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.
+
<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.
+
<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>
<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>
<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>
<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>
<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>
<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>
<mac address='00:16:3e:5d:c7:9e'/>
</interface>
- <!--ONE Network-->
+ <!--ONE Network-->
<interface type='network'>
<source network='onenetwork'/>
</interface>
<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>
<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>
<h3>Xen paravirtualized guests with hardware acceleration</h3>
-
+
</body>
</html>
<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>
<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>
<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>
<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>
<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>
<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>
<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>
<pre>
...
- <features>
- <pae/>
- <acpi/>
- <apic/>
- </features>
- ...</pre>
+ <features>
+ <pae/>
+ <acpi/>
+ <apic/>
+ </features>
+ ...</pre>
<p>
All features are listed within the <code>features</code>
<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>
<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>
<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>
<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
<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>
<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>
<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>
<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>
<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>
<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>
<dl>
<dt><code>model</code></dt>
<dd>
- <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>
+ QEMU and KVM support:
+ </p>
+ <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>
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>
+ QEMU and KVM support:
+ </p>
+ <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>
+ 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>
<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>
<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>
<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.
<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>
<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>
<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>
</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>
<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>
<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>
<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
<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>
<pre>
...
- <target>
+ <target>
<path>/var/lib/virt/images/sparse.img</path>
<format type='qcow2'/>
<permissions>
<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>
<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>
<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>
<mode>0744</mode>
<label>virt_image_t</label>
</permissions>
- </target>
+ </target>
</volume></pre>
</body>
</html>
<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>
diff -urp libvirt.orig/ libvirt.modified/ > libvirt-myfeature.patch
</pre>
- <p>
- or:
- </p>
- <pre>
+ or:
+ </p>
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>
./configure --enable-compile-warnings=error
</pre>
- <p>
- and run the tests:
- </p>
- <pre>
+ and run the tests:
+ </p>
make check
make syntax-check
make -C tests valgrind
</pre>
- <p>
- The latter test checks for memory leaks.
- </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>
(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>
<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>
+ <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>
<ul>
<li><p>For strict equality:</p>
- <pre>
STREQ(a,b)
STRNEQ(a,b)
</pre>
</li>
<li><p>For case sensitive equality:</p>
- <pre>
STRCASEEQ(a,b)
STRCASENEQ(a,b)
</pre>
<li><p>For strict equality of a substring:</p>
- <pre>
STREQLEN(a,b,n)
STRNEQLEN(a,b,n)
</pre>
<li><p>For case sensitive equality of a substring:</p>
- <pre>
STRCASEEQLEN(a,b,n)
STRCASENEQLEN(a,b,n)
</pre>
<li><p>For strict equality of a prefix:</p>
- <pre>
STRPREFIX(a,b)
</pre>
</li>
<pre>
int virAsprintf(char **strp, const char *fmt, ...)
- ATTRIBUTE_FORMAT(printf, 2, 3);
+ ATTRIBUTE_FORMAT(printf, 2, 3);
</pre>
<p>
</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>
<td> x </td>
<td> ≥ 0.3.0 </td>
<td> x </td>
- <td> x </td>
+ <td> x </td>
</tr>
<tr>
<td> virConnectGetType </td>
<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>
<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>
<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
<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>
<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>
<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>
<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>
<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>
projects / libvirt.git / commitdiff