6.13.1 Customizing the Guest Image to Expand an Existing File System

The following example workflow shows how to customize a guest image to expand an existing file system. You can adapt the following to perform similar customizations in your environment.

  1. Prepare a host with libguestfs packages and choose a staging server.

    Modification of the baseline Exadata system image is performed using the libguestfs tools (such as guestfish, virt-resize, and virt-customize). To avoid potential issues with Oracle Exadata System Software updates, Oracle recommends using a separate Linux host to perform image modification. You can use dnf to install the required libguestfs packages. For example: 

    # dnf install libguestfs-xfs libguestfs-tools

    After image modification, the rest of the workflow is performed as root on an Exadata KVM host, also known as the staging server. Choose a suitable KVM host as the staging server. In this example workflow, the staging server is exa01adm05.

  2. Select the Exadata base system image being customized and copy it to the libguestfs server.

    Note:

    The base system image must be from Oracle Exadata System Software release 26.1.0 or later.

    In this example workflow, the baseline Exadata system image is System.first.boot.26.1.0.0.0.260515.rtg.img.

  3. On the libguestfs server, examine the baseline Exadata system image.

    Note:

    On the libguestfs server, set LIBGUESTFS_BACKEND=direct in the Linux shell environment to avoid potential configuration and permission issues with libguestfs tools. 

    # ls -la ./System.first.boot.26.1.0.0.0.260515.rtg.img
-rw-r-----. 1 root root 106622563328 Apr 27 12:03 System.first.boot.26.1.0.0.0.260515.rtg.img
# export LIBGUESTFS_BACKEND=direct
# virt-filesystems -a ./System.first.boot.26.1.0.0.0.260515.rtg.img --all -h -l
Name                                Type       VFS     Label MBR Size Parent
/dev/sda1                           filesystem xfs     BOOT  -   412M -
/dev/sda2                           filesystem unknown -     -   256M -
/dev/VGExaDbDomU/LVDbHome           filesystem xfs     HOME  -   3.9G -
/dev/VGExaDbDomU/LVDbKdump          filesystem xfs     KDUMP -   20G  -
/dev/VGExaDbDomU/LVDbSwap1          filesystem swap    SWAP  -   16G  -
/dev/VGExaDbDomU/LVDbSys1           filesystem xfs     DBSYS -   15G  -
/dev/VGExaDbDomU/LVDbSys2           filesystem unknown -     -   15G  -
/dev/VGExaDbDomU/LVDbTmp            filesystem xfs     TMP   -   2.9G -
/dev/VGExaDbDomU/LVDbVar1           filesystem xfs     VAR   -   1.9G -
/dev/VGExaDbDomU/LVDbVar2           filesystem unknown -     -   2.0G -
/dev/VGExaDbDomU/LVDbVarLog         filesystem xfs     DIAG  -   18G  -
/dev/VGExaDbDomU/LVDbVarLogAudit    filesystem xfs     AUDIT -   924M -
/dev/VGExaDbDomU/LVDoNotRemoveOrUse filesystem unknown -     -   2.5G -
/dev/VGExaDbDomU/LVDbHome           lv         -       -     -   4.0G /dev/VGExaDbDomU
/dev/VGExaDbDomU/LVDbKdump          lv         -       -     -   20G  /dev/VGExaDbDomU
/dev/VGExaDbDomU/LVDbSwap1          lv         -       -     -   16G  /dev/VGExaDbDomU
/dev/VGExaDbDomU/LVDbSys1           lv         -       -     -   15G  /dev/VGExaDbDomU
/dev/VGExaDbDomU/LVDbSys2           lv         -       -     -   15G  /dev/VGExaDbDomU
/dev/VGExaDbDomU/LVDbTmp            lv         -       -     -   3.0G /dev/VGExaDbDomU
/dev/VGExaDbDomU/LVDbVar1           lv         -       -     -   2.0G /dev/VGExaDbDomU
/dev/VGExaDbDomU/LVDbVar2           lv         -       -     -   2.0G /dev/VGExaDbDomU
/dev/VGExaDbDomU/LVDbVarLog         lv         -       -     -   18G  /dev/VGExaDbDomU
/dev/VGExaDbDomU/LVDbVarLogAudit    lv         -       -     -   1.0G /dev/VGExaDbDomU
/dev/VGExaDbDomU/LVDoNotRemoveOrUse lv         -       -     -   2.5G /dev/VGExaDbDomU
/dev/VGExaDbDomU                    vg         -       -     -   99G  /dev/sda3
/dev/sda3                           pv         -       -     -   99G  -
/dev/sda1                           partition  -       -     -   512M /dev/sda
/dev/sda2                           partition  -       -     -   256M /dev/sda
/dev/sda3                           partition  -       -     -   99G  /dev/sda
/dev/sda                            device     -       -     -   99G  -

