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
`<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>`::
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.
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[]
----
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')
====
Common Storage Properties
~~~~~~~~~~~~~~~~~~~~~~~~~
-A few storage properties are common among differenty storage types.
+A few storage properties are common among different storage types.
nodes::
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:::
rootdir:::
-Allow to store Container data.
+Allow to store container data.
vztmpl:::
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:
`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.
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>
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.
`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
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
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
-------
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
# 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
projects / pve-docs.git / commitdiff