Differences

This shows you the differences between two versions of the page.

--- quickreference:lvm2 [2020/08/18 13:33] – rodolico
+++ quickreference:lvm2 [2023/10/15 00:11] (current) – [Testing a change with ability to revert] rodolico
@@ Line 13: / Line 13: @@
 At this point, you can create a vg (Volume Group) using the pv. We'll call it "vg0".
-<code bash>lvcreate vg0 /dev/md0</code>
+<code bash>vgcreate vg0 /dev/md0</code>
 Now, you have a volume group "vg0" which has all of the storage available on the physical volume /dev/md0 (well, with a little overhead subtracted). Now, let's say you want to allocate 10G of storage for some testing. We'll call it "testing".
@@ Line 24: / Line 24: @@
 fdisk /dev/vg0/testing
 mkfs.ext4 -m 0 -L testing /dev/vg0/testing
+</code>
+===== Make it Stop =====
+Well, lvm really, really wants to make sure your stuff is there, even it the underlying volume is renamed, or even reformatted. Even after you remove the lv's, the vg's and the pv's, sometimes you still can not get it to do anything
+<code bash>
+# sometimes helpful to remove the dm's first, but not always necessary
+dmsetup ls
+dmsetup remove <name>
+# now, tell it to release the lv's. If you do not specify a path
+# releases everything
+lvchange -an <lvpath>
+vgchange -an <vgname>
 </code>
@@ Line 112: / Line 126: @@
   - You can view how "full" the snapshot is with the command<code>lvs</code>
   - Make your changes. For example, if your snapshot is of a Xen virtual, start the virtual back up and make the system changes.
-  - Clean up.
   - If you have problems with the existing system, revert to the original
-  - Shut down any processes accessing the original volume (ie, shut down a xen virtual, or unmount a partition)
+    - Shut down any processes accessing the original volume (ie, shut down a xen virtual, or unmount a partition)
-  - Revert the original with the command<code bash>lvconvert --merge /dev/vg0/snap.virt</code>
+    - Revert the original with the command<code bash>lvconvert --merge /dev/vg0/snap.virt</code>
     - The parameter is the path to the snapshot. This will take all changes to the original and put them back in, then it will automatically delete the snapshot.
   - If you had no problems and want the machine in the new state permanently, remove the snapshot with<code bash>lvremove /dev/vg0/snap.virt</code>
     - be sure you don't delete the wrong one, that is why I precede snapshots with "snap"
-    - Please note: running an LV with a snapshot decreases efficiency. Any writes to the original generate a write to the snapshot, so you are decreasing disk access speed greatly. Don't leave spare snapshots laying around past the time you need them,
+    - Please note: running an LV with a snapshot decreases efficiency. Many (most?) writes to the original generate a write to the snapshot, so you are decreasing disk access speed greatly. Don't leave spare snapshots laying around past the time you need them,
@@ Line 127: / Line 140: @@
 ==== System ====
-  - Xen hvml
+  * Xen hvm
-  - Physical volume for DOMU (hvm) is an LVM partition exported as a device (full disk). We'll call this /dev/virtuals/my_domu-disk1 in the following example. This is from the DOM0's perspective. It is 50G and we want it to become 100G, with all that space available to the DOMU.
+  * Physical volume for DOMU (hvm) is an LVM partition exported as a device (full disk). We'll call this /dev/virtuals/my_domu-disk1 in the following example. This is from the DOM0's perspective. It is 50G and we want it to become 100G, with all that space available to the DOMU.
-  - One or more partitions on the exported device has been set as a pv (Physical volume) from within the DOM. Yes, we're talking about an LVM running on top of an LVM. We'll call this /dev/xvdb1, and it is from the DOMU's perspective.
+  * One or more partitions on the exported device has been set as a pv (Physical volume) from within the DOM. Yes, we're talking about an LVM running on top of an LVM. We'll call this /dev/xvdb1, and it is from the DOMU's perspective.
-  - The partition used for the pv is the last one in the exported device. If this is NOT the case, stop now and figure out something else.
+  * The partition used for the pv is the last one in the exported device. If this is NOT the case, stop now and figure out something else.
 ==== Solution ====
   - Shut down the DOMU
-  - <code bash>lvresize -L 100G /dev/virtuals/my_domu-disk1li></code>
+  - Increase LV to the size you want. This sets it to 100G<code bash>lvresize -L 100G /dev/virtuals/my_domu-disk1</code>
-  - <code bash>fdisk /dev/virtuals/my_domu-disk1<code>
+  - Manually edit partition table to "grow" the partition. NOTE: I'm lazy, so I use the bootable [[https://gparted.sourceforge.io/|gparted Live ISO]] most of the time, but this is how you do it manually
-  - use the "p" command to see what the partition number and type is and, most importantly, what its starting cylinder/sector/whatever is. You must record this info. If it is bootable (unlikely), you will need that also.
+    - <code bash>fdisk /dev/virtuals/my_domu-disk1</code>
+    - use the "p" command to see what the partition number and type is and, most importantly, what its starting cylinder/sector/whatever is. You must record this info. If it is bootable (unlikely), you will need that also.
     - use the "d" command to delete the partition.
     - use the "n" command to create a new partition.
@@ Line 143: / Line 157: @@
     - Let the ending cylinder/whatver be the default, ie the rest of the available space
     - use the "p" command again to ensure the partition is an exact duplicate of what it was, except the ending location/size should now be greater
-    - use the "w" command to write the changes to disk. You will most likely get an error that the partition table has not been updated in the kernel, but you can safely ignore that. If you don't want to ignore it, run the following command to force a reread, but since we don't care if the DOM0 knows about the change, I generally ignore this.
+    - use the "w" command to write the changes to disk. You will most likely get an error that the partition table has not been updated in the kernel, but you can safely ignore that. If you don't want to ignore it, run the following command to force a reread, but since we don't care if the DOM0 knows about the change, I generally ignore this.<code>kpartx -lv /dev/virtuals/my_domu-disk</code>
-  - <code>kpartx -lv /dev/virtuals/my_domu-disk</code>
   - Start the DOMU and log into it
   - vgs # so we can see what we had