mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-08-27 02:51:16 +00:00
* docs/libvir.html docs/storage.html: apply documentation fixes
and typos cleanup from Atsushi Sakai Daniel
This commit is contained in:
parent
d4cbf4c624
commit
f5ade63437
@ -1,3 +1,8 @@
|
||||
Fri Mar 7 12:11:53 CET 2008 Daniel Veillard <veillard@redhat.com>
|
||||
|
||||
* docs/libvir.html docs/storage.html: apply documentation fixes
|
||||
and typos cleanup from Atsushi Sakai
|
||||
|
||||
Fri Mar 7 10:22:00 CET 2008 Daniel Veillard <veillard@redhat.com>
|
||||
|
||||
* src/xend_internal.c: applied patch from Cole Robinson to not
|
||||
|
@ -4069,7 +4069,7 @@ full capacity for storage volumes. This value is in bytes. This
|
||||
is not applicable when creating a pool.</dd>
|
||||
|
||||
<dt>available</dt>
|
||||
<dd>Providing the free space available for allocating new volums
|
||||
<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
|
||||
@ -4119,11 +4119,11 @@ value for this, so it is optional.</dd>
|
||||
<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 tbe directory in which
|
||||
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
|
||||
guarenteed stable across reboots, since they are allocated on
|
||||
demand. It is preferrable to use a stable location such as one
|
||||
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.
|
||||
</dd>
|
||||
<dt>permissions<dt>
|
||||
@ -4145,7 +4145,7 @@ contains the MAC (eg SELinux) label string.
|
||||
If a storage pool exposes information about its underlying
|
||||
placement / allocation scheme, the <code>device</code> element
|
||||
within the <code>source</code> element may contain information
|
||||
about its avilable extents. Some pools have a constraint that
|
||||
about its available extents. Some pools have a constraint that
|
||||
a volume must be allocated entirely within a single constraint
|
||||
(eg disk partition pools). Thus the extent information allows an
|
||||
application to determine the maximum possible size for a new
|
||||
@ -4209,10 +4209,10 @@ on the local host.</dd>
|
||||
<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 tbe directory in which
|
||||
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
|
||||
guarenteed stable across reboots, since they are allocated on
|
||||
guaranteed stable across reboots, since they are allocated on
|
||||
demand. It is preferrable to use a stable location such as one
|
||||
of the <code>/dev/disk/by-{path,id,uuid,label</code> locations.
|
||||
</dd>
|
||||
@ -4297,10 +4297,10 @@ One of the following options:
|
||||
<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 guarenteed always
|
||||
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 dependant on support of the
|
||||
are present. The others are dependent on support of the
|
||||
<code>qemu-img</code> tool.
|
||||
|
||||
<h4><a name="StorageBackendFS">Filesystem pool</a></h4>
|
||||
@ -4332,7 +4332,7 @@ required.
|
||||
<h5>Valid pool format types</h5>
|
||||
|
||||
<p>
|
||||
The fileystem pool supports the following formats:
|
||||
The filesystem pool supports the following formats:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
@ -4385,7 +4385,7 @@ point. It will default to using NFS as the protocol.
|
||||
<h5>Valid pool format types</h5>
|
||||
|
||||
<p>
|
||||
The network fileystem pool supports the following formats:
|
||||
The network filesystem pool supports the following formats:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
|
@ -84,7 +84,7 @@ full capacity for storage volumes. This value is in bytes. This
|
||||
is not applicable when creating a pool.</dd>
|
||||
|
||||
<dt>available</dt>
|
||||
<dd>Providing the free space available for allocating new volums
|
||||
<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
|
||||
@ -128,11 +128,11 @@ value for this, so it is optional.</dd>
|
||||
<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 tbe directory in which
|
||||
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
|
||||
guarenteed stable across reboots, since they are allocated on
|
||||
demand. It is preferrable to use a stable location such as one
|
||||
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.
|
||||
</dd>
|
||||
<dt>permissions<dt>
|
||||
@ -152,7 +152,7 @@ contains the MAC (eg SELinux) label string.
|
||||
If a storage pool exposes information about its underlying
|
||||
placement / allocation scheme, the <code>device</code> element
|
||||
within the <code>source</code> element may contain information
|
||||
about its avilable extents. Some pools have a constraint that
|
||||
about its available extents. Some pools have a constraint that
|
||||
a volume must be allocated entirely within a single constraint
|
||||
(eg disk partition pools). Thus the extent information allows an
|
||||
application to determine the maximum possible size for a new
|
||||
@ -212,10 +212,10 @@ on the local host.</dd>
|
||||
<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 tbe directory in which
|
||||
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
|
||||
guarenteed stable across reboots, since they are allocated on
|
||||
guaranteed stable across reboots, since they are allocated on
|
||||
demand. It is preferrable to use a stable location such as one
|
||||
of the <code>/dev/disk/by-{path,id,uuid,label</code> locations.
|
||||
</dd>
|
||||
@ -293,10 +293,10 @@ One of the following options:
|
||||
</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 guarenteed always
|
||||
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 dependant on support of the
|
||||
are present. The others are dependent on support of the
|
||||
<code>qemu-img</code> tool.
|
||||
|
||||
</p><h4><a name="StorageBackendFS" id="StorageBackendFS">Filesystem pool</a></h4>
|
||||
@ -328,7 +328,7 @@ required.
|
||||
<h5>Valid pool format types</h5>
|
||||
|
||||
<p>
|
||||
The fileystem pool supports the following formats:
|
||||
The filesystem pool supports the following formats:
|
||||
</p>
|
||||
|
||||
<ul><li><code>auto</code> - automatically determine format</li>
|
||||
@ -378,7 +378,7 @@ point. It will default to using NFS as the protocol.
|
||||
<h5>Valid pool format types</h5>
|
||||
|
||||
<p>
|
||||
The network fileystem pool supports the following formats:
|
||||
The network filesystem pool supports the following formats:
|
||||
</p>
|
||||
|
||||
<ul><li><code>auto</code> - automatically determine format</li>
|
||||
|
Loading…
Reference in New Issue
Block a user