docs/formatdomain.html docs/formatdomain.html.in docs/java.html docs/java.html.in
+Fri Aug 8 19:18:43 JST 2008 Atsushi SAKAI <sakaia@jp.fujitsu.com>
+
+ * docs/formatdomain.html docs/formatdomain.html.in
+ docs/java.html docs/java.html.in: fix typos
+
Thu Aug 7 19:47:40 CEST 2008 Daniel Veillard <veillard@redhat.com>
* tests/domainschematest: patch from Guido Günther to fix RNG checking
(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>
- refering to the machine type. The <a href="formatcaps.html">Capabilities XML</a>
+ refer
ring 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 fullyvirtualized 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",
+ 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.
<p>
Hypervisors employing paravirtualization do not usually emulate
a BIOS, and instead the host is responsible to kicking off the
- operating system boot. This may use a pseduo-bootloader in the
+ operating system boot. This may use a pseudo-bootloader in the
host to provide an interface to choose a kernel for the guest.
An example is <code>pygrub</code> with Xen.
</p>
<bootloader_args>--append single</bootloader_args>
...</pre>
<dl><dt><code>bootloader</code></dt><dd>The content of the <code>bootloader</code> element provides
- a fullyqualified path to the bootloader executable in the
+ 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 dependant
+ 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>
<a name="elementsLifecycle" id="elementsLifecycle">Lifecycle control</a>
</h3>
<p>
- It is sometimes neccessary to override the default actions taken
+ It is sometimes necessary to override the default actions taken
when a guest OS triggers a lifecycle operation. The following
collections of elements allow the actions to be specified. A
common use case is to force a reboot to be treated as a poweroff
<a name="elementsDevices" id="elementsDevices">Devices</a>
</h3>
<p>
- The final set of XML elements are all used to descibe devices
+ The final set of XML elements are all used to describe devices
provided to the guest domain. All devices occur as children
of the main <code>devices</code> element.
<span class="since">Since 0.1.3</span>
<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 guarenteed to map to
+ 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
...
<input type='mouse' bus='usb'/>
...</pre>
- <dl><dt><code>input</code></dt><dd>The <code>input</code> element has one madatory attribute, the <code>type</code>
+ <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.
...</pre>
<p>
NB special case if <console type='pty'>, then the TTY
- path is also duplicated as an attribute tty='/dv/pts/3'
+ path is also duplicated as an attribute tty='/dev/pts/3'
on the top level <console> tag. This provides compat
with existing syntax for <console> tags.
</p>
The character device is passed through to the underlying
physical character device. The device types must match,
eg the emulated serial port should only be connected to
- a host serial port - dont connect a serial port to a parallel
+ a host serial port - don't connect a serial port to a parallel
port.
</p>
<pre>
(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>
- refering to the machine type. The <a href="formatcaps.html">Capabilities XML</a>
+ refer
ring 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 fullyvirtualized domains. <span class="since">Since 0.1.0</span></dd>
+ 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
<p>
Hypervisors employing paravirtualization do not usually emulate
a BIOS, and instead the host is responsible to kicking off the
- operating system boot. This may use a pseduo-bootloader in the
+ operating system boot. This may use a pseudo-bootloader in the
host to provide an interface to choose a kernel for the guest.
An example is <code>pygrub</code> with Xen.
</p>
<dl>
<dt><code>bootloader</code></dt>
<dd>The content of the <code>bootloader</code> element provides
- a fullyqualified path to the bootloader executable in the
+ 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 dependant
+ 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
<h3><a name="elementsLifecycle">Lifecycle control</a></h3>
<p>
- It is sometimes neccessary to override the default actions taken
+ It is sometimes necessary to override the default actions taken
when a guest OS triggers a lifecycle operation. The following
collections of elements allow the actions to be specified. A
common use case is to force a reboot to be treated as a poweroff
<h3><a name="elementsDevices">Devices</a></h3>
<p>
- The final set of XML elements are all used to descibe devices
+ The final set of XML elements are all used to describe devices
provided to the guest domain. All devices occur as children
of the main <code>devices</code> element.
<span class="since">Since 0.1.3</span>
<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 guarenteed to map to
+ 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
<dl>
<dt><code>input</code></dt>
- <dd>The <code>input</code> element has one madatory attribute, the <code>type</code>
+ <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.
<p>
NB special case if <console type='pty'>, then the TTY
- path is also duplicated as an attribute tty='/dv/pts/3'
+ path is also duplicated as an attribute tty='/dev/pts/3'
on the top level <console> tag. This provides compat
with existing syntax for <console> tags.
</p>
The character device is passed through to the underlying
physical character device. The device types must match,
eg the emulated serial port should only be connected to
- a host serial port - dont connect a serial port to a parallel
+ a host serial port - don't connect a serial port to a parallel
port.
</p>
<h2>Presentation</h2>
<p>The Java bindings are currently a work in progress based mostly
on the work of Toth Istvan. The first usable release is 0.2.0, where
-most of the naming conventions were defined. Futher release will try
+most of the naming conventions were defined. Further release will try
as much as possible to stay compatible</p>
<h2>Getting it</h2>
<p>
<h2>Presentation</h2>
<p>The Java bindings are currently a work in progress based mostly
on the work of Toth Istvan. The first usable release is 0.2.0, where
-most of the naming conventions were defined. Futher release will try
+most of the naming conventions were defined. Further release will try
as much as possible to stay compatible</p>
<h2>Getting it</h2>
projects / thirdparty / libvirt.git / commitdiff
