VMware is a widely used virtualization platform for running Oracle databases. In the past, database storage options available to Oracle DBAs for creating virtual disks were limited to either a VMFS (Virtual Machine File System) datastore, or a RDM (Raw Device Mapping) disk.
VMware Virtual Volumes (vVol) is a new technology introduced in vSphere 6.0 to radically simplify storage management for vSphere admins as well as storage admins. vVol datastores address the challenges of over-abstraction of virtual disks in VMFS datastores on one end, and rigidity of RDM (Raw Device Mapping) datastores on the other.
In this article, we'll go through the use case of migrating an Oracle database running on physical hardware to a VMware virtual machine using vVols. We'll see how simple it is to migrate from physical to virtual and visa versa using the vVol technology. The instructions provided here can also be used to move a virtualized Oracle database on VMware RDMs to VMware Virtual Volumes.
Many organizations run their production workloads on physical servers and their tier-two environments on virtual. This process can also be used to provision and refresh clones of a production Oracle database running on physical servers.
Before we dive deep into vVols, let's first take a quick look at VFMS and RDM, and how vVols address their shortcomings.
VMFS
VMFS is a cluster file system that provides storage virtualization optimized for virtual machines. Each virtual machine consists of a set of files (vmdks) and VMFS is the default storage system for these files on physical SCSI disks and partitions. A VMFS datastore typically consists of a single storage volume, but it contains virtual disks from multiple virtual machines. VMFS datastore supports VMware distributed infrastructure services such as vSphere vMotion, DRS, and vSphere HA to operate across a cluster of ESXi hosts. This gives us a lot of flexibility, but at the same time, the increased abstraction leads to loss of control as well as monitoring capabilities. At the storage level, the granularity of array operations like snapshots and replication is at a volume level (i.e. at a VMFS datastore level). That makes it difficult to snapshot a VM, or an individual disk inside a VM, without having to snapshot the entire datastore. Moreover, VM snapshots are known to suffer from long freezes of the VM when old snapshots are deleted (please refer to VMware KB 1002836 for more details). Storage level snapshots do not have this problem and are much more efficient.
For detailed instructions on cloning an Oracle database on VMFS, please refer to KB article Cloning an Oracle Database on VMware VMFS.
RDM
RDM or Raw Device Mapping, as its name suggests, allows a virtual machine to directly access a volume on the FlashArray™. It can be used only with Fibre Channel or iSCSI. RDM can be thought of as providing a symbolic link from a VMFS volume to a physical volume on the FlashArray. This is great because it enables a one-to-one relationship between a virtual disk in the VM and the volume on the FlashArray, and opens up the possibility of using FlashArray features like snapshots and replication at the virtual disk granularity. However, RDMs are not fully integrated with the VMware stack and suffer from many limitations.
VVols deliver array native capabilities to VMs. VVol technology can be thought of as a VMware certified and integrated framework for provisioning RDMs. We get all the benefits of RDMs – data mobility, array-based granularity, but integrated into the VMware stack. No additional plugins or workflows to manage.
Please note that vVols are currently not supported with NVMe-oF, ActiveCluster or ActiveDR.
With Virtual Volumes, virtual disks become native objects on the storage array. This means VM operations like clones and snapshots are executed natively by the storage array. Any VM placed onto a vVols datastore gets all of these benefits out of the box.
There are a few different types of vVols that get created on the FlashArray:
-
Config vVol – This is 4GB volume that gets created per VM that stores the description of the hardware and settings for the virtual machine. It contains the VMX file, logs and few other descriptor files.
-
Data vVol – This gets created for each virtual disk added to the VM and is the volume that stores the actual data. Its size is the same as the requested size of the virtual disk. Different configurations and policies can be applied to each Data vVol.
-
Swap vVol – This is created automatically when a VM powers up and is deleted when the VM is powered off.
-
Memory vVol – This gets created when a snapshot is taken with the "Snapshot Memory" option.
VMware features like pausing, resuming, snapshotting a VM are all available to vVol VMs.
At a high level, we will be performing the following steps:
- Connect VMware cluster to the FlashArray
- Configure VASA storage provider on the VMware cluster
- Gather information about the database on the physical server (source)
- Create a new VM to host the migrated database (target)
- Install Oracle Linux and Oracle 19c on the target VM
- Migrate Oracle database volumes from physical server to virtual machine using snapshot copy at the FlashArray level.