mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-11-06 05:11:14 +00:00
a2232a5cc2
* src/libvirt_sym.version.in configure.in NEWS docs/*: release of 0.5.1 * po/*: updated and regenerated daniel
418 lines
16 KiB
HTML
418 lines
16 KiB
HTML
<?xml version="1.0" encoding="ISO-8859-1"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<!--
|
|
This file is autogenerated from storage.html.in
|
|
Do not edit this file. Changes will be lost.
|
|
-->
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
|
|
<link rel="stylesheet" type="text/css" href="main.css" />
|
|
<link rel="SHORTCUT ICON" href="32favicon.png" />
|
|
<title>libvirt: Storage Management</title>
|
|
<meta name="description" content="libvirt, virtualization, virtualization API" />
|
|
</head>
|
|
<body>
|
|
<div id="header">
|
|
<div id="headerLogo"></div>
|
|
<div id="headerSearch">
|
|
<form action="search.php" enctype="application/x-www-form-urlencoded" method="get"><div>
|
|
<input id="query" name="query" type="text" size="12" value="" />
|
|
<input id="submit" name="submit" type="submit" value="Search" />
|
|
</div></form>
|
|
</div>
|
|
</div>
|
|
<div id="body">
|
|
<div id="menu">
|
|
<ul class="l0"><li>
|
|
<div>
|
|
<a title="Front page of the libvirt website" class="inactive" href="index.html">Home</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="Details of new features and bugs fixed in each release" class="inactive" href="news.html">News</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="Get the latest source releases, binary builds and get access to the source repository" class="inactive" href="downloads.html">Downloads</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="Information for users, administrators and developers" class="active" href="docs.html">Documentation</a>
|
|
<ul class="l1"><li>
|
|
<div>
|
|
<a title="Information about deploying and using libvirt" class="inactive" href="deployment.html">Deployment</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="Overview of the logical subsystems in the libvirt API" class="inactive" href="intro.html">Architecture</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="Description of the XML formats used in libvirt" class="inactive" href="format.html">XML format</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="Hypervisor specific driver information" class="active" href="drivers.html">Drivers</a>
|
|
<ul class="l2"><li>
|
|
<div>
|
|
<a title="Driver the Xen hypervisor" class="inactive" href="drvxen.html">Xen</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="Driver for QEMU, KQEMU, KVM and Xenner" class="inactive" href="drvqemu.html">QEMU / KVM</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="Driver for the Linux native container API" class="inactive" href="drvlxc.html">Linux Container</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="Psuedo-driver simulating APIs in memory for test suites" class="inactive" href="drvtest.html">Test</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="Driver providing secure remote to the libvirt APIs" class="inactive" href="drvremote.html">Remote</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="Driver for the OpenVZ container technology" class="inactive" href="drvopenvz.html">OpenVZ</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="Driver for the User Mode Linux technology" class="inactive" href="drvuml.html">UML</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<span class="active">Storage</span>
|
|
</div>
|
|
</li></ul>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="Reference manual for the C public API" class="inactive" href="html/index.html">API reference</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
|
|
</div>
|
|
</li></ul>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="User contributed content" class="inactive" href="http://wiki.libvirt.org">Wiki</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="Frequently asked questions" class="inactive" href="FAQ.html">FAQ</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="How and where to report bugs and request features" class="inactive" href="bugs.html">Bug reports</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="How to contact the developers via email and IRC" class="inactive" href="contact.html">Contact</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="Miscellaneous links of interest related to libvirt" class="inactive" href="relatedlinks.html">Related Links</a>
|
|
</div>
|
|
</li><li>
|
|
<div>
|
|
<a title="Overview of all content on the website" class="inactive" href="sitemap.html">Sitemap</a>
|
|
</div>
|
|
</li></ul>
|
|
</div>
|
|
<div id="content">
|
|
<h1>Storage Management</h1>
|
|
<p>
|
|
This page describes the backends for the storage management capabilities in
|
|
libvirt.
|
|
</p>
|
|
<ul><li>
|
|
<a href="#StorageBackendDir">Directory backend</a>
|
|
</li><li>
|
|
<a href="#StorageBackendFS">Local filesystem backend</a>
|
|
</li><li>
|
|
<a href="#StorageBackendNetFS">Network filesystem backend</a>
|
|
</li><li>
|
|
<a href="#StorageBackendLogical">Logical backend</a>
|
|
</li><li>
|
|
<a href="#StorageBackendDisk">Disk backend</a>
|
|
</li><li>
|
|
<a href="#StorageBackendISCSI">iSCSI backend</a>
|
|
</li></ul>
|
|
<h2>
|
|
<a name="StorageBackendDir" id="StorageBackendDir">Directory pool</a>
|
|
</h2>
|
|
<p>
|
|
A pool with a type of <code>dir</code> provides the means to manage
|
|
files within a directory. The files can be fully allocated raw files,
|
|
sparsely allocated raw files, or one of the special disk formats
|
|
such as <code>qcow</code>,<code>qcow2</code>,<code>vmdk</code>,
|
|
<code>cow</code>, etc as supported by the <code>qemu-img</code>
|
|
program. If the directory does not exist at the time the pool is
|
|
defined, the <code>build</code> operation can be used to create it.
|
|
</p>
|
|
<h3>Example pool input definition</h3>
|
|
<pre>
|
|
<pool type="dir">
|
|
<name>virtimages</name>
|
|
<target>
|
|
<path>/var/lib/virt/images</path>
|
|
</target>
|
|
</pool>
|
|
</pre>
|
|
<h3>Valid pool format types</h3>
|
|
<p>
|
|
The directory pool does not use the pool format type element.
|
|
</p>
|
|
<h3>Valid volume format types</h3>
|
|
<p>
|
|
One of the following options:
|
|
</p>
|
|
<ul><li><code>raw</code>: a plain file</li><li><code>bochs</code>: Bochs disk image format</li><li><code>cloop</code>: compressed loopback disk image format</li><li><code>cow</code>: User Mode Linux disk image format</li><li><code>dmg</code>: Mac disk image format</li><li><code>iso</code>: CDROM disk image format</li><li><code>qcow</code>: QEMU v1 disk image format</li><li><code>qcow2</code>: QEMU v2 disk image format</li><li><code>vmdk</code>: VMWare disk image format</li><li><code>vpc</code>: VirtualPC disk image format</li></ul>
|
|
<p>
|
|
When listing existing volumes all these formats are supported
|
|
natively. When creating new volumes, only a subset may be
|
|
available. The <code>raw</code> type is guaranteed always
|
|
available. The <code>qcow2</code> type can be created if
|
|
either <code>qemu-img</code> or <code>qcow-create</code> tools
|
|
are present. The others are dependent on support of the
|
|
<code>qemu-img</code> tool.
|
|
|
|
</p>
|
|
<h2>
|
|
<a name="StorageBackendFS" id="StorageBackendFS">Filesystem pool</a>
|
|
</h2>
|
|
<p>
|
|
This is a variant of the directory pool. Instead of creating a
|
|
directory on an existing mounted filesystem though, it expects
|
|
a source block device to be named. This block device will be
|
|
mounted and files managed in the directory of its mount point.
|
|
It will default to allowing the kernel to automatically discover
|
|
the filesystem type, though it can be specified manually if
|
|
required.
|
|
</p>
|
|
<h3>Example pool input</h3>
|
|
<pre>
|
|
<pool type="fs">
|
|
<name>virtimages</name>
|
|
<source>
|
|
<device path="/dev/VolGroup00/VirtImages"/>
|
|
</source>
|
|
<target>
|
|
<path>/var/lib/virt/images</path>
|
|
</target>
|
|
</pool>
|
|
</pre>
|
|
<h3>Valid pool format types</h3>
|
|
<p>
|
|
The filesystem pool supports the following formats:
|
|
</p>
|
|
<ul><li><code>auto</code> - automatically determine format</li><li>
|
|
<code>ext2</code>
|
|
</li><li>
|
|
<code>ext3</code>
|
|
</li><li>
|
|
<code>ext4</code>
|
|
</li><li>
|
|
<code>ufs</code>
|
|
</li><li>
|
|
<code>iso9660</code>
|
|
</li><li>
|
|
<code>udf</code>
|
|
</li><li>
|
|
<code>gfs</code>
|
|
</li><li>
|
|
<code>gfs2</code>
|
|
</li><li>
|
|
<code>vfat</code>
|
|
</li><li>
|
|
<code>hfs+</code>
|
|
</li><li>
|
|
<code>xfs</code>
|
|
</li></ul>
|
|
<h3>Valid volume format types</h3>
|
|
<p>
|
|
The valid volume types are the same as for the <code>directory</code>
|
|
pool type.
|
|
</p>
|
|
<h2>
|
|
<a name="StorageBackendNetFS" id="StorageBackendNetFS">Network filesystem pool</a>
|
|
</h2>
|
|
<p>
|
|
This is a variant of the filesystem pool. Instead of requiring
|
|
a local block device as the source, it requires the name of a
|
|
host and path of an exported directory. It will mount this network
|
|
filesystem and manage files within the directory of its mount
|
|
point. It will default to using NFS as the protocol.
|
|
</p>
|
|
<h3>Example pool input</h3>
|
|
<pre>
|
|
<pool type="netfs">
|
|
<name>virtimages</name>
|
|
<source>
|
|
<host name="nfs.example.com"/>
|
|
<dir path="/var/lib/virt/images"/>
|
|
</source>
|
|
<target>
|
|
<path>/var/lib/virt/images</path>
|
|
</target>
|
|
</pool>
|
|
</pre>
|
|
<h3>Valid pool format types</h3>
|
|
<p>
|
|
The network filesystem pool supports the following formats:
|
|
</p>
|
|
<ul><li><code>auto</code> - automatically determine format</li><li>
|
|
<code>nfs</code>
|
|
</li></ul>
|
|
<h3>Valid volume format types</h3>
|
|
<p>
|
|
The valid volume types are the same as for the <code>directory</code>
|
|
pool type.
|
|
</p>
|
|
<h2>
|
|
<a name="StorageBackendLogical" id="StorageBackendLogical">Logical volume pools</a>
|
|
</h2>
|
|
<p>
|
|
This provides a pool based on an LVM volume group. For a
|
|
pre-defined LVM volume group, simply providing the group
|
|
name is sufficient, while to build a new group requires
|
|
providing a list of source devices to serve as physical
|
|
volumes. Volumes will be allocated by carving out chunks
|
|
of storage from the volume group.
|
|
</p>
|
|
<h3>Example pool input</h3>
|
|
<pre>
|
|
<pool type="logical">
|
|
<name>HostVG</name>
|
|
<source>
|
|
<device path="/dev/sda1"/>
|
|
<device path="/dev/sdb1"/>
|
|
<device path="/dev/sdc1"/>
|
|
</source>
|
|
<target>
|
|
<path>/dev/HostVG</path>
|
|
</target>
|
|
</pool>
|
|
</pre>
|
|
<h3>Valid pool format types</h3>
|
|
<p>
|
|
The logical volume pool does not use the pool format type element.
|
|
</p>
|
|
<h3>Valid volume format types</h3>
|
|
<p>
|
|
The logical volume pool does not use the volume format type element.
|
|
</p>
|
|
<h2>
|
|
<a name="StorageBackendDisk" id="StorageBackendDisk">Disk volume pools</a>
|
|
</h2>
|
|
<p>
|
|
This provides a pool based on a physical disk. Volumes are created
|
|
by adding partitions to the disk. Disk pools are have constraints
|
|
on the size and placement of volumes. The 'free extents'
|
|
information will detail the regions which are available for creating
|
|
new volumes. A volume cannot span across 2 different free extents.
|
|
</p>
|
|
<h3>Example pool input</h3>
|
|
<pre>
|
|
<pool type="disk">
|
|
<name>sda</name>
|
|
<source>
|
|
<device path='/dev/sda'/>
|
|
</source>
|
|
<target>
|
|
<path>/dev</path>
|
|
</target>
|
|
</pool>
|
|
</pre>
|
|
<h3>Valid pool format types</h3>
|
|
<p>
|
|
The disk volume pool accepts the following pool format types, representing
|
|
the common partition table types:
|
|
</p>
|
|
<ul><li>
|
|
<code>dos</code>
|
|
</li><li>
|
|
<code>dvh</code>
|
|
</li><li>
|
|
<code>gpt</code>
|
|
</li><li>
|
|
<code>mac</code>
|
|
</li><li>
|
|
<code>bsd</code>
|
|
</li><li>
|
|
<code>pc98</code>
|
|
</li><li>
|
|
<code>sun</code>
|
|
</li></ul>
|
|
<p>
|
|
The <code>dos</code> or <code>gpt</code> formats are recommended for
|
|
best portability - the latter is needed for disks larger than 2TB.
|
|
</p>
|
|
<h3>Valid volume format types</h3>
|
|
<p>
|
|
The disk volume pool accepts the following volume format types, representing
|
|
the common partition entry types:
|
|
</p>
|
|
<ul><li>
|
|
<code>none</code>
|
|
</li><li>
|
|
<code>linux</code>
|
|
</li><li>
|
|
<code>fat16</code>
|
|
</li><li>
|
|
<code>fat32</code>
|
|
</li><li>
|
|
<code>linux-swap</code>
|
|
</li><li>
|
|
<code>linux-lvm</code>
|
|
</li><li>
|
|
<code>linux-raid</code>
|
|
</li><li>
|
|
<code>extended</code>
|
|
</li></ul>
|
|
<h2>
|
|
<a name="StorageBackendISCSI" id="StorageBackendISCSI">iSCSI volume pools</a>
|
|
</h2>
|
|
<p>
|
|
This provides a pool based on an iSCSI target. Volumes must be
|
|
pre-allocated on the iSCSI server, and cannot be created via
|
|
the libvirt APIs. Since /dev/XXX names may change each time libvirt
|
|
logs into the iSCSI target, it is recommended to configure the pool
|
|
to use <code>/dev/disk/by-path</code> or <code>/dev/disk/by-id</code>
|
|
for the target path. These provide persistent stable naming for LUNs
|
|
</p>
|
|
<h3>Example pool input</h3>
|
|
<pre>
|
|
<pool type="iscsi">
|
|
<name>virtimages</name>
|
|
<source>
|
|
<host name="iscsi.example.com"/>
|
|
<device path="demo-target"/>
|
|
</source>
|
|
<target>
|
|
<path>/dev/disk/by-path</path>
|
|
</target>
|
|
</pool>
|
|
</pre>
|
|
<h3>Valid pool format types</h3>
|
|
<p>
|
|
The iSCSI volume pool does not use the pool format type element.
|
|
</p>
|
|
<h3>Valid volume format types</h3>
|
|
<p>
|
|
The iSCSI volume pool does not use the volume format type element.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
<div id="footer">
|
|
<p id="sponsor">
|
|
Sponsored by:<br /><a href="http://et.redhat.com/"><img src="et.png" alt="Project sponsored by Red Hat Emerging Technology" /></a></p>
|
|
</div>
|
|
</body>
|
|
</html>
|