Skip to main content

Tag: lvm

Resize vps disk in an automated way

sysadmin Leave a comment

This is the commands I run to resize automatically the VPS disks when I have resized the disk through Proxmox interface.

#!/bin/bash

# This is only needed if you use GPT type tables
echo "Fix" | /usr/local/sbin/parted  ---pretend-input-tty /dev/sdb print
# Resize partition 1 using all the space
/usr/local/sbin/parted /dev/sdb resizepart 1 100%
#  I use LVM so the physical volume must be resized first
pvresize /dev/sdb1
# Resize the logical volume using all space available
lvresize /dev/vgdata/home -l +100%FREE
# Finally notify file system to use all the space
resize2fs /dev/vgdata/home

Note: I use parted 3.2, if your distribution comes with an older one uninstall it and install it from sources

Removing multipath device – map in use

sysadmin 1 Comment

I got in trouble when I tried to remove a multipath device from my servers. This device is on top on some lvm volumes that I am not using it any longer. I tried to remove with multipath -f, but it was not possible, it said that the map was in use:

~# multipath -f /dev/mapper/2554b454e79496758
Dec 05 12:22:31 | 2554b454e79496758: map in use
Dec 05 12:22:31 | failed to remove multipath map 2554b454e79496758

You can view how many processes are using this map with the dmsetup tool, see the open count field:

~# dmsetup info  /dev/mapper/2554b454e79496758
Name:              2554b454e79496758
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        4
Event number:      1086846
Major, minor:      251, 4
Number of targets: 1
UUID: mpath-2554b454e79496758

First remove any LVM active devices on this device, ex: if you have a volume group “vggroup” and a lvm “vol1” on this device remove them:

~# lvremove /dev/vggroup/vol1
~# vgremove vggroup
~# pvremove /dev/mapper/2554b454e79496758

and if the device file is still mapped under /dev remove it:

~# dmsetup remove /dev/vggroup/*

At this point there shouldn’t be any processes accessing this device and we should be able to remove it with the command above, but it some cases there are still processes blocked waiting for the device. We can try to find out which processes are with lsoft command filtering by device mayor and minor number:

~# lsof | grep "251,4"

In my case there was some vgs processes blocked trying to access the device. We cannot kill these processes, because they are already waiting for a signal from the kernel.

~# ps aux | grep sbin/vgs
root     1206972  0.0  0.0  32444  4288 ?        D    dic02   0:00 /sbin/vgs --separator : --noheadings --units b --unbuffered --nosuffix --options vg_name,vg_size,vg_free
root     1213321  0.0  0.0  32444  4308 ?        D    dic02   0:00 /sbin/vgs --separator : --noheadings --units b --unbuffered --nosuffix --options vg_name,vg_size,vg_free
root     1248170  0.0  0.0  32444  4196 ?        D    dic02   0:00 /sbin/vgs --separator : --noheadings --units b --unbuffered --nosuffix --options vg_name,vg_size,vg_free
root     2542017  0.0  0.0  32444  4252 ?        D    10:46   0:00 /sbin/vgs --separator : --noheadings --units b --unbuffered --nosuffix --options vg_name,vg_size,vg_free

We can try to suspend the multipath device to force timeout to the processes:

~# dmsetup suspend /dev/mapper/2554b454e79496758
~# dmsetup info /dev/mapper/2554b454e79496758
Name:              2554b454e79496758
State:             SUSPENDED
Read Ahead:        256
Tables present:    LIVE
Open count:        4
Event number:      1086846
Major, minor:      251, 4
Number of targets: 1
UUID: mpath-2554b454e79496758

And try to clear the device table:

~# dmsetup clear  /dev/mapper/2554b454e79496758
~# dmsetup wipe_table  /dev/mapper/2554b454e79496758

We are lucky and finally the device is not in use any longer:

~# dmsetup info  /dev/mapper/2554b454e79496758
Name:              2554b454e79496758
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        0
Event number:      1086846
Major, minor:      251, 7
Number of targets: 1
UUID: mpath-2554b454e79496758

Now, we can remove it without problems:

