mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-26 03:21:44 +03:00
5bc4307597
Got sick of seeing the "validity error : ID Objects already defined" errors, which this patch addresses.
421 lines
12 KiB
XML
421 lines
12 KiB
XML
<?xml version="1.0"?>
|
|
<html>
|
|
<body>
|
|
<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>
|
|
<li>
|
|
<a href="#StorageBackendSCSI">SCSI backend</a>
|
|
</li>
|
|
<li>
|
|
<a href="#StorageBackendMultipath">Multipath backend</a>
|
|
</li>
|
|
</ul>
|
|
|
|
<h2><a name="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">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">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">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">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">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>
|
|
|
|
<h2><a name="StorageBackendSCSI">SCSI volume pools</a></h2>
|
|
<p>
|
|
This provides a pool based on a SCSI HBA. Volumes are preexisting SCSI
|
|
LUNs, and cannot be created via the libvirt APIs. Since /dev/XXX names
|
|
aren't generally stable, 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
|
|
<span class="since">Since 0.6.2</span>
|
|
</p>
|
|
|
|
<h3>Example pool input</h3>
|
|
<pre>
|
|
<pool type="scsi">
|
|
<name>virtimages</name>
|
|
<source>
|
|
<adapter name="host0"/>
|
|
</source>
|
|
<target>
|
|
<path>/dev/disk/by-path</path>
|
|
</target>
|
|
</pool></pre>
|
|
|
|
<h3>Valid pool format types</h3>
|
|
<p>
|
|
The SCSI volume pool does not use the pool format type element.
|
|
</p>
|
|
|
|
<h3>Valid volume format types</h3>
|
|
<p>
|
|
The SCSI volume pool does not use the volume format type element.
|
|
</p>
|
|
|
|
<h2><a name="StorageBackendMultipath">Multipath pools</a></h2>
|
|
<p>
|
|
This provides a pool that contains all the multipath devices on the
|
|
host. Volume creating is not supported via the libvirt APIs.
|
|
The target element is actually ignored, but one is required to appease
|
|
the libvirt XML parser.<br/>
|
|
<br/>
|
|
Configuring multipathing is not currently supported, this just covers
|
|
the case where users want to discover all the available multipath
|
|
devices, and assign them to guests.
|
|
<span class="since">Since 0.7.1</span>
|
|
</p>
|
|
|
|
<h3>Example pool input</h3>
|
|
<pre>
|
|
<pool type="mpath">
|
|
<name>virtimages</name>
|
|
<target>
|
|
<path>/dev/mapper</path>
|
|
</target>
|
|
</pool></pre>
|
|
|
|
<h3>Valid pool format types</h3>
|
|
<p>
|
|
The Multipath volume pool does not use the pool format type element.
|
|
</p>
|
|
|
|
<h3>Valid volume format types</h3>
|
|
<p>
|
|
The Multipath volume pool does not use the volume format type element.
|
|
</p>
|
|
|
|
|
|
</body>
|
|
</html>
|