From: Atsushi SAKAI
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
- 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
@@ -402,7 +402,7 @@
Devices
- 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
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.
arch
specifying the CPU architecture to virtualization, and machine
- refering to the machine type. The Capabilities XML
+ referring to the machine type. The Capabilities XML
provides details on allowed values for these. Since 0.0.1loaderloader tag refers to a firmware blob
used to assist the domain creation process. At this time, it is
- only needed by Xen fullyvirtualized domains. Since 0.1.0bootdev attribute takes one of the values "fd", "hd",
+ only needed by Xen fully virtualized domains. Since 0.1.0bootdev attribute takes one of the values "fd", "hd",
"cdrom" or "network" and is used to specify the next boot device
to consider. The boot element can be repeated multiple
times to setup a priority list of boot devices to try in turn.
@@ -267,7 +267,7 @@
pygrub with Xen.
bootloaderbootloader 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. Since 0.1.0bootloader_argsbootloader_args element allows
command line arguments to be passed to the bootloader.
Since 0.2.3
@@ -330,7 +330,7 @@
Lifecycle control
devices element.
Since 0.1.3
@@ -446,7 +446,7 @@
type is "block", then the dev attribute specifies
the path to the host device to serve as the disk. Since 0.0.3targettarget element controls the bus / device under which the
disk is exposed to the guest OS. The dev 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 bus attribute specifies the type of disk device
to emulate; possible values are driver specific, with typical values being
@@ -628,7 +628,7 @@
...
<input type='mouse' bus='usb'/>
...
- inputinput element has one madatory attribute, the type
+ inputinput element has one mandatory attribute, the type
whose value can be either 'mouse' or 'tablet'. The latter provides absolute
cursor movement, while the former uses relative movement. The optional
bus attribute can be used to refine the exact device type.
@@ -760,7 +760,7 @@
...
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index cc6473fea2..d4f650e6e1 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -84,12 +84,12 @@ (badly named!) refers to an OS that supports the Xen 3 hypervisor guest ABI. There are also two optional attributes,archspecifying the CPU architecture to virtualization, andmachine- refering to the machine type. The Capabilities XML + referring to the machine type. The Capabilities XML provides details on allowed values for these. Since 0.0.1
loaderloader tag refers to a firmware blob
used to assist the domain creation process. At this time, it is
- only needed by Xen fullyvirtualized domains. Since 0.1.0bootdev attribute takes one of the values "fd", "hd",
"cdrom" or "network" and is used to specify the next boot device
@@ -104,7 +104,7 @@
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 pygrub with Xen.
bootloaderbootloader 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. Since 0.1.0bootloader_argsbootloader_args element allows
@@ -196,7 +196,7 @@
- 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 @@ -301,7 +301,7 @@
- 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 devices element.
Since 0.1.3
@@ -358,7 +358,7 @@
targettarget element controls the bus / device under which the
disk is exposed to the guest OS. The dev 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 bus attribute specifies the type of disk device
to emulate; possible values are driver specific, with typical values being
@@ -557,7 +557,7 @@
inputinput element has one madatory attribute, the type
+ input element has one mandatory attribute, the type
whose value can be either 'mouse' or 'tablet'. The latter provides absolute
cursor movement, while the former uses relative movement. The optional
bus attribute can be used to refine the exact device type.
@@ -716,7 +716,7 @@
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.
@@ -727,7 +727,7 @@ 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. diff --git a/docs/java.html b/docs/java.html index 2b0c15f20a..572e583193 100644 --- a/docs/java.html +++ b/docs/java.html @@ -105,7 +105,7 @@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
diff --git a/docs/java.html.in b/docs/java.html.in index 316070cf35..2d9a24fa12 100644 --- a/docs/java.html.in +++ b/docs/java.html.in @@ -6,7 +6,7 @@
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