Extending “/” Root Filesystem on a VM Guest on ODA

Share on:

Sometimes space utilization projections can be improperly done; possibly calling for the need to increase the filesystem size of a vm guest residing on a virtualized ODA. If you are unlucky to have a vm guest with a non-lvm filesystem requiring an expansion of the “/”; “root” filesystem, then this becomes a slightly tricky task.

Thankfully there is a way out of such a dilemma.

This blog outlines the necessary steps for extending the root filesystem by 50gb on a vm guest residing on an ODA.

The filesystem that we will be extending will be an “ext4” filesystem non-lvm.

The hosts we will be working with are as follows

From our Odabase node 0, we extracted the ff information

 

1. Identify the vm guest to be worked on

From the odabase hosting your vms, run the ff as root user

From the extract above, we have located our vm guest to be worked on as “vm_01”. We will then login to the vm and verify the free space as follows:

We have just 2.4gb free space on the filesystem; hence the urgent need to add some more space.

 

2. Stop vm guest

Now that we have confidently identified the name of the vm guest to be worked on, we will need to stop the running vm guest as root user from its odabase as follows:

We need to verify that indeed the vm guest in question has been stopped with the following command:

We can notice that the “vm_01” vm is in an “OFFLINE” state, indicating that the vm has been successfully stopped.

We can doublecheck with the following command also:

Under “ExpectedState” from the extract above we notice that the state is also “OFFLINE”; proving that the vm is indeed down and we can proceed with the next step.

 

3. Confirm space for addition

It is pertinent to confirm from the repository hosting the vm for adequate free space to accommodate the filesystem extension. In our case we will be extending the filesystem by 50gb so we need to at least make sure that we have enough space in the vm repository to host both the original virtual disk to be extended and the new extended virtual disk upon completion.

From earlier extracts, it can be gathered that the “vm_01” to be operated on is domiciled on the shared repo “vmreps11” on node 0.

From the above, we can validate that we have in excess of 500gb against “FreeSpace” on the vm repository which is more than sufficient for our purposes.

 

4. Locating essential vm files to be backed up 

Log in to the Dom 0 of the node of the ODA where the vm is domiciled which in our case is “odadom0” and backup both the virtual disk to be worked on and the vm guest’s “vm.cfg” file.

If you are clueless as to where exactly to locate these files on the Dom 0, the “Disks” parameter from the previously taken extract from the odabase of your vm should provide some clues to point you to the right direction. Eg:

The extract above shows us that we will be able to locate our files in the “/OVS/Repositories/vmreps11/.ACFS/snaps/vm_01/VirtualMachines/vm_01” directory on the Dom 0.

To verify the exact location and file name of the virtual disk to be worked on, let us open the “vm.cfg” file for further details.

