Office cabinets in a narrow room

In Red Hat OpenShift version 4, resizing virtual machine disks created through the OpenShift Virtualization Operator is easier than ever. After expanding the persistent volume claim (PVC), the additional space is made available immediately to the virtual machine. Below are some ways to do so in btrfs with the Red Hat provided Fedora image, xfs on the Red Hat Enterprise Linux 8 template, and a custom Microsoft Windows Server 2019 template using a simple ansible playbook to accomplish the task.

 

Note that Red Hat OpenShift Virtualization does not contain images for Microsoft Windows virtual machines, so those will need to be provided by you.

  • The integral part of this process is having the storage class that is associated with the volumes have the allowVolumeExpansion: true field in its configuration, along with having back end storage that supports it.

  • Ansible must be installed and configured on the machine from which you run the playbook. The Ansible Windows module must also be installed on the same machine in order to run the playbook for configuring Windows servers. See here for more information: Ansible Windows Module.

  • Services and Routes will need to be set up in OpenShift to allow access to the virtual machines.

    For the Linux VMs, exposing ssh access during their initial creation is the simplest way to get this up and running.

  • The user accounts performing the resizing on the Linux machines will require sudo access, and on Windows will need to have administrator privileges.

  • Windows Remote Management (WinRM) will need to be configured on the Windows server. Details on Windows Remote Management configuration and usage can be found here: Windows Remote Management.

    Depending on the details specific to your Windows VM and OpenShift installation, use of WinRM will need a service and route to expose ports 5985 for http or 5986 for https.

Volume expansion within a btrfs filesystem

The Fedora image in Red Hat OpenShift 4 Virtualization has a root partition that uses the btrfs file system. Before starting, let's gather some information regarding the virtual machine disks. While logged into the VM, run lsblk to show the disks and partitions, then use sudo btrfs filesystem show to show the btrfs partition. Doing this will give us a greater sense of what we're looking to accomplish during the expansion. See below for examples of the output.

lsblk command output:

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
zram0 251:0 0 7.8G 0 disk [SWAP]
vda 252:0 0 1M 0 disk
vdb 252:16 0 37.8G 0 disk
├─vdb1 252:17 0 1M 0 part
├─vdb2 252:18 0 500M 0 part /boot
├─vdb3 252:19 0 100M 0 part /boot/efi
├─vdb4 252:20 0 4M 0 part
└─vdb5 252:21 0 37.2G 0 part /home
/

btrfs command output:

Label: 'fedora'  uuid: 437a4991-d1ba-4577-b624-48a51910a100
Total devices 1 FS bytes used 1005.85MiB
devid 1 size 37.21GiB used 2.38GiB path /dev/vdb5

In order to resize the PVC on which the virtual disk resides, first find the correct PVC using oc get pvc -n <insert VM namespace here>, and then increase the size using the oc patch command oc patch pvc <PVC name> -p '{"spec": {"resources": {"requests": {"storage": "<new size>"}}}}'. In the example below, we increased the capacity of the PVC to 60Gi.

oc get PVC output before:

NAME                                 CAPACITY    VOLUME
fedora-faint-whale-rootdisk-d49j6 40Gi PVC-cc285d66-56f4-4f4a-8357-6fe1a1550738

oc get PVC output after:

NAME                                 CAPACITY    VOLUME
fedora-faint-whale-rootdisk-d49j6 60Gi PVC-cc285d66-56f4-4f4a-8357-6fe1a1550738

To verify that the expanded PVC is seen by and available to the virtual machine, run the lsblk command once again.

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
zram0 251:0 0 7.8G 0 disk [SWAP]
vda 252:0 0 1M 0 disk
vdb 252:16 0 56.7G 0 disk
├─vdb1 252:17 0 1M 0 part
├─vdb2 252:18 0 500M 0 part /boot
├─vdb3 252:19 0 100M 0 part /boot/efi
├─vdb4 252:20 0 4M 0 part
└─vdb5 252:21 0 37.2G 0 part /home
/

With the resize of the PVC completed, and verification that the added space is available to the virtual machine, we can resize the volume. For the sake of our demonstration, "/home" will be expanded to the maximum available capacity using sudo btrfs filesystem resize 1:max /home. It's possible, but rare, that this will take some time to complete. It will require a reboot for it to show the new size.

btrfs output after the resize and reboot:

Label: 'fedora'  uuid: 437a4991-d1ba-4577-b624-48a51910a100
Total devices 1 FS bytes used 1005.89MiB
devid 1 size 56.11GiB used 2.38GiB path /dev/vdb5

The process is now complete, and you have a greater capacity with which to work.

Volume expansion in the xfs filesystem

Unlike the Fedora image, RHEL 8 comes with a root partition formatted with xfs. The process to resize the persistent volume claim (PVC) is the same as above. The PVC on which the RHEL VM resides will be different, and the resize within the virtual machine will also be different. You are able to use the lsblk command from above to view disk information that is applicable to the current task.

For the purpose of the RHEL 8 task, the PVC started with an initial size of 40Gi and was increased to 60Gi.

Output of the lsblk command before the resize:

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda 252:0 0 1M 0 disk
vdb 252:16 0 40G 0 disk
├─vdb1 252:17 0 1M 0 part
├─vdb2 252:18 0 100M 0 part /boot/efi
└─vdb3 252:19 0 39.9G 0 part /

