totp: fix copy/paste mistake

[pve-docs.git] / pmxcfs.adoc

diff --git a/pmxcfs.adoc b/pmxcfs.adoc
index 2c7f04ac35059c3427ea37b5fe225899341c3eda..f4aa847e0ef136172145d21d0af3772358c73a4a 100644 (file)
--- a/pmxcfs.adoc
+++ b/pmxcfs.adoc
@@ -26,13 +26,13 @@ endif::manvolnum[]
 
 The Proxmox Cluster file system (``pmxcfs'') is a database-driven file
 system for storing configuration files, replicated in real time to all
-cluster nodes using `corosync`. We use this to store all PVE related
+cluster nodes using `corosync`. We use this to store all {PVE} related
 configuration files.
 
-Although the file system stores all data inside a persistent database
-on disk, a copy of the data resides in RAM. This imposes restrictions
-on the maximum size, which is currently 30MB. This is still enough to
-store the configuration of several thousand virtual machines.
+Although the file system stores all data inside a persistent database on disk,
+a copy of the data resides in RAM. This imposes restrictions on the maximum
+size, which is currently 128 MiB. This is still enough to store the
+configuration of several thousand virtual machines.
 
 This system provides the following advantages:
 
@@ -106,7 +106,7 @@ Files
 |`ha/resources.cfg`                     | Resources managed by high availability, and their current state
 |`nodes/<NAME>/config`                  | Node-specific configuration
 |`nodes/<NAME>/lxc/<VMID>.conf`         | VM configuration data for LXC containers
-|`nodes/<NAME>/openvz/`                 | Prior to PVE 4.0, used for container configuration data (deprecated, removed soon)
+|`nodes/<NAME>/openvz/`                 | Prior to {pve} 4.0, used for container configuration data (deprecated, removed soon)
 |`nodes/<NAME>/pve-ssl.key`             | Private SSL key for `pve-ssl.pem`
 |`nodes/<NAME>/pve-ssl.pem`             | Public SSL certificate for web server (signed by cluster CA)
 |`nodes/<NAME>/pveproxy-ssl.key`        | Private SSL key for `pveproxy-ssl.pem` (optional)
@@ -226,7 +226,7 @@ For example, recovering the VM with ID `100` from an offline `node1` to another
 node `node2` works by running the following command as root on any member node
 of the cluster:
 
- mv /etc/pve/nodes/node1/qemu-server/100.conf /etc/pve/nodes/node2/
+ mv /etc/pve/nodes/node1/qemu-server/100.conf /etc/pve/nodes/node2/qemu-server/
 
 WARNING: Before manually recovering a guest like this, make absolutely sure
 that the failed source node is really powered off/fenced. Otherwise {pve}'s