# virt-cat -a ./System.first.boot.26.1.0.0.0.260515.rtg.img /etc/fstab
libguestfs: error: mount_ro: mount: /crashfiles: mount point is not a directory
virt-cat: some filesystems could not be mounted (ignored)
LABEL=BOOT              /boot           xfs     defaults,nodev,nosuid           0 0
LABEL=DBSYS             /               xfs     defaults                        0 0
LABEL=SWAP              swap            swap    defaults                        0 0
LABEL=KDUMP             /crashfiles     xfs     defaults,nodev                  0 0
LABEL=TMP               /tmp            xfs     defaults,nodev,nosuid           0 0
LABEL=HOME              /home           xfs     defaults,nodev,nosuid           0 0
LABEL=VAR               /var            xfs     defaults,nodev                  0 0
LABEL=DIAG              /var/log        xfs     defaults,nodev,nosuid           0 0
LABEL=AUDIT             /var/log/audit  xfs     defaults,nodev,noexec,nosuid    0 0
tmpfs                   /dev/shm        tmpfs   defaults,nodev,size=30831m      0 0

# qemu-img info ./System.first.boot.26.1.0.0.0.260515.rtg.img
image: System.first.boot.26.1.0.0.0.260515.rtg.img
file format: raw
virtual size: 99.3 GiB (106622563328 bytes)
disk size: 5.81 GiB

    Take note of the internal structure of the baseline image. In particular, note the size of the image and location of the physical volume (/dev/sda3), which will be expanded in order to accommodate the desired file system expansion.

  4. Create an expanded clone of the baseline system image:

    # qemu-img create -f raw custom.img 150G
Formatting 'custom.img', fmt=raw size=161061273600

# virt-resize --expand /dev/sda3 ./System.first.boot.26.1.0.0.0.260515.rtg.img  ./custom.img
[   0.0] Examining System.first.boot.26.1.0.0.0.260515.rtg.img
  25% ...
 100% ...
**********

Summary of changes:

/dev/sda1: This partition will be left alone.

/dev/sda2: This partition will be left alone.

/dev/sda3: This partition will be resized from 98.5G to 149.2G.  The LVM PV 
on /dev/sda3 will be expanded using the ‘pvresize’ method.

**********
[  11.0] Setting up initial partition table on custom.img
[  22.2] Copying /dev/sda1
[  23.1] Copying /dev/sda2
[  23.4] Copying /dev/sda3
...
[ 137.1] Expanding /dev/sda3 using the ‘pvresize’ method

Resize operation completed with no errors.  Before deleting the old disk, 
carefully check that the resized disk boots and works correctly

    In the example, the size of the expanded baseline image is 150 GB (150G). You can choose any size that accommodates the base image and desired customizations.

  5. Customize the base image.

    You can use guestfish to customize a guest image. It is recommended to prepare a script with the desired customizations and then run guestfish to apply the scripted customizations.

    Note:

    You are responsible for all image customizations that you perform. Oracle will not support questions or issues with specific image customizations. If a guest fails, and Oracle suspects the failure may be caused by an image customization, then Oracle may ask for the issue to be reproduced on a standard (uncustomized) system.

    The guestfish utility is a powerful and flexible tool for accessing and customizing a guest image. You can use it to install application binaries and data, create or resize file systems, and perform numerous other offline customizations.

    The following example shows a guestfish script that starts by mounting the guest image and making it bootable. This initialization is a typical requirement for system images. Following the initialization phase, the script continues to perform a set of customizations to expand the root file system. You can use the following example as a template for similar customizations that you want to make.

    Note:

    Consider the need to recalculate and resize LVDoNotRemoveOrUse. First-boot validation can fail if LVDoNotRemoveOrUse is missing or undersized. 

    # cat modify.fish
