“Come with me if you want to live” – famous words from the Terminator series.

It’s also the very reason IT companies are adopting the ‘Virtualize First’ policy to reap all of the benefits of virtualization and move away from the soon to be legacy bare metal architecture world and ‘save a bunch of money’ , just as the Gecko said.

As part of the Virtualization journey, one of the tools VMware Professional Services (PSO), Partners and Customers use to migrate applications from physical x86 servers (Windows & Linux) to VMware Virtual Machine (VM) is using the VMware Convertor tool, the process known as P2V (Physical to Virtual). It transforms the Windows- and Linux-based physical machines and third-party image formats to VMware virtual machines.

Read moreProtecting Virtual SAP Landscapes with VMware vShield App – Part 1 of 2

One of the most common question I get talking the VMware field, Partners & Customers as part of my role is ‘Can I use VMware Convertor to migrate Oracle databases from physical x86 running  Linux / Oracle OVM running Linux to VMware vSphere platform ?’ , the answer, famous 2 words , ‘it depends !!’ .

Let me explain why I said that.

Database Re-Platforming

Oracle databases, being the sophisticated ‘beasts of burden’, there are many key factors to be kept in mind when we embark on an Oracle database re-platforming exercise, either between same / different system architectures, bare metal to bare metal / physical to virtual architecture, some of them include:

  • source and destination system architecture
    • are we moving between like architectures (x86 to x86)
    • are we moving between from a big endian system to a little endian system (Solaris / AIX / HP-UX to x86)
  • size and operating nature of the database (terabytes / production, pre-prod, dev, test etc)
  • database storage (File system / Oracle ASM)
Read moreSizing Virtual Machines for JVM Workloads – Part 2

More information on Handiness can be found in the link below
https://en.wikipedia.org/wiki/Endianness

So, if your use case is moving Oracle databases from a big endian system to a little endian system (Solaris / AIX / HP-UX to x86), Stop Right here!!

You cannot use the VMware Convertor tool to migrate databases between RISC Unix and Linux x86. You need an Oracle Plan and Design exercise to migrate Oracle databases between these 2 systems.

Keep reading if you are replatforming Oracle database between x86 platforms i.e. Physical server / Virtual machine (VMware vSphere / Oracle OVM) to VMware Virtual Machine (VMware).

Database Storage

One of the key factors in a database re-platforming exercise is the database storage migration.

Storage for a standalone Oracle database on Linux can be typically stored in

  • a standalone filesystem (e.g ext3 / ext4 / xfs / ocfs2 etc)
  • networked filesystem i.e NFS / Direct NFS (dNFS)
  • Oracle Automatic Store Management (ASM)

Oracle Automatic Store Management (ASM)

As we all know, Oracle technologies are getting sophisticated with every release and Oracle Automatic Store Management (ASM) released in version 10 has made databases performance and management more sophisticated.

Oracle ASM is Oracle’s recommended storage management solution that provides an alternative to conventional volume managers, file systems, and raw devices. Oracle ASM is a volume manager and a file system for Oracle Database files that supports single-instance Oracle Database and Oracle Real Application Clusters (Oracle RAC) configurations.

More information on Oracle ASM can be found in the link below
https://docs.oracle.com/database/122/OSTMG/asm-intro.htm#OSTMG036

VMware Convertor

Let’s look at the capabilities of the VMware Convertor tool.

More information about the VMware Convertor can be found at
https://www.vmware.com/support/pubs/converter_pubs.html

Capabilities of VMware Convertor

You can use Converter Standalone to perform a number of conversion tasks.

  • Import running remote physical and virtual machines as virtual machines to standalone ESX/ESXi or to ESX/ESXi hosts that vCenter Server manages.
  • Import virtual machines hosted by VMware Workstation or Microsoft Hyper-V Server to ESX/ESXi hosts that vCenter Server manages.
  • Export virtual machines managed by vCenter Server hosts to other VMware virtual machine formats.

Supported source O/S for P2V

Converter Standalone supports Windows and Linux operating systems as sources for powered-on-machine conversions and virtual-machine conversions.

Supported modes for P2V

Converter Standalone supports disk-based cloning, volume-based cloning, and linked-cloning modes.

Volume-based cloning

  • Volumes from the source machine are copied to the destination machine.
  • Converter Standalone supports volume-based cloning during hot cloning, and during the import of existing virtual machines.
  • During volume-based cloning, all volumes in the destination virtual machine, except LVM2 logical volumes, are converted to basic volumes, regardless of their type in the corresponding source volume. LVM2 logical volumes can be preserved as logical volumes during conversion.
  • Volume-based cloning is performed at the file level or block level, depending on the destination volume size that you select.