The output of the same command after resizing:

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda 252:0 0 1M 0 disk
vdb 252:16 0 56.7G 0 disk
├─vdb1 252:17 0 1M 0 part
├─vdb2 252:18 0 100M 0 part /boot/efi
└─vdb3 252:19 0 39.9G 0 part /

After resizing PVC and verifying that the increase is seen by the virtual machine, we can use growpart /dev/vdb 3 to make the additional space available (note that the space after the vdb is needed). If successful, you will see a message stating the partition table was changed.

Output of the growpart command:

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda 252:0 0 1M 0 disk
vdb 252:16 0 56.7G 0 disk
├─vdb1 252:17 0 1M 0 part
├─vdb2 252:18 0 100M 0 part /boot/efi
└─vdb3 252:19 0 56.6G 0 part /

From here we use the command sudo xfs_growfs -d /dev/vdb3 to add in the additional space.

Output of the command df -h with the resized partition:

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs 3.8G 0 3.8G 0% /dev
tmpfs 3.8G 0 3.8G 0% /dev/shm
tmpfs 3.8G 8.6M 3.8G 1% /run
tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup
/dev/vdb3 57G 3.9G 53G 7% /
/dev/vdb2 100M 5.8M 95M 6% /boot/efi
tmpfs 777M 0 777M 0% /run/user/1001

Volume expansion for Microsoft Windows Server

Changing the size of disks in Microsoft Windows Server can be done multiple ways, all of which require the correct Windows account permissions such as administrator access. The process below shows how to do this with an Ansible playbook utilizing some of the Windows diskpart utility commands.

Like our previous expansions, we used the oc patch command to increase the sizes of the PVC. In this example the PVC used began with an initial size of 60Gi and was increased to 100Gi.

When you create a virtual machine in Red Hat OpenShift Virtualization, you are able to expose ssh for Windows machines as well. The process of enabling it is impartial to the OS, but when you are using Windows Server you must install an ssh service to connect to the machine. Luckily, Windows Server has OpenSSH included with it in Server 2019 that can be configured to allow access. Please see here for instructions on doing so: Windows Server OpenSSH.

In the first example, an Ansible playbook is used to resize the disk. To run the playbook we used the command ansible-playbook <playbook-name>. Below is the text of the playbook, and the output of the command is below that.

Contents of yaml file used to expand the capacity:

- name: Extend Windows drive to maximum capacity.
hosts: "Windows-Hosts"
gather_facts: false
vars:
ansible_user: < your ansible user >
ansible_password: < your ansible password >
ansible_connection: winrm
ansible_port: 5985
ansible_winrm_server_cert_validation: ignore

tasks:
- name: List Current Volume
win_shell:
Get-Volume
register: command_output
- debug:
var: command_output.stdout_lines

- name: Disk Scan
win_shell:
"echo rescan | diskpart"

- name: Disk extension
community.windows.win_partition:
state: present
drive_letter: C
partition_size: "-1"
partition_number: 1

- name: List Modified Volume
win_shell:
Get-Volume
register: command_output
- debug:
var: command_output.stdout_lines


Output of the above playbook:

PLAY [Extend Windows drive to maximum capacity.] *****************************************************************************************************************

TASK [List Current Volume] *********************************************************************************************************************
changed: [2k19-unable-alpaca]

TASK [debug] *********************************************************************************************************************
ok: [2k19-unable-alpaca] => {
"command_output.stdout_lines": [
"",
"DriveLetter FriendlyName FileSystemType DriveType HealthStatus OperationalStatus SizeRemaining Size",
"----------- ------------ -------------- --------- ------------ ----------------- ------------- ----",
" System Reserved NTFS Fixed Healthy OK 114.53 MB 549 MB",
"C NTFS Fixed Healthy OK 37.81 GB 56.16 GB",
"",
""
]
}

TASK [Disk Scan] *********************************************************************************************************************
changed: [2k19-unable-alpaca]

TASK [Disk extension] *********************************************************************************************************************
changed: [2k19-unable-alpaca]

TASK [List Modified Volume] *********************************************************************************************************************
changed: [2k19-unable-alpaca]

TASK [debug] *********************************************************************************************************************
ok: [2k19-unable-alpaca] => {
"command_output.stdout_lines": [
"",
"DriveLetter FriendlyName FileSystemType DriveType HealthStatus OperationalStatus SizeRemaining Size",
"----------- ------------ -------------- --------- ------------ ----------------- ------------- ----",
" System Reserved NTFS Fixed Healthy OK 114.53 MB 549 MB",
"C NTFS Fixed Healthy OK 75.61 GB 93.96 GB",
"",
""
]
}

PLAY RECAP *********************************************************************************************************************
2k19-unable-alpaca : ok=6 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

In this blog post the OpenShift cli tools were used to patch and resize the various PVCs. You can also expand these PVCs in the OpenShift web console by going to Storage > PersistentVolumeClaims, selecting the PVC, and then clicking Actions > Expand PVC in the upper right area of the PVC information page. You are able to utilize whichever method you prefer, and then continue on with the storage increase. We've concentrated on resizing using the command line with the idea of being able to script changes, and modify that to meet the needs of larger environments.

One other option of note is that Windows Disks can be resized from within the Windows GUI using the Disk Management utility. Instructions on doing that can be found here: Windows Disk Management.