PPME PowerMax to PowerFlex – virtual

This is the second example from the post which introduced you to PowerPath Migration Enabler, or PPME. While the first example was a migration on a physical host, by far the more common scenario, for the second example, I’m going to move data within a VMware VM from PowerMax to PowerFlex. Yes, these are the same storage platforms as before because, well, that’s all I got! I suppose I could show the reverse from PowerFlex to PowerMax but I want to keep the symmetry with the physical post. 

Environment

For this setup, I considered two different scenarios for the PowerFlex side. For PowerMax, I am presenting storage and adding physical RDMs to the VM. For PowerFlex, however, I could show a migration in one of two ways:

1. RDM to RDM – present PowerFlex to the ESXi cluster and add RDMs to the VM
2. Install the SDC on the Linux VM and then present the devices 

Either of these will work with PPME (it doesn’t know the difference anyway), but I decided to keep this as a purely VMware example. Customers currently using RDMs would probably want to keep them because using devices outside of VMware’s knowledge gets complicated. Also, if the customer decided to add replication and use VMware SRM, they’d need RDMs.

So below are the details of this virtual setup for both source and target. Once again I will run Oracle because RDMs are a choice some customers still make with that software, whether they use them directly or via ASM (my configuration). I’ll do the migration in two parts. The first will be using PPME to move the RDMs, and then I’ll run a Storage vMotion to relocate the VM from a PowerMax datastore to a PowerFlex datastore.

Source

• VMware vSphere vCenter 7.0.3 Build 20395099
• VMware ESXi, 7.0.3, 20036589 with (4) hosts in a cluster
• FC connectivity to the PowerMax 8500
• A masking view to the vSphere cluster with (1) storage group containing:
  • (4) 30 GB devices
• Oracle 21c installed on the local device – both Grid and Database as I am using ASM
  
  • Oracle database “orcl” created on ASM
• PowerPath version 7.5 (build 95)

VM – dsib2028.drm.lab.emc.com

Not critical, but here are the specs:

• Guest OS: Red Hat Enterprise Linux 8 (64-bit)
  • RedHat Release 8.3 (kernel 4.18.0-240.el8.x86_64)
• Compatibility: ESXi 7.0 U2 and later (VM version 19)
  
• VMware Tools: Running, version:11296 (Current)
• 4 CPU, 16 GB RAM
• (1) 250 GB device on a PowerMax datastore
• (4) 30 GB PowerMax RDMs
• (4) 32 GB PowerFlex RDMs

Target

• PowerFlex version 3.6.600
  • Multi-node, custom configuration Linux/ESXi
  • sdc-3.6.500.106-esx7.x
• Four devices mapped to the ESXi hosts. Recall PowerFlex creates devices in increments of 8 GB so we want them equal or larger than our PowerMax devices.
  • (4) 32 GB devices
  • (1) 400 GB device (PowerFlex datastore for SvMotion)

Oracle

As noted, the Oracle database is running across the four presented devices using ASM (+DATA is the group), each of which has been claimed by PowerPath – emcpowera through emcpowerd.

After modifying the ownership of the devices to oracle:oinstall (755), during the Oracle Grid installation I change the discovery path and use the devices for the ASM disk group:

And here is the database running in EM.

PowerFlex storage

On the PowerFlex side, here are the four 32 GB devices, mapped to the four ESXi hosts (# SDCs column below):

I then present them to the vSphere cluster and add them as RDMs to the VM. Here are our 8 RDMs then.

After adding the new RDMs, PowerPath claims our PowerFlex devices as: emcpowere, emcpowerf, emcpowerg, and emcpowerh.

Migration

I’m going to conduct the first part of the migration in the same manner as the physical PPME by using the bulk flag -all, particularly as I’m migrating four devices. Once the process is complete, I’ll remove the PowerMax RDMs from the VM, remove the PowerPath devices from their dead state, and then proceed with the second part, the Storage vMotion of the VM to PowerFlex. Remember that even though we are using RDMs, VMware still uses a pointer file in the datastore so when we migrate the VM we do the whole thing, not just the 250 GB vmdk.

As with the last migration on a physical host, functionality is the prime goal here not performance. For the demo, just FYI, as I have been told over the years I’m a soft speaker, I always crank the mic so you may have to lower your volume.

Demo

 

Advertisement