Editorial changes

spelling, grammer, typos and other editorial changes
This commit is contained in:
Fabian Grünbichler 2016-03-14 13:46:28 +01:00
parent 43da832202
commit 871e1fd656
5 changed files with 37 additions and 37 deletions

View File

@ -14,16 +14,16 @@ can use any file system supported by Linux.
This backend assumes that the underlying directory is POSIX
compatible, but nothing else. This implies that you cannot create
snapshots at the storage level. But there exists a woraround for VM
snapshots at the storage level. But there exists a workaround for VM
images using the `qcow2` file format, because that format supports
snapshots internally.
TIP: Some storage types does not support `O_DIRECT`, so you can't use
TIP: Some storage types do not support `O_DIRECT`, so you can't use
cache mode `none` with such storages. Simply use cache mode
`writeback` instead.
We use a predefined directory layout to store different content types
into different sub-directories. This layout is use by all file level
into different sub-directories. This layout is used by all file level
storage backends.
.Directory layout
@ -69,8 +69,8 @@ This specifies the owner VM.
`<NAME>`::
This scan be an arbitrary name (`ascii`) without white spaces. The
backend uses `disk[N]` as default, where `[N]` is replaced by an
This can be an arbitrary name (`ascii`) without white spaces. The
backend uses `disk-[N]` as default, where `[N]` is replaced by an
integer to make the name unique.
`<FORMAT>`::
@ -78,19 +78,19 @@ integer to make the name unique.
Species the image format (`raw|qcow2|vmdk`).
When you create a VM template, all VM images are renamed to indicate
that they are now read-only, and can be uses as base image for clones:
that they are now read-only, and can be uses as a base image for clones:
base-<VMID>-<NAME>.<FORMAT>
NOTE: Such base images are used to generate cloned images. So it is
important that those files are read-only, and never gets modified. The
backend changes access mode to `0444`, and sets the immutable flag
important that those files are read-only, and never get modified. The
backend changes the access mode to `0444`, and sets the immutable flag
(`chattr +i`) if the storage supports that.
Storage Features
~~~~~~~~~~~~~~~~
As mentioned above, most file systems does not support snapshots out
As mentioned above, most file systems do not support snapshots out
of the box. To workaround that problem, this backend is able to use
`qcow2` internal snapshot capabilities.

View File

@ -24,7 +24,7 @@ Container Images
include::attributes.txt[]
endif::manvolnum[]
Command line tool to manage comtainer images. See 'man pct' for usage
Command line tool to manage container images. See 'man pct' for usage
examples.
ifdef::manvolnum[]

View File

