Extend the disk space of a virtual appliance

The virtual appliances fill up: recordings, archives, databases and logs accumulate on the partitions that carry them. This page extends one of those partitions so it uses all the space available on the disk — on a Mediation Controller or on an Edge Gateway.

The operation is normally carried out live, with no impact on production.

One condition, and it is not negotiable

The commands below assume the disk layout and the partitioning delivered with the appliance. If the disks or the partitioning of this virtual machine have been modified by hand, they do not apply: they delete and recreate a partition, and they would do so from assumptions that are no longer true. In that case, contact Systancia support rather than adapting the commands yourself.

A single change is tolerated: the one this very procedure has already made. The page is meant to be applied again — an appliance extended this way remains eligible, and each new enlargement of the virtual disk is handed to the partition in the same manner.

Before you start

Go through these four steps in order. The first is the one that makes the rest recoverable.

1. Back up the virtual machine

Take a backup of the virtual machine before anything else. The extension rewrites the partition table: a backup is what turns a failed operation into a restore instead of a reinstallation.

2. Extend the virtual disk from the hypervisor

Add the required space to the appliance's disk, from your hypervisor. This step alone changes nothing inside the machine — the operating system keeps seeing the former size until the commands below are run.

The option is greyed out? Look for a snapshot

A hypervisor refuses to extend the disk of a virtual machine that holds a snapshot. If the option is unavailable, check whether one remains and remove it — then extend the disk.

3. Optionally, take a snapshot

Once the disk is extended, you may take a snapshot of the machine, as an immediate way back for the commands that follow. Take it after the disk extension, never before: a snapshot is precisely what would prevent that extension.

4. Apply the extension inside the appliance

Only then run the commands of the next section.

Which partition to extend

The commands take a directory and extend the partition that carries it. Any directory of the system can be named, with one exception.

/boot is excluded

Do not target /boot. The commands work on the LVM volume of the appliance, which /boot is kept out of. The field below refuses that path.

In practice, two directories per appliance grow faster than the rest — they are the usual reason for running this procedure:

Appliance	Directory	What it holds
Mediation Controller	/var	The data of the Mediation Controller, the database among them.
Mediation Controller	/var/log	The system logs.
Edge Gateway	/var/lib/ipdiva/carerecord/archives	The graphical archives of the recorded sessions.
Edge Gateway	/var/log	The system logs.

Naming a directory, not a partition

You do not need to know which partition or which logical volume carries what: the commands read it from the directory you give them. Run df -h on the appliance to see which one is running out.

Extend the partition

Open an SSH session on the appliance, as root, then run the commands matching it.

You can customize the variable for the following commands:

Custom value	Variable	Comment
	TARGET_DIRECTORY	Directory whose partition is to be extended — see Which partition to extend.

Or fill the field with one of the three directories that saturate first:

/var /var/lib/ipdiva/carerecord/archives /var/log

Mediation ControllerEdge Gateway

directory=TARGET_DIRECTORY

echo 1 > /sys/class/block/sda/device/rescan

start_lvm_partition=`fdisk -l /dev/sda | grep LVM | awk '{print $2}'`
mountpoint=`df $directory | awk 'NR==2 {print $1}'`

echo -e "d\n2\nn\ne\n2\n\n\nn\n$start_lvm_partition\n\nn\nt\n5\n8E\nw" | fdisk /dev/sda

pvresize /dev/sda5
lvresize -l +100%FREE $mountpoint
resize2fs $mountpoint

directory=TARGET_DIRECTORY

echo 1 > /sys/class/block/sda/device/rescan

start_last_lvm_partition=`fdisk -l /dev/sda | grep LVM | awk '{print $2}' | sort -nr | head -n1`
last_lvm_partition=`fdisk -l /dev/sda | grep $start_last_lvm_partition | awk '{print $1}'`
mountpoint=`df $directory | awk 'NR==2 {print $1}'`

echo -e "d\n${last_lvm_partition: -1}\nn\np\n${last_lvm_partition: -1}\n$start_last_lvm_partition\n\nn\nt\n${last_lvm_partition: -1}\n8E\nw" | fdisk /dev/sda

pvresize $last_lvm_partition
lvresize -l +100%FREE $mountpoint
resize2fs $mountpoint

What the commands do

They chain four operations: make the kernel see the new disk size without rebooting, rewrite the last LVM partition so it reaches the end of the disk, hand that space to LVM, then grow the file system onto it. The two variants differ only in the partition layout of each appliance — pick the one matching the machine you are on.

Check the free space before and after

Run df -h on the directory before and after. The gain must match the space added at step 2.

If the file system has not grown, do not run the commands again straight away: the partition table has already been rewritten, and a second pass over the same disk size would start from a state they do not expect. Report the outcome to Systancia support instead.

Running them again is legitimate in one case, and it is the ordinary one: when more space has been added to the virtual disk. Start over at step 1 — the whole procedure applies again, backup included.