More information can be found at
https://www.vmware.com/pdf/convsa_61_guide.pdf

Disk-Based Cloning

Converter Standalone supports disk-based cloning to import existing virtual machines. Disk-based cloning transfers all sectors from all disks and preserves all volume metadata. The destination virtual machine receives partitions of the same type, size, and structure, as the partitions of the source virtual machine. All volumes on the source machine’s partitions are copied as they are. Disk-based cloning supports all types of basic and dynamic disks.

From what we could gather

VMware Convertor will perform an online volume based file level P2V migration from a physical Linux server to virtual Linux server of as long as

  • the physical Linux server is powered on
  • cloning is Volume based cloning at file level i.e. a mounted/visible volume/file system only, no raw disks

Powered on Option

Powered off option

Potential Oracle Migration Issue

  • Migration of Oracle database using Oracle Automatic Storage (ASM) may be an issue here as it’s an Oracle representation of RAW without any visible volume and file system, does VMware Convertor address Linux raw devices?

VMware Convertor Cold Clone

In order to migrate the physical Linux server as is which included any raw disk and all , is to use the VMware Convertor Cold Clone (coldclone.3.03.iso). Unfortunately, the last version that was released was for vSphere 4.1, Cold Clone 3.0.3.

The Cold Clone ISOs have been discontinued and support has been removed from VMware. and all support to the Cold Clone product is stopped. For the strong hearted, you can fiddle around with the Cold Clone ISO from the below links

https://www.vladan.fr/free-tools-vmware

More information about the VMware Convertor Cold Clone can be found at
https://www.vmware.com/pdf/convsa_50_guide.pdf

Use Case – Migrate from Physical Linux / Oracle OVM running Linux to VMware vSphere

The goal of this exercise is to find out if we can migrate a database running on a Physical server / Virtual Server (VMware/Oracle OVM) running Linux O/S to vSphere Virtual Machine (VM) running Linux O/S with the source database storage either on

  • a filesystem (e.g ext3 / ext4) or
  • Oracle Automatic Store Management (ASM)

Key things to keep in mind

  • Customers demand no change to be made to their source system as part of this P2V, the migration should be seamless to them
  • Migrating a database running on a Physical server / Virtual Machine (on VMware/Oracle OVM) running Linux O/S to a Virtual Machine (VM) running Linux O/S with the NFS as database storage is an easy migration from a storage perspective

Oracle Virtual Machine (OVM)

Oracle VM is a platform provided by Oracle Corporation that provides an environment for running Oracle Virtual Machines (OVM).

For all migration purposes of Oracle OVM to VMware vSphere, treat the OVM machine as a physical server and perform the P2V ie bring up the Oracle VM on the Oracle VM Server and perform a P2V treating it as a physical server.

More information about the Oracle VM can be found at
https://docs.oracle.com/cd/E64076_01

Oracle VM 3.4.4. Architecture

The components of an Oracle VM 3.4.4. environment is as shown below.

https://docs.oracle.com/cd/E64076_01/E64081/html/vmcon-ovm-arch.html

Oracle VM Manager is used to manage Oracle VM Servers, virtual machines, and resources. Oracle VM Manager is usually hosted on a standalone computer.

Oracle VM Server is a managed virtualization environment providing a server platform which runs virtual machines, also known as domains.

Oracle VM Manager communicates with each Oracle VM Server via the Oracle VM Agent.

 

Lab Setup – Oracle VM Server and Oracle VM Manager

The example shown below is a P2V exercise of 2 Oracle databases running in Oracle VM 3.4.4 on OEL 7.3

  • ‘DB1’ using Oracle ASM as database storage
  • ‘DB2’ using ext4 filesystem as database storage

Both Oracle VM Server ‘OVM_SERV344’ and Oracle VM Manager ‘OVM_MGR344’ are embedded in vSphere VM’s as part of the setup.

A vSphere VM named ‘OVM_SERV344’ running Oracle VM Server 3.4.4 was setup as per Oracle documentation, with 16 vCPU, 64 GB RAM.

The Oracle VM agent is also installed in the same VM as the VM server.

(Ignore the VMware tools warning, we are more interested in the OVM migration aspect of this exercise)

