Install OS and Oracle Software on the Target VM

[root@orademo1 ~]$ lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
fd0           2:0    1    4K  0 disk 
sda           8:0    0  100G  0 disk
├─sda1        8:1    0    1G  0 part /boot
└─sda2        8:2    0   99G  0 part
  ├─ol-root 249:0    0   50G  0 lvm  /
  ├─ol-swap 249:1    0  3.9G  0 lvm  [SWAP]
  └─ol-home 249:2    0 45.1G  0 lvm  /home
sdb           8:16   0  500G  0 disk 
sdc           8:32   0    2T  0 disk 

Create a mount point for the software home. Create an entry in /etc/fstab and mount /u01.

# mkdir /u01
# echo "UUID=fb70ad02-edb1-4f75-affb-3ce574608856 /u01  xfs     discard,noatime      0 0" >> /etc/fstab
# mount /u01

As we know, when we create a disk in a vVol datastore, a volume automatically gets created on the FlashArray. The volumes actually get created inside a Volume Group whose name is derived from the name of the VM as shown below

Clicking on the volume group will show the volumes it contains.

As mentioned earlier, at a minimum, three kinds of vVols get created - Config and Swap vVol in addition to Data vVols. As we can see, it is using automatically generated names for the Data vVols. At this point we can go and rename them to same names of the volumes connected to the physical server. Even though volumes for both databases are on the same array, there will not be a naming conflict as the VM volumes are in a volume group.

To rename a volume, simply click on the button with three vertical dots (kebab icon) in the last column. After rename, this is how our volumes look like.

Follow the normal procedure to install Grid Infrastructure as well as Oracle database software from the installation media. Create a dummy database that is identical to the physical server in terms of the number of file system volumes or ASM disks, as the case may be. In case of ASM, the dummy database should use the same method (udev,ASMlib or ASMFD) for ASM disk persistence as the source. The database name should be the same, although the hostname of the VM can be different if required.

At this point, we have a database identical to the one on physical server up and running on the VM. The final step would be to refresh the contents of the dummy database with the production database whenever we are ready to make the switch.

We have created the dummy database to have the database installer do some of the tasks like registering the database with Oracle Clusterware, and just as a sanity check that the grid and database software is functioning correctly before we refresh the database volumes from production.

Alternatively, we can skip the step of creating the dummy database, i.e. we only install database software. In that case, we'll register the database with Oracle Clusterware manually as shown in Step 6d.