~# mutipath -f  /dev/mapper/2554b454e79496758

To avoid multipath rediscover the device again we can blacklist it. Remove device from already discovered devices:

~# sed -i '/2554b454e79496758/d' /etc/multipath/wwids

In the multipath configuration file add an entry in the blacklist section withe the wwid of the deivce, if the file does not exist create it:
/etc/multipath.conf

blacklist {
   wwid 2554b454e79496758
}

And finally reload multipath:

~# systemctl reload multipath-tools

LVM Recovering Physical Volume Metadata

sysadmin Leave a comment

 

I had to recover LVM metadata from one physical volume and here are the steps I followed.  I am not sure why I got this situation, I’ve used LVM for a long time and this is the only one that I have to recover the metadata. The physical volume was backed by ISCSI lun.

Running pvdisplay command showed as no LVM volume:

$ sudo  pvdisplay /dev/mapper/26a326a6471427270
No physical volume label read from /dev/mapper/26a326a6471427270
Failed to read physical volume "/dev/mapper/26a326a6471427270"

 

ISCSI session was OK:

$ sudo iscsiadm -m session

tcp: [25] 172.16.68.51:3260,1 iqn.2012-12:backups
tcp: [26] 172.16.68.151:3260,1 iqn.2012-12:backups
tcp: [27] 172.16.64.10:3260,1 iqn.2012-12:backups
tcp: [28] 172.16.66.10:3260,1 iqn.2012-12:backups

 

multipath detected the device paths OK:

26a326a6471427270 dm-11 SCST_BIO,j2jdqBrpZ2sYmXO3
size=13T features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=0 status=active
|- 30:0:0:0 sdaf 65:240 active ready running
|- 28:0:0:0 sdah 66:16 active ready running
|- 29:0:0:0 sdag 66:0 active ready running
`- 31:0:0:0 sdai 66:32 active ready running

 

$ sudo  dmsetup ls --tree
vgsatar6_C02-ovznhshare05 (253:52)
└─26a326a6471427270 (253:11)
├─ (66:32)
├─ (66:0)
├─ (66:16)
└─ (65:240)

 

$ sudo ls -l  /dev/vgsatar6_C02/ovznhshare05

lrwxrwxrwx 1 root root 8 ene 21 17:06 /dev/vgsatar6_C02/ovznhshare05 -> ../dm-52

 

Also the device was mounted and running fine:

$ mount

/dev/mapper/vgsatar6_C02-ovznhshare05 on /var/san/share05 type ext3 (rw,relatime,errors=continue,barrier=0,data=ordered)

But, I was sure that if the server was restarted the device was going to be lost and not mounted again.

The steps to recover the metadata were as follows:

umount the device:

$ sudo umount /var/san/share05

Open your last LVM backup for that VG in /etc/lvm/backup. In my case it was /etc/lvm/backup/vgsatar6_C02

Indentify the UUID for your physical volume in that file:

 

physical_volumes {
  pv0 {
    id = "1Babrx-VzKI-7Yav-9hGp-2KX2-DRgT-zdpAql"
    device = "/dev/mapper/26a326a6471427270" # Hint only

    status = ["ALLOCATABLE"]
    flags = []
    dev_size = 27288010752 # 12,707 Terabytes
    pe_start = 2048
    pe_count = 3331055 # 12,707 Terabytes
  }
}

In my case the Id was “1Babrx-VzKI-7Yav-9hGp-2KX2-DRgT-zdpAql”.

Recreate the physical volume again using the information saved in the backup:

$ sudo pvcreate --uuid "1Babrx-VzKI-7Yav-9hGp-2KX2-DRgT-zdpAql" --restorefile /etc/lvm/backup/vgsatar6_C02 /dev/mapper/26a326a6471427270

 

Restore volume group:

 

$sudo vgcfgrestore vgsatar6_C02

Activate logical volume and mount it again:

 

$ sudo lvchange -ay /dev/vgsatar6_C02/ovznhshare05 
$ sudo mount /dev/vgsatar6_C02/ovznhshare05 /var/san/share05

 

And that’s all, I hope that will help someone.

For more info look at redhat documentation