A vSphere VM named ‘OVM_MGR344’ running Oracle VM Manager 3.4.4 was setup as per Oracle documentation, with 4 vCPU, 16 GB RAM.

A guest VM ‘OL73’ is created in the Oracle OVM 3.4.4 environment (Oracle VM Server) running O/S OEL 7.3 and Oracle Database 12.2 software.

The OVM ‘OL73’ VM has the below storage

  • 30GB for O/S and Oracle binaries (GI/RDBMS)
  • 20GB for an ext3 Filesystem housing a database ‘DB1’ datafiles
  • 25GB for Oracle ASM storage housing a database ‘DB2’ datafiles

 

OS disks

[root@ora73 ~]# fdisk -lu
….
Disk /dev/xvda: 32.2 GB, 32212254720 bytes, 62914560 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000b5739

Device Boot      Start         End      Blocks   Id  System
/dev/xvda1   *        2048     2099199     1048576   83  Linux
/dev/xvda2         2099200    62914559    30407680   8e  Linux LVM
….
Disk /dev/xvdb: 21.5 GB, 21474836480 bytes, 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0xe2e5cd88

Device Boot      Start         End      Blocks   Id  System
/dev/xvdb1            2048    41943039    20970496   83  Linux
….
Disk /dev/xvdc: 26.8 GB, 26843545600 bytes, 52428800 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x362c02ac

Device Boot      Start         End      Blocks   Id  System
/dev/xvdc1            2048    52428799    26213376   83  Linux
……
[root@ora73 ~]#

 

Partition / Volume / Filesystem Layout

[root@ora73 ~]# lsblk
NAME                      MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda                      202:0    0  30G  0 disk
├─xvda1                   202:1    0   1G  0 part /boot
└─xvda2                   202:2    0  29G  0 part
├─ol-root               249:0    0  26G  0 lvm  /
└─ol-swap               249:1    0   3G  0 lvm  [SWAP]
xvdb                      202:16   0  20G  0 disk
└─xvdb1                   202:17   0  20G  0 part
└─vg_u01-LogVol_u01     249:2    0  20G  0 lvm  /u01
xvdc                      202:32   0  25G  0 disk
└─xvdc1                   202:33   0  25G  0 part
xvdd                      202:48   0  25G  0 disk
└─xvdd1                   202:49   0  25G  0 part
└─vg_dbmnt-LogVol_dbmnt 249:3    0  20G  0 lvm  /dbmnt
[root@ora73 ~]#

Oracle ASM disk

[root@ora73 ~]# /usr/sbin/oracleasm listdisks
DATA_DISK01
[root@ora73 ~]#

Lab Setup

  1. 2 Oracle databases exists on an OVM Linux ‘ora73’ , DB1 and DB2
  2. Database ‘DB1 uses Oracle ASM as storage
  3. Database ‘DB2’ uses ext4 File system as storage
  4. Boot partition is on /dev/xvda1 in OVM VM i.e. separate partition, no volume or LVM
  5. Oracle binaries are under /u01 (/dev/xvdb1)
  6. ‘DB1’ database storage is on Oracle ASM (ASM disk ‘DATA_DISK01’) which is on /dev/xvdc1
  7. ‘DB2’ database storage is on ex4 file system ‘/dbmnt’ which is on /dev/xvdd1

Red Hat 7 / OEL 7 Recommended Partitioning Scheme

Red Hat recommends that you create separate file systems at the following mount points on AMD64 and Intel 64 systems:

  • /boot – recommended size at least 1 GB
  • / (root)
  • /home
  • swap

The partition mounted on /boot contains the operating system kernel, which allows your system to boot Red Hat Enterprise Linux, along with files used during the bootstrap process. Unlike other mount points, using an LVM volume for /boot is not possible – /boot must be located on a separate disk partition.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/sect-disk-partitioning-setup-x86#sect-custom-partitioning-x86

 

P2V Steps

  1. Start VMware Convertor tool

Remember to enable root login over SSH for Oracle OVM ‘ora73’.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/V2V_Guide/Preparation_Before_the_P2V_Migration-Enable_Root_Login_over_SSH.html

2. Click ‘Convert Machine’ tab on menu

Select ‘Powered on’ & ‘Remote Linux Machine’ , Click on ‘view source details’

Press ‘Close’ , enter root password for ‘OL73’ and Press ‘Next’

3. Select ‘folder’ where you want to place the VM

Choose ‘ora73_p2v’ as the destination VM, as I had a common DNS server in my lab, I ran into DNS issues and hence decided to go with a different VM name.