Our vm_01 extract in Step 1 earlier showed us that the “/” mountpoint to be worked on is mounted upon the “/dev/xvda2” filesystem. From the contents of the “vm.cfg” we can see that the virtual disk we have to focus on is the ff     “disk =[u’file:/OVS/Repositories/vmreps11/.ACFS/snaps/vm_01/VirtualMachines/vm_01/vm_01_root.img,xvda,w‘”

This is because is has the “xvda” appended to the end of the disk name. Bear in mind that the filesystem could be named differently in your environment. It will NOT always be named “/dev/xvda2” all the time; it happens to be so because this is the configuration in the example we are using.

 

5. Backing up essential vm files.

Now that we have located the files to be backed up; we can go ahead and do so.

The files to be backed up in our scenario are “vm.cfg” and “vm_01_root.img” already highlighted. Once again ensure that there is enough space in the location for both the original files and the backups.

 

6. Extending the virtual disk

Here will be working on “vm_01_root_backup.img” instead of “vm_01_root.img ” so that we can easily and painlessly revert to the original virtual disk should we encounter any unplanned errors during the process. Try as much as possible to work on the backup version instead of the original version of the virtual disk.

This command extends the “vm_01_root_backup.img” virtual disk by 50gb

 

7. Partition extended virtual disk

Attach the newly extended virtual disk

Display the attached virtual disk

Onto the partitioning process.

Delete and recreate the root and swap partitions.

CAUTION!!!
Make sure you DO NOT delete “/boot”.
TAKE NOTE OF BEGIN AND END CYLINDER LOCATION OF BOOT PARTITION BEFORE PROCEEDING

Enter the letter “p” at the prompt to display the partitions existing on the filesystem

Note that (“/root”🠮”/dev/xvda2”🠮”Partition 2”) starts on cylinder “16” as highlighted above so keep that in mind when recreating the partitions. Once again it might be a different cylinder value in your environment.

The partitions we are interested in now are the (“/root”🠮”/dev/xvda2”🠮”Partition 2”) & (“swap”🠮”/dev/xvda3”🠮”Partition 3”).

These are the two partitions to be deleted and recreated. Enter the letter “d” and the follow with the respective partition numbers to delete the partitions.

Now we will have to recreate the deleted partition “/root” as primary partitions. Enter the letter “n” to recreate the previously deleted partitions and then enter letter “p” to specify the creation of a primary partition.

From the extract above, we specified our “First cylinder” as “16” since that is where the previously deleted (“/root”🠮”/dev/xvda2”🠮”Partition 2”) partition cylinder started and we would want to continue from where we left off to prevent any complications later on during the process. For “Last Cylinder”, we specified “+50G” to ensure that the (“/root”🠮”/dev/xvda2”🠮”Partition 2”) partition possesses the size 50gb.

Now it is time to recreate the (“swap”🠮”/dev/xvda3”🠮”Partition 3”) partition. We will simply allocate the remaining free space to the (“swap”🠮”/dev/xvda3”🠮”Partition 3”) partition.

Note that we are using cylinder “8722” above as the “First cylinder” since it is the next cylinder after “8721” which happens to be the “Last Cylinder” for (“/root”🠮”/dev/xvda2”🠮”Partition 2”). We need to try not to cause any overlaps.

Next, enter letter “t”, specify partition “3” and then select letter “L”  and then option  “82”  (Linux swap / So) to configure the newly created partition as a “swap” partition.

Detach the newly partitioned virtual disk

Edit the “vm.cfg” to include the newly partitioned virtual disk.
In our case, the original virtual disk containing the “root” partition was “vm_01_root.img” so we will have to replace that with “vm_01_root_backup.img”

Hence, replace the values

 

8. Prepare vm guest for single user mode boot

We need to edit the “vm.cfg” in order to help us boot the vm guest into single mode to continue the remainder of the tasks.

In your “vm.cfg” file, insert the ff highlighted

For Single User Mode, it is just needed to edit the vm.cfg file and add (extra = ‘S’) just after (bootloader=”/usr/bin/pygrub”)

Also, the (,vncpasswd=welcome1) will enable you to easily login to the vm with vnc viewer if you do not know the password. Here we will be using the just assigned password “welcome1”.

NOTE:
Remember to revert these changes after the operation is complete.

 

9. Start the vm guest

Login to your odabase and start the vm guest

Confirm that vm is started

The extract above indicates that our vm “vm_01” is in an “ONLINE” state and therefore it is running.

Using vncviewer, login to the vm guest, specifying your respective dom0 IP on the node that the vm is domiciled and the vnc port indicated in your “vm.cfg” file. In our case, our vnc port in that file is port 1, (vnc = 1)

If the vm does not boot into single user mode, edit the “/etc/inittab” file as follows

After doing the above, you can reboot into single user mode but do not forget to reverse this setting after completing the work.

 

10. Resize “/root” partition.

Once we have logged into our vm through vncviewer, we can continue the process of resizing our partition.

Run a filesystem check

Run the ff command to ensure our filesystem is properly mounted

Resize the filesystem

Confirm the new size of the “/” partition

 

11. Revert changes to vm configuration files

Now that the space has been added, we will have to do the ff:

  • Shutdown the vm guest from odabase
  • Revert the changes made in the “vm.cfg” in step 8
  • Startup the vm guest
Share on:

More from this Author

Troubleshooting and Resolving ORA 00283 and ORA 28374 Errors During Remote Pluggable Database Cloning

Troubleshooting and Resolving ORA-00283 and ORA-28374 Errors During Remote Pluggable Database Cloning

Introduction: Creating a clone of a remote pluggable database across a database link can be a powerful tool for managing and replicating data across ... Read More

strong secure password

Modifying SYS and Wallet Password on ExaCC Bypassing Password Verify Function

Introduction: In this piece, I will walk you through a real-life scenario recently faced with a client where I had to change an Oracle 12c SYS and ... Read More

Back to Top