# Add target disk/volume to guestfs environment
add ./custom.img

# Start execution
run

# Mount root filesystem (LVM root) as /
mount /dev/VGExaDbDomU/LVDbSys1 /

# Mount /boot partition
mount /dev/sda1 /boot

# Install GRUB bootloader to disk (BIOS mode)
# NOTE: Not applicable for UEFI systems
sh "grub2-install /dev/sda"

# NOTE: Alternative for UEFI systems
# Mount EFI System Partition (required for UEFI boot files)
# mount /dev/sda2 /boot/efi

# End of Initialization 

# Expand root file system lv to 40G. We need to expand both active/inactive partitions
lvresize /dev/VGExaDbDomU/LVDbSys1 40960
lvresize /dev/VGExaDbDomU/LVDbSys2 40960

# Resize root filesystem.
xfs_growfs /

# LVDoNotRemoveOrUse is the snapshot reserve LV for KVM guest custom filesystem layouts.
# The required reserve is calculated from the mounted system filesystems:
# /, /var, /opt, /etc, /root, /usr
# For each of those mounts that exists and is backed by an LV in the root VG:
# reserve_for_mount = max(ceil(LV_size_in_GiB * 0.04), 1 GiB)
# The final required size is the sum of the reserves for each mount. Rounding is done for each LV before summing (not once at the end).
#
# Examples:
# 40G LV -> ceil(4% of 40G) = ceil(1.6G) = 2GiB
# 10G LV -> ceil(0.4G) = 1GiB minimum
# 100G LV -> 4GiB
#
# If / is 40G, /var is 10G, and /opt is 20G,
# then LVDoNotRemoveOrUse required size = 2GiB + 1GiB + 1GiB = 4GiB
#
# In this case, / is 40G, /var is 2G, and no /opt.
# So, LVDoNotRemoveOrUse required size = 2GiB + 1GiB = 3GiB

lvresize /dev/VGExaDbDomU/LVDoNotRemoveOrUse 3072

# Exit guestfs session
exit

    Note:

    For further guestfish commands and examples see the libguestfs help at https://libguestfs.org/.

    After you prepare the customization script, you can run guestfish to apply it. For example, the following guestfish command runs the script at ./modify.fish: 

    # guestfish --rw -f ./modify.fish

    Examine any output from the guestfish command to ensure that the customizations are performed as planned.

  6. Create a checksum for the customized image and copy the customized image back to the Exadata staging server.

    You can use the Linux sha256sum utility to create a checksum for a customized image. For example: 

    # sha256sum ./custom.img
b796a1f4b38d442f8ce1ab405525c38b92bddf1f37031580b46b7cd4af348bac ./custom.img

    The checksum is used later to validate the integrity of the customized image after it is copied to the Exadata staging server and loaded into the Exascale volume used for deployment.

  7. On the Exadata staging server, provision a volume for the customized image.

    To provision a volume for a customized image, use the Exascale command line interface (ESCLI) to create a new empty volume and then attach it to the staging server. For example: 

    [root@exa01adm05 ~]# escli --wallet <wallet-location> --ctrl <ERS-endpoint>
Wallet: <wallet-location>
User: admin
@> lsinitiator 
id                                   hostName      giClusterName giClusterId 
d8fd0073-59ac-e40b-d8fd-007359ace40b exa01adm06               
f7c2bd74-08c7-b02c-f7c2-bd7408c7b02c exa01adm05               

@> mkvolume 150g --attributes vault=sysvault_exa01,name=goldvol_exa01
Created volume with id vol0021_99b9510268b04b74a8157d662ade5e4f