4. Select the destination Datastore for the VM

5. Edit the options and review the destination partition / volume layout options. Click on advanced. After re-arranging  the designation layout to match the source , the final layout looks like

Key Observations from GUI

  • /boot is allocated as a partition on its own disk ie /sda1 (VirtualDisk1)
  • No option to leave /boot as a partition with /(root) & swap on same disk as in source
  • Root (/) and Swap are assigned to a LVM on a different disk (VirtualDisk2)
  • /u01 is on a separate disk as source (VirtualDisk3)
  • /dbmnt is on a separate disk as source (VirtualDisk4)
  • Where is the Oracle ASM disk i.e. source disk /dev/ xvdc1? We do not see it here?

6. Proceeding with the rest of the steps, adjust the vCPU and Memory allocations as needed

PVSCSI drivers would have to be installed via VMware Tools after the VM is created.

7. Choose appropriate network adapters

VMXNET3 network adapter is available as target network adapter.

8. Option of powering off source or destination machines

9. Setup destination Networking

Turn off IPV6 if needed

Setup search domains

10. Confirm

11. Submit Job

12. Destination VM created. Power it up

13. Check out the partitions / volumes on the target VM

[root@ora73 ~]# lsblk
NAME                    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                       8:0    0    1G  0 disk
└─sda1                    8:1    0    1G  0 part /boot
sdb                       8:16   0   29G  0 disk
└─sdb1                    8:17   0   29G  0 part
├─vg_u01-root         249:2    0   26G  0 lvm  /
└─vg_u01-swap         249:3    0    3G  0 lvm  [SWAP]
sdc                       8:32   0   20G  0 disk
└─sdc1                    8:33   0   20G  0 part
└─vg_dbmnt-LogVol_u01 249:1    0   20G  0 lvm  /u01
sdd                       8:48   0   20G  0 disk
└─sdd1                    8:49   0   20G  0 part
└─ol-LogVol_dbmnt     249:0    0   20G  0 lvm  /dbmnt
sr0                      11:0    1 1024M  0 rom
[root@ora73 ~]#

Key Observations from Target VM

  • /boot is allocated as a partition on its own separate disk i.e. /sda1
  • Root (/) and Swap are assigned to a LVM on a different disk (sdb)
  • /u01 is on a separate disk as source (sdc)
  • /dbmnt is on a separate disk as source (sdd)
  • ASM disk is missing and so database ‘DB1 which uses Oracle ASM as storage is not available at destination VM i.e. /dev/xvdc1 is not P2Ved over
  • Database ‘DB2’ which uses ext4 File system as storage is brought over to the destination VM

Reason for Oracle ASM disks not P2Ved over

Basically, the p2v process will not p2v the ASM disks because they aren’t mounted filesystems i.e. no volumes created on them.

In order to get the contents of the raw disk i.e. ASM in this case, to the target vSphere VM

  • Use VMware Convertor Cold Clone if possible
  • If VMware Convertor Cold Clone is not possible
    o             Shutdown ‘DB2’ on physical sever & add ASM disk of physical server as physical RDM to target VM
    o             Create new ASM disk group on target and add the new p-rdm to it
    o             Create and add new vmdk/s to newly created Oracle ASM disk group
    o             Use ASM rebalance method to relocate ASM disk extents from p-rdm to vmdk
    o             Offline drop ASM disks related to the p-rdm
    o             Remove and reclaim the p-rdm

Key points to take away from this blog

  • VMware Convertor tool transforms your Windows- and Linux-based physical machines and third-party image formats to VMware virtual machines.
  • Hot cloning method using volume based cloning at file level does not bring over raw disks from source server to target VM
  • Hot cloning method using volume based cloning at block level is only supported for Windows
  • Disk-based cloning is supported for existing virtual machines.
  • Cold clone will bring over the source VM to the target vSphere platform as is but cold clone is currently de-supported

Conclusion

VMware Convertor tool is one of most widely used tools in the industry today to migrate applications from physical servers to VMware Virtual Machine (VM) , the process known as P2V (Physical to Virtual).

It has certain limitations porting over Linux raw disks when using hot cloning method using volume based cloning at file level for powered on physical Linux servers. However cold cloning will ensure the resulting virtual machine is an exact replica of the source physical machine.

For Oracle ASM portability, use VMware Convertor cold clone method or use Oracle ASM rebalance method as explained above.

Similar Posts