Rhel 6.10 virtualize on vmware

I tried to find this using rename mount point and change mount point name. Neither pulled up anything that seemed relevant.

I have a server setup previously buy a different admin. I need to add space, normally I would add space and then add it to the lvm. This was not setup that way, the drive is raw linux, and it has a partition after it so I can't just add space in vmware and resize the partition.
So, what I am going to do is create a new lvm and copy the data to it.

What I would like to do is rename the mount point that has the data on it, example /dev/sda2/u01 and change it to something like /dev/sda2/u01old, or something like that. Make the appropriate change in fstab.

Then make the new lvm, create the new mount point: /dev/vg_u01/lv_u01/u01, add fstab entry.
Then copy the data from old to new mount point.

First off, is this viable? Seems to me it should be fairly easy to do. Would I just basically do this:
umount /u01
mv /u01 /u01old
mount /dev/sda2 /u01old
Then appropriate fstab change.

Would that do it?

I'd like to rename the point, before copying data; instead of doing it afterwards.
I have a snapshot of this server, so if it goes south, I can easily restore it.

Thanks

Why bother changing the DEVICE name, /dev/sda2/u01? Just unmmount it from /u01 then mount it as /u01old after you create that /u01old directory. You can then mount your new LV on /u01. After both are mounted you copy all the files from /u01old into your new /u01.

That is to say there is no requirement that device name and mount point (directory) name be the same.

Also since you're talking about an LV having u01 in its name won't interfere with the separate partition with u01 in its name.

Well, 1 snag I forgot to mention is that to umount, I have to remove the fstab entry and reboot. Otherwise it won't unmount unless I do a lazy and then it loses data. I don't know if that changes anything, but if not, then I should still just be able to remount as mount /dev/sdb2 /u01old instead of /u01, I assume?

If /u01 is busy you're correct you can't unmount it. You wouldn't want to do a lazy or force unmount as it might cause whatever has it busied out to fail. If you run "lsof /u01" it should show what PIDs are busying it out then you can use ps to see what those PIDs are. If they are something safe to stop you wouldn't need to reboot - you'd just stop them. (Don't do a "kill -9" - find out what started them and stop them.) If not safe to stop then yes you'd have to reboot to stop those processes and unmount the filesystem automatically.

You also don't need to reboot to modify /etc/fstab. It is only consulted during mount operations. If you can stop the processes safely above you can do the modify of fstab then unmount the old and mount the new LV as /u01. If you have to do a reboot to stop the processes you can do the modification of fstab before the reboot so it will automatically mount the old as /u01old and the new LV as /u01 during the boot.

That's all great info. I've tried to lsof and kill the process, still didn't work, so I'll have to modify fstab and do things that way.
Thanks!

Why isn't this all being done from a liveCD booted into the guest ?. That way you don't get issues with in-use filesystems.
All this is way too complicated for the task at hand. Personally I'd just create a lv and copy the (biggest) data over - leave the system side of things alone.
Applications don't (shouldn't) care where the data are, they simply use the mountpoint - after you've moved the data then fix fstab to point to it. You can remove the original data at your leisure to free up the space.

Not sure what application(s) are using that mount point so I'll be `generic'. (Looks like a traditional Oracle `OFA' mount point to me, though.)

I'd:

• # wall "Hey I'm stopping applications for filesystem work."
• Stop application(s). I would not use kill(1) to do this. Stop any services using files on /u01 by using the correct method, either systemctl or the SysV init script(s).
• # mkdir /u01old
• # umount /u01
• # mount /dev/"old-device" /u01old
• # mount /dev/"new-device" /u01
• Copy data from /u01old to /u01 being mindful of file ownership and permissions. There a number of tools you could use for this. (I'm partial to cpio(1) but whatever works for you.)
• Restart application(s)
• # wall "Applications are back up. Please test."

Then, once someone has tested and verified that the application(s) are working, you can delete the old data files under /u01old.

HTH...