@> mkvolumeattachment  vol0021_99b9510268b04b74a8157d662ade5e4f goldvol_exa01 --attributes initiator=f7c2bd74-08c7-b02c-f7c2-bd7408c7b02c
Created edv attachment with id att0021_a72a1ab7cec84c1dbdaf5a700354410a

@> exit

    In the example:

    • The volume size is 150 GB (150g), matching the size of the customized image it will accommodate.

    • The volume is named goldvol_exa01. You can choose your own name for each customized image. Also take note of the volume ID (for example, vol0021_99b9510268b04b74a8157d662ade5e4f) as you will require it later to reference the volume.

    • The volume is created in an Exascale vault named sysvault_exa01. You can choose an existing vault in your Exascale system or create a specific vault to house your customized images.

    After volume provisioning, you can verify a volume by examining the corresponding block device at /dev/exc/<volume-name>. For example: 

    [root@exa01adm05 ~]# ls -la /dev/exc/goldvol_exa01 
brw-rw----. 2 root disk 251, 11 May  7 07:40 /dev/exc/goldvol_exa01

  8. Copy the customized image into the Exascale volume.

    For example:

    [root@exa01adm05 ~]# dd if=./custom.img of=/dev/exc/goldvol_exa01 bs=16M status=progress oflag=direct
...

  9. Catalog the gold-image volume.

    As an operational best practice, you should maintain a catalog of your customized gold-images. For each image, you should maintain metadata to help you identify the image and its contents. You should also keep checksum information to validate the integrity of each image.

    To ensure an enduring read-only copy of the customized image, you can create a snapshot of the underlying Exascale volume. To identify the Exascale volume, use the volume ID reported during volume creation. For example: 

    [root@exa01adm05 ~]# escli --wallet <wallet-location> --ctrl <ERS-endpoint>

@> mkvolumesnapshot vol0021_99b9510268b04b74a8157d662ade5e4f --attributes name=goldvol_exa01_snap1
Created volume snapshot with id vol0021_snap0001_50e52177583f4be4bad68ac20b65001e

    Take note of the volume snapshot ID (for example, vol0021_snap0001_50e52177583f4be4bad68ac20b65001e) as you will require it to reference the volume snapshot.

    After you create a volume snapshot, you can continue to use the original volume for further customizations. At any point you can make another snapshot for a different generation of the customized image.

    After you have a snapshot for a validated and tested image, you can lock the snapshot to prevent accidental deletion. For example:

    @> chvolumesnapshot vol0021_snap0001_50e52177583f4be4bad68ac20b65001e --attributes lockExpiryTime=2050-06-30T13:00:00,lockImmutable=true

    To use a validated and tested image, make a volume clone and associated attachment. For example:

    @> mkvolume --attributes volumeSnapshot=vol0021_snap0001_50e52177583f4be4bad68ac20b65001e,name=goldvol_exa01_clone1
Created volume with id vol0039_e9867af0dc03439698e5f6d7edf43a04

@> mkvolumeattachment vol0039_e9867af0dc03439698e5f6d7edf43a04 goldvol_exa01_clone1 --attributes initiator=f7c2bd74-08c7-b02c-f7c2-bd7408c7b02c
Created edv attachment with id att0031_690f91c85ad64573a93485426467977b

    The volume clone behaves just like the original Exascale volume, with the added convenience that it is easy to drop and re-create it to return the clone back to the snapshot state.

    You can use the Linux sha256sum utility to create a checksum for a customized image. For example: 

    [root@exa01adm05 ~]# sha256sum /dev/exc/goldvol_exa01_clone1