@ -110,12 +110,12 @@ Each storage pool has a `<type>`, and is uniquely identified by its `<STORAGE_ID
----
NOTE: There is one special local storage pool named `local`. It refers to
directory '/var/lib/vz' and is automatically generated at installation
the directory '/var/lib/vz' and is automatically generated at installation
time.
The `<type>: <STORAGE_ID>` line starts the pool definition, which is then
followed by a list of properties. Most properties have values, but some of them comes
with reasonable default. In that case you can omit the value.
followed by a list of properties. Most properties have values, but some of
them come with reasonable default. In that case you can omit the value.
.Default storage configuration ('/etc/pve/storage.cfg')
====
@ -128,7 +128,7 @@ with reasonable default. In that case you can omit the value.
Common Storage Properties
~~~~~~~~~~~~~~~~~~~~~~~~~
A few storage properties are common among differenty storage types.
A few storage properties are common among different storage types.
nodes::
@ -140,7 +140,7 @@ content::
A storage can support several content types, for example virtual disk
images, cdrom iso images, container templates or container root
directories. Not all storage types supports all content types. One can set
directories. Not all storage types support all content types. One can set
this property to select for what this storage is used for.
images:::
@ -149,7 +149,7 @@ KVM-Qemu VM images.
rootdir:::
Allow to store Container data.
Allow to store container data.
vztmpl:::
@ -181,16 +181,16 @@ Default image format (`raw|qcow2|vmdk`)
WARNING: It is not advisable to use the same storage pool on different
{pve} clusters. Some storage operation needs exclusive access to the
{pve} clusters. Some storage operation need exclusive access to the
storage, so proper locking is required. While this is implemented
within an cluster, it does not work between different clusters.
within a cluster, it does not work between different clusters.
Volumes
-------
We use a special notation to address storage data. When you allocate
data from a storage pool, it returns such volume identifier. A volume
data from a storage pool, it returns such a volume identifier. A volume
is identified by the `<STORAGE_ID>`, followed by a storage type
dependent volume name, separated by colon. A valid `<VOLUME_ID>` looks
like:
@ -215,15 +215,15 @@ volume is owned by a VM or Container. For example volume
`local:230/example-image.raw` is owned by VM 230. Most storage
backends encodes this ownership information into the volume name.
When you remove a VM or Container, the system also remove all
When you remove a VM or Container, the system also removes all
associated volumes which are owned by that VM or Container.
Using the Command Line Interface
--------------------------------
I think it is required to understand the concept behind storage pools
and volume identifier, but in real life, you are not forced to do any
It is recommended to familiarize yourself with the concept behind storage
pools and volume identifiers, but in real life, you are not forced to do any
of those low level operations on the command line. Normally,
allocation and removal of volumes is done by the VM and Container
management tools.

10
qm.adoc
View File

@ -40,18 +40,18 @@ All configuration files consists of lines in the form
See 'man vm.conf' for a complete list of options.
Configuration files are stored inside the Proxmox configuration file
Configuration files are stored inside the Proxmox cluster file
system, and can be access at '/etc/pve/qemu-server/<VMID>.conf'.
The default for option `keyboard` is read from
The default for the `keyboard` option is read from
'/etc/pve/datacenter.conf'.
Locks
-----
Online migration and backups ('vzdump') set a lock to prevent
unintentional action on such VMs. Sometimes you need remove such lock
manually (power failure).
Online migrations and backups ('vzdump') set a lock to prevent incompatible
concurrent actions on the affected VMs. Sometimes you need to remove such a
lock manually (e.g., after a power failure).
qm unlock <vmid>

View File

@ -25,7 +25,7 @@ Backup and Restore
include::attributes.txt[]
endif::manvolnum[]
'vzdump' is an utility to make consistent snapshots of running virtual
'vzdump' is a utility to make consistent snapshots of running virtual
machines (VMs). It basically creates an archive of the VM private
area, which also includes the VM configuration files. 'vzdump'
currently supports LXC containers and QemuServer VMs.
@ -38,10 +38,10 @@ Stop the VM during backup. This results in a very long downtime.
`suspend` mode::
For containers, this mode uses rsync to copy the VM to a temporary
For containers, this mode uses rsync to copy the VM data to a temporary
location (see option `--tmpdir`). Then the VM is suspended and a second
rsync copies changed files. After that, the VM is started (resume)
again. This results in a minimal downtime, but needs additional space
rsync copies changed files. After that, the VM is started (resumed)
again. This results in minimal downtime, but needs additional space
to hold the VM copy.
For QemuServer, this mode will suspend the VM, start
@ -54,7 +54,7 @@ underlying storage. A snapshot will be made of the container volume,
and the snapshot content will be archived in a tar file.
For QemuServer, this mode will do a live backup similar to the
`snaphost` mode, but without suspending/resuming the VM.
`suspend` mode, but without suspending/resuming the VM.
A technical overview of the Proxmox VE live backup for QemuServer can
be found online
@ -63,14 +63,14 @@ https://git.proxmox.com/?p=pve-qemu-kvm.git;a=blob;f=backup.txt[here],
Backup File Names
-----------------
Newer version of vzdump encodes the virtual machine type and the
Newer versions of vzdump encode the virtual machine type and the
backup time into the filename, for example
vzdump-lxc-105-2009_10_09-11_04_43.tar
That way it is possible to store several backup into the same
That way it is possible to store several backup in the same
directory. The parameter `maxfiles` can be used to specify the
maximal number of backups to keep.
maximum number of backups to keep.
Restore
-------
@ -78,7 +78,7 @@ Restore
The resulting archive files can be restored with the following programs.
`pct restore`:: Containers restore utility
`pct restore`:: Container restore utility
`qmrestore`:: QemuServer restore utility
@ -139,7 +139,7 @@ configuration files to the default dump directory (usually
# vzdump 777
Use rsync and suspend/resume to create an snapshot (minimal downtime).
Use rsync and suspend/resume to create a snapshot (minimal downtime).
# vzdump 777 --mode suspend