* docs/libvir.html docs/storage.html: apply documentation fixes

and typos cleanup from Atsushi Sakai
Daniel

ChangeLog

@@ -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

docs/libvir.html

@@ -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>

docs/storage.html

@@ -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>