b796a1f4b38d442f8ce1ab405525c38b92bddf1f37031580b46b7cd4af348bac /dev/exc/goldvol_exa01_clone1

    Compare this checksum with the one created on the libguestfs server to validate that the image has not changed. You can also save the checksum in the image catalog and check it every time you use the image.

  10. Clone the customized image to the required KVM hosts.

    Before you can reference a customized image in an Exadata guest VM, you must clone the image to make it available on the required KVM hosts.

    You can use the Oracle Exadata Deployment Assistant (OEDA) Command Line Utility (OEDACLI) to perform the required actions.

    Following is an example of the required command sequence. In the example:

    • exa01adm05 and exa01adm06 identify the KVM hosts that will expose the customized image. The command sequence assumes that the customized image is being cloned to two hosts. However, you can extend this to any required number of hosts.

    • goldvol_exa01adm05 is the volume name used to identify the volume on exa01adm05, and goldvol_exa01adm06 is used to identify the volume on exa01adm06.

    • vol0039_e9867af0dc03439698e5f6d7edf43a04 is the Exascale volume ID associated with the customized image.

    • /root/es.xml represents the path to the Exadata XML configuration file for your system. 

    [root@exa01adm05 linux-x64]# cat ./clone.cmd
CLONE EDVVOLUME volumename=goldvol_exa01adm05 where volumesource=vol0039_e9867af0dc03439698e5f6d7edf43a04 hostname=exa01adm05
SAVE ACTION
MERGE ACTIONS
DEPLOY ACTIONS

CLONE EDVVOLUME volumename=goldvol_exa01adm06 where volumesource=vol0039_e9867af0dc03439698e5f6d7edf43a04 hostname=exa01adm06
SAVE ACTION
MERGE ACTIONS
DEPLOY ACTIONS

SAVE FILE

[root@exa01adm05 linux-x64]# ./oedacli -c /root/es.xml -f ./clone.cmd
Version : 260504
SUCCESS - file loaded OK
Customer : Example - Example
processMerge
processMergeActions
Merging Action : CLONE EDVVOLUME volumename=goldvol_exa01adm05 where volumesource=vol0039_e9867af0dc03439698e5f6d7edf43a04 hostname=exa01adm05
Merging CLONE EDVVOLUME
Action Validated and Merged OK
Deploying Action ID : 10 CLONE EDVVOLUME volumename=goldvol_exa01adm05 where volumesource=vol0039_e9867af0dc03439698e5f6d7edf43a04 hostname=exa01adm05
Deploying CLONE EDVVOLUME
Found the source EDV volume goldvol_exa01_clone1 for volume source vol0039_e9867af0dc03439698e5f6d7edf43a04
Cloned an EDV volume with Exascale Volume ID vol0041_e5f6d7edf43a04e9867af0dc03439698
Attached volume vol0041_e5f6d7edf43a04e9867af0dc03439698 into KVM host exa01adm05.example.com for guest exa01adm05.example.com in /dev/exc/goldvol_exa01adm05_vol0041_e5f6d7edf43a04e9867af0dc03439698
Done...
Done [Elapsed = 17235 mS [0.0 minutes] Thu May 07 10:00:30 PDT 2026]]
processMerge
processMergeActions
Merging Action : CLONE EDVVOLUME volumename=goldvol_exa01adm06 where volumesource=vol0039_e9867af0dc03439698e5f6d7edf43a04 hostname=exa01adm06
Merging CLONE EDVVOLUME
Action Validated and Merged OK
Deploying Action ID : 11 CLONE EDVVOLUME volumename=goldvol_exa01adm06 where volumesource=vol0039_e9867af0dc03439698e5f6d7edf43a04 hostname=exa01adm06
Deploying CLONE EDVVOLUME
Found the source EDV volume goldvol_exa01_clone1 for volume source vol0039_e9867af0dc03439698e5f6d7edf43a04
Cloned an EDV volume with Exascale Volume ID vol0042_690f91c85ad64573a93485426467977b
Attached volume vol0042_690f91c85ad64573a93485426467977b into KVM host exa01adm06.example.com for guest exa01adm06.example.com in /dev/exc/goldvol_exa01adm06_vol0042_690f91c85ad64573a93485426467977b
Done...
Done [Elapsed = 10085 mS [0.0 minutes] Thu May 07 10:00:40 PDT 2026]]
File : /root/es.xml saved OK 
[root@exa01adm05 linux-x64]#

    Examine the OEDACLI output to determine the corresponding block device for the image volume on each KVM host. For example, /dev/exc/goldvol_exa01adm05_vol0041_e5f6d7edf43a04e9867af0dc03439698 on exa01adm05, and /dev/exc/goldvol_exa01adm06_vol0042_690f91c85ad64573a93485426467977b on exa01adm06. Take note of these block devices as you will require them to reference the customized image in your guest VMs.

  11. Alter the configuration of the Exadata guest VMs to use the customized image.

    To use a customized image in Exadata guest VMs, you must first define the VMs using OEDA as you would for any Exadata VM cluster. Then, before deploying the cluster, you must alter the VM definition in the Exadata XML configuration file using OEDACLI.

    Following is an example of the required command sequence. In the example:

    • exa01adm05vm01 and exa01adm06vm01 identify the guest VMs being altered.

      It is assumed that exa01adm05vm01 resides on the KVM host exa01adm05, and exa01adm06vm01 resides on exa01adm06.

      The command sequence assumes that the customized image is being used across two guests. However, you can extend this to any required number of guests.

    • The imagefile settings reference the block devices for the cloned image volume on each KVM host (shown in the previous step). Each guest VM must reference the cloned image volume that is attached to the KVM host where that guest VM will run.

      For exa01adm05vm01, the system image is set to /dev/exc/goldvol_exa01adm05_vol0041_e5f6d7edf43a04e9867af0dc03439698, which is the reference to the gold-image volume clone on the KVM host exa01adm05.

      For exa01adm06vm01, the system image is set to /dev/exc/goldvol_exa01adm06_vol0042_690f91c85ad64573a93485426467977b, which is the reference to the gold-image volume clone on exa01adm06.

    • /root/cluster01-es.xml represents the path to the Exadata XML configuration file containing the VMs being altered. 

    [root@exa01adm05 linux-x64]# cat ./update.cmd
