buildsys: switch upload dist over to buster

[pve-docs.git] / local-lvm.adoc

diff --git a/local-lvm.adoc b/local-lvm.adoc
index 999b7bc958abad7aacad881490aa00f491b47e0d..2489b9d140d83b7c036ccaf4762986a6a43568d1 100644 (file)
--- a/local-lvm.adoc
+++ b/local-lvm.adoc
@@ -1,12 +1,15 @@
+[[chapter_lvm]]
 Logical Volume Manager (LVM)
 ----------------------------
-include::attributes.txt[]
+ifdef::wiki[]
+:pve-toplevel:
+endif::wiki[]
 
 Most people install {pve} directly on a local disk. The {pve}
 installation CD offers several options for local disk management, and
 the current default setup uses LVM. The installer let you select a
 single disk for such setup, and uses that disk as physical volume for
-the **V**olume **G**roup (VG) 'pve'. The following output is from a
+the **V**olume **G**roup (VG) `pve`. The following output is from a
 test installation using a small 8GB disk:
 
 ----
@@ -30,7 +33,7 @@ VG:
   swap pve  -wi-ao---- 896.00m     
 ----
 
-root:: Formatted as 'ext4', and contains the operation system.
+root:: Formatted as `ext4`, and contains the operation system.
 
 swap:: Swap partition
 
@@ -38,3 +41,98 @@ data:: This volume uses LVM-thin, and is used to store VM
 images. LVM-thin is preferable for this task, because it offers
 efficient support for snapshots and clones.
 
+For {pve} versions up to 4.1, the installer creates a standard logical
+volume called ``data'', which is mounted at `/var/lib/vz`.
+
+Starting from version 4.2, the logical volume ``data'' is a LVM-thin pool,
+used to store block based guest images, and `/var/lib/vz` is simply a
+directory on the root file system.
+
+Hardware
+~~~~~~~~
+
+We highly recommend to use a hardware RAID controller (with BBU) for
+such setups. This increases performance, provides redundancy, and make
+disk replacements easier (hot-pluggable).
+
+LVM itself does not need any special hardware, and memory requirements
+are very low.
+
+
+Bootloader
+~~~~~~~~~~
+
+We install two boot loaders by default. The first partition contains
+the standard GRUB boot loader. The second partition is an **E**FI **S**ystem
+**P**artition (ESP), which makes it possible to boot on EFI systems.
+
+
+Creating a Volume Group
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Let's assume we have an empty disk `/dev/sdb`, onto which we want to
+create a volume group named ``vmdata''.
+
+CAUTION: Please note that the following commands will destroy all
+existing data on `/dev/sdb`.
+
+First create a partition.
+
+ # sgdisk -N 1 /dev/sdb
+
+
+Create a **P**hysical **V**olume (PV) without confirmation and 250K
+metadatasize.
+
+ # pvcreate --metadatasize 250k -y -ff /dev/sdb1
+
+
+Create a volume group named ``vmdata'' on `/dev/sdb1`
+
+ # vgcreate vmdata /dev/sdb1
+
+
+Creating an extra LV for `/var/lib/vz`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This can be easily done by creating a new thin LV.
+
+ # lvcreate -n <Name> -V <Size[M,G,T]> <VG>/<LVThin_pool>
+
+A real world example:
+
+ # lvcreate -n vz -V 10G pve/data
+
+Now a filesystem must be created on the LV.
+
+ # mkfs.ext4 /dev/pve/vz
+
+At last this has to be mounted.
+
+WARNING: be sure that `/var/lib/vz` is empty. On a default
+installation it's not.
+
+To make it always accessible add the following line in `/etc/fstab`.
+
+ # echo '/dev/pve/vz /var/lib/vz ext4 defaults 0 2' >> /etc/fstab
+
+
+Resizing the thin pool
+~~~~~~~~~~~~~~~~~~~~~~
+
+Resize the LV and the metadata pool can be achieved with the following
+command.
+
+ # lvresize --size +<size[\M,G,T]> --poolmetadatasize +<size[\M,G]> <VG>/<LVThin_pool>
+
+NOTE: When extending the data pool, the metadata pool must also be
+extended.
+
+
+Create a LVM-thin pool
+~~~~~~~~~~~~~~~~~~~~~~
+
+A thin pool has to be created on top of a volume group.
+How to create a volume group see Section LVM.
+
+ # lvcreate -L 80G -T -n vmstore vmdata