How to mount an old disk back to the RHEL VM without reboot?

Question

Background

I have added a second hard disk (500GB) to this RHEL VM. And then format, created volume group (storerhel2) and logical volume (store) for it. I then mounted it to a newly created directory (/newStore). It showed as under sdb. Everything worked fine.

lsblk -f
sdb
└─sdb1 LVM2_member tcsmci-DJhs-19V8-UrKR-SOkI-hE1L-TuCqg3
└─storerhel2-store xfs eec69c87-8dd5-46c1-b402-1efe67d0489b /newStore

dmesg | grep sg | grep -i attached
[ 29.711244] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 29.711471] sd 0:0:1:0: Attached scsi generic sg1 type 0
[ 29.711731] sr 3:0:0:0: Attached scsi generic sg2 type 5

I have then unmounted the disk from the VM, removed the hard disk on ESXi. After that, I re-added it back to the VM. But this time, it showed that the hard disk was under sdc instead of sdb. Also, the volume group was not recognized.

lsblk -f
sdc
└─sdc1 LVM2_member tcsmci-DJhs-19V8-UrKR-SOkI-hE1L-TuCqg3

dmesg | grep sg | grep -i attached
[ 29.711244] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 29.711471] sd 0:0:1:0: Attached scsi generic sg1 type 0
[ 29.711731] sr 3:0:0:0: Attached scsi generic sg2 type 5
[ 675.053285] sd 0:0:1:0: Attached scsi generic sg1 type 0

When I tried to mount it again to the original directory, it showed error.

mount /dev/mapper/storerhel2-store /newStore
mount: /dev/mapper/storerhel2-store: can't read superblock

However, when I rebooted it, the hard disk was successfully mounted again as it was written in fstab.

cat /etc/fstab
/dev/mapper/storerhel2-store /newStore xfs inode64,logbsize=256k,noatime,nobarrier 0 0

Question

How do I mount the hard disk again without rebooting the VM? I have tried identifying the scsi devices to rescan the disks (see the links below), same error. Has anyone ever come across the situation?

Please share your knowledge! Thank you!

Reference

https://kerneltalks.com/disk-management/how-to-rescan-disk-in-linux-after-extending-vmware-disk/

https://kerneltalks.com/howto/map-linux-disk-vmware-disk/

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/online_storage_reconfiguration_guide/rescan-scsi-bus

Answer 1

Linux LVM VGs should be deactivated and exported prior to doing work on their member PV disks. Unmounting a file system is not sufficient, there's a layer in between these.

For completeness, it is possible to migrate data from one PV to another while leaving the VG online. Storage migration things. Setting that aside for now, I'll assume this is the simpler case of off lining storage and detaching disks.

Reference LVM procedures under the use case of moving a VG to another system. Which will include:

umount
vgchange -an
vgexport

Then once the disks are back bringing it online involves

vgimport
vgchange -ay
mount

Drive letters like sdb or sdc are not guaranteed to be the same. They are likely to change as paths to the (virtual) storage changes. Instead, reference unique identifiers under /dev/disk/by-id/ such as lvm-pv-uuid or wwn.

---

When making changes to disks, hosts aren't always aware of them immediately. That rescan-scsi-bus.sh script you cited covers all sorts of ways to poke Linux to look at its storage busses again without rebooting. Use as is, or read its source code to appreciate people's one liners for doing this task.

Some storage drivers are hypervisor aware, and do away with traditional SCSI interface. And so reflect disk changes (often resizes) immediately. vmw_pvscsi is VMware's Linux disk driver, any modern server distro should have it, but perhaps confirm that while you are working on the disks of this guest.