ALTER MACHINE imagefile=/dev/exc/goldvol_exa01adm05_vol0041_e5f6d7edf43a04e9867af0dc03439698 where hostname=exa01adm05vm01
SAVE ACTION
MERGE ACTIONS

ALTER MACHINE imagefile=/dev/exc/goldvol_exa01adm06_vol0042_690f91c85ad64573a93485426467977b where hostname=exa01adm06vm01
SAVE ACTION
MERGE ACTIONS

SAVE FILE

[root@exa01adm05 linux-x64]# ./oedacli -c /root/cluster01-es.xml -f ./update.cmd
Version : 260504
SUCCESS - file loaded OK
Customer : Example - Example
processMerge
processMergeActions
Merging Action : ALTER MACHINE imagefile=/dev/exc/goldvol_exa01adm05_vol0041_e5f6d7edf43a04e9867af0dc03439698 where hostname=exa01adm05vm01
Merging ALTER MACHINE
Action Validated and Merged OK
processMerge
processMergeActions
Merging Action : ALTER MACHINE imagefile=/dev/exc/goldvol_exa01adm06_vol0042_690f91c85ad64573a93485426467977b where hostname=exa01adm06vm01
Merging ALTER MACHINE
Action Validated and Merged OK
File : /root/cluster01-es.xml saved OK 
[root@exa01adm05 linux-x64]#

  12. Deploy the Exadata guest VMs using the customized image.

    Use the OEDA deployment script (install.sh) to deploy the customized guest VMs. For example: 

    [root@exa01adm05 linux-x64]# ./install.sh -cf /root/cluster01-es.xml -s 4
