| Table of Contents |
|---|
Introduction
If it should become necessary to expand the storage space for the partition at the /data mount point, the following set of instructions should help you to perform that change with minimal NMIS downtime.
Generally you should only be needing to resize the partiton at the /data mount point on an NMIS VM as this partition contains the following directories:
- nmis9/
- database/
- var/
- backups
- omk/
- var/
- mongo/
- ( mongo/ is the directory set as the storage.dbPath set in /etc/mongod.conf )
Determine whether the VMs' partitions are using LVM
First, determine whether the NMIS VM is using LVM:
...
If
...
the
...
sudo
...
lsblk
...
command
...
produces
...
partition
...
entries
...
in
...
the
...
TYPE
...
column
...
of type lvm
...
,
...
then
...
that
...
partition
...
is
...
using
...
LVM.
...
In the example command below, using a recent release of the NMIS VM that does not use LVM, we have disks /dev/sda
...
and
...
/dev/sdb.
...
/dev/sda
...
has
...
partitions
...
/dev/sda1
...
to
...
/dev/sda4
...
and
...
all
...
partitions
...
are TYPE part
/dev/sdb has partition /dev/sdb1 of TYPE part
| Code Block |
|---|
of TYPE part [root@omk-vm9-centos7-20210806-stage-test ~]# sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 120G 0 disk ├─sda1 8:1 0 1G 0 part /boot ├─sda2 8:2 0 15G 0 part / ├─sda3 8:3 0 1G 0 part [SWAP] └─sda4 8:4 0 103G 0 part /var sdb 8:16 0 120G 0 disk └─sdb1 8:17 0 120G 0 part /data |
If your NMIS VM is using partitions of type lvm, then proceed to the paragraph below NMIS VMs' using LVM
Otherwise, continue with the next paragraph NMIS VMs' using Traditional Disk Partitions
NMIS VMs' using Traditional Disk Partitions
First Step, determine the current state
| Code Block |
|---|
df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 17M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/sda2 15G 6.1G 7.8G 44% / /dev/sda4 23G 805M 21G 4% /var /dev/sda1 976M 95M 815M 11% /boot /dev/sdb1 40G 8.5G 29G 23% /data tmpfs 783M 0 783M 0% /run/user/0 tmpfs 783M 0 783M 0% /run/user/1000 |
df -h command returns this information for /data partition:
Partition: /dev/sdb1
Partition Size: 40G
Partition Used: 8.5G
Partition Available: 29G
Partition Used %: 23%
Partition Mount Point: /data
It is recommended that you rerun the df -h command at the end to verify that the resizing has worked.
Second Step, Resize Storage Hardware
At this point it'll be simplest to open your vmware client, resize the VM's disk 2 to the desired new size and then reboot the VM to make it pick up the size change.
If you would like to avoid any downtime and not reboot, that's also possible if your virtualisation system allows adding or resizing disks "on the go": Virtualbox doesn't allow that, Vmware does. Please note that Vmware doesn't let you resize disks if there are any snapshots present; if that is the case, then these snapshots must be removed before the resize can occur.
Third Step, Informing the OS and resizing the file system
Install growpart:
| Code Block |
|---|
# centos|rhel
sudo yum install -y cloud-utils-growpart# debian|ubuntu
sudo apt install cloud-guest-utils |
Grow the partition at the /data mount point, which we now know from the df -h commands above is /dev/sdb1:
| Code Block |
|---|
sudo growpart /dev/sdb 1
CHANGED: partition=1 start=2048 old: size=83884032 end=83886080 new: size=251656159 end=251658207 |
NMIS VMs' using LVM
The resizing procedure is quite simple, for size increases at least. The two required steps are:
...
This is possible because the Opmantek Virtual appliance makes use of Linux's excellent LVM support (Logical Volume Management, described in more details here).
First Step, determine the current state
login as as root to the VM and run
...
/data is the filesystem on top of the logical volume, which has a size of 99GB (plus spare change), of which 39BG are used. It is recommended that you rerun these commands at the end to verify that the resizing has worked.
Second Step, Resize Storage Hardware
At this point it'll be simplest to open your vmware client, resize the VM's disk 2 to the desired new size and then reboot the VM to make it pick up the size change.
...
In many cases it will be simpler to add another 'disk' to the system rather than resizing either of the existing 'disks'.
Third Step, Informing the OS and resizing the file system
When the VM boots the newly resized disk 2 (aka /dev/sdb) will be detected but volume group and logical volume still need to be told about the change of 'hardware'.
...