Initializing
===== Executing Create Virtual Machine =====
Checking Secure Fabric setup in [exa01celadm09.example.com, exa01celadm07.example.com, exa01celadm08.example.com]
Checking status of remote files...
Checking status of existing files on remote nodes...
Getting status of local files...
Creating KVM hosts vaults: sysvault_exa01adm06,sysvault_exa01adm05
Vault sysvault_exa01adm06 was already created
Vault sysvault_exa01adm05 was already created
Creating EDV volumes and attachments...
Setting up exascale on KVM hosts if not already setup
Setting up exascale with lock on host: exa01adm05.example.com
Setting up exascale with lock on host: exa01adm06.example.com
Created 10 EDV volumes in 3163 mS
Found 10 volume attachments
Created EDV volume attachments in 3875 mS
Successfully created EDV volumes and attachments.
Creating guests for cluster Cluster-cluster01
Creating KVM guests in cluster Cluster-cluster01
File name is /EXAVMIMAGES/upgrade/linux-x64/WorkDir/exa01adm05vm01.example.com-vm.xml
File name is /EXAVMIMAGES/upgrade/linux-x64/WorkDir/exa01adm06vm01.example.com-vm.xml
Creating KVM guest using /EXAVMIMAGES/upgrade/linux-x64/WorkDir/exa01adm05vm01.example.com-vm.xml on node exa01adm05.example.com
Creating KVM guest using /EXAVMIMAGES/upgrade/linux-x64/WorkDir/exa01adm06vm01.example.com-vm.xml on node exa01adm06.example.com
KVM Guests created, waiting for guests to start...
No config Keys in the configuration file..
Creating databasemachine.xml for EM discovery
Done Creating databasemachine.xml for EM discovery
===== Successfully completed execution of step Create Virtual Machine [elapsed Time [Elapsed = 314480 mS [5.0 minutes] Thu May 07 10:08:05 PDT 2026]] =====

[root@exa01adm05 linux-x64]#

    Note that the deployment does not specifically identify when a customized image is used.

    To confirm that the customized image was used, examine the newly created guest VMs and verify that they contain the expected customizations. For example, the following confirms that guest VM exa01adm05vm01 has the customized 40GB root file system: 

    [root@exa01adm05 ~]# ssh -l root exa01adm05vm01
root@exa01adm05vm01's password: 
...
[root@exa01adm05vm01 ~]# df -h
Filesystem                                                                                         Size  Used Avail Use% Mounted on
devtmpfs                                                                                            40G     0   40G   0% /dev
tmpfs                                                                                               41G  5.2M   41G   1% /run
tmpfs                                                                                               41G     0   41G   0% /sys/fs/cgroup
/dev/mapper/VGExaDbDomU-LVDbSys1                                                                    40G  3.2G   37G   8% /
/dev/mapper/VGExaDbDomU-LVDbKdump                                                                   20G  175M   20G   1% /crashfiles
/dev/sda1                                                                                          412M  170M  243M  42% /boot
/dev/mapper/VGExaDbDomU-LVDbTmp                                                                    3.0G   54M  2.9G   2% /tmp
/dev/mapper/VGExaDbDomU-LVDbVar1                                                                   2.0G  146M  1.8G   8% /var
/dev/mapper/VGExaDbDomU-LVDbHome                                                                   4.0G   61M  3.9G   2% /home
/dev/mapper/VGExaDbDomU-LVDbVarLog                                                                  18G  191M   18G   2% /var/log
/dev/mapper/VGExaDbDomU-LVDbVarLogAudit                                                            924M   40M  885M   5% /var/log/audit
tmpfs                                                                                               81G  4.0K   81G   1% /dev/shm
/dev/mapper/VGExaDbDisk.exa01adm05vm01_u01_vol0027_fb9191ec508b4816899553e32973e053-LVDBDisk        18G  161M   18G   1% /u01
/dev/mapper/VGExaDbDisk.exa01adm05vm01_gih01_vol0030_70de90b21cde4ab5afefb5e49fe0d66a-LVDBDisk      48G  3.1G   45G   7% /u01/app/23.0.0.0/grid
/dev/mapper/VGExaDbDisk.exa01adm05vm01_dbh01_vol0033_4fa5dfdedf3c45c480060c508ddde9a4-LVDBDisk      48G  8.6G   40G  18% /u01/app/oracle/product/23.0.0.0/dbhome_4
tmpfs                                                                                              8.1G     0  8.1G   0% /run/user/0
[root@exa01adm05vm01 ~]#

Parent topic: Customizing the Guest Image