Oracle VM 3 for X86 / Backend Storage Migration

Have to migrate a bunch of OVM3 X86 Clustered Server Pool and their VMs (Virtual Machines) from one storage to another (From EMC Clariion to EMC Symmetrix VMAX) and decided to document what I did to complete such migration. 

Before starting with the technical details, let's me first explain why such Migration Path isn't really straightforward. In a clustered configuration, Oracle VM needs at least 02 type of shared disk to work:

1. The first type of shared disk is used by Server pool, It contains the File-system that is used to store all the Cluster related configuration. It's to be noted that only one of this type of disk is required per Server Pool. I refer to that Filesystem below as Server Pool Filesystem
2. The second type of shared disk is to be used as Repository for Oracle VM System, It contains everything related to the VMs (Virtual Disks, VMs configuration, ISO...). We can have many of this type of disk per server pool. I refer to that type of Shared Disk below as Storage Repository.

As you might already have guessed, Migrating Data that are on the second type of disk isn't the main challenge here. The main challenge is related to the first type, the main reason being that there's no clear documented procedure to complete Server Pool Filesystem Migration. 

In the first section below, I'll describe the current Environment, I mean by that the Environment I'm willing to migrate from old Backend Storage (EMC Clariion) to new Backend Storage (EMC Symmetrix). In the Second section, I'll deal with the Storage Repository Migration and in the third section, I'll try to describe what I see as the main challenge, the Server Pool Filesystem Migration.

1. Environment Description:

The server Pool that we're willing to migrate here is made of 02 HP Proliant Nodes in a Clustered Server Pool , Its pool FileSystem is connected through a Fiber Channel SAN and has a size of 15Gb. The Pool name is HP_Bay2_bay3_Pool and the 02 OVM Servers name are ovms-bay2 and ovms-bay3. Below is a screenshot of its Info section on OVM Manager.

On the following screenshots, we see that there's 03 VMs (stiv-vm1,stiv-vm2 and stiv-vm3) running under these Systems. The three VMs are hosted on 02 Storage Repositories (DC1_HP_HA_TEST-DEV_repo1 & DC1_HP_HA_TEST-DEV_repo2). 

The following table serves as a summary of what we'll be doing during this Migration, My suggestion is to always have such a Table during this Type of Migration.

Type	Source	Destination
Server Pool	HP_bay2_Bay3_pool	DC1_VMAX_HP_Bay2_Bay3_pool
Storage Repository	DC1_HP_HA_TEST-DEV_repo1	DC1_VMAX_HP_Bay2_Bay3_repo1
Storage Repository	DC1_HP_HA_TEST-DEV_repo2	DC1_VMAX_HP_Bay2_Bay3_repo2
VMs to Migrate	stiv-vm1; stiv-vm2; stiv-vm3

2. Storage Repository Migration:

The strategy used for the Storage Repository Migration is to create another Storage Repositories coming from the new Storage and migrate VMs and their Data to these Storage Repository. 
So the obvious first step here is to allocate LUN from the new storage to our Clustered Nodes. In this case, we've 02X01TB Storage Repositories on the Source Storage (EMC Clariion), we'll create the same on the target Storage (EMC Symmetrix VMAX). We'll also add in addition a small 15Gb that'll be used in the next section (Server Pool Migration). This is a screenshot of these FC LUNs after their SAN/Storage Allocation. 

Just to have these new LUNs clearly identified, I've renamed with the friendly names follow

Once these LUNs are allocated, we'll create 02 new storage repositories on them and assign to the the source server pool. Below is the screenshot for the creation of one of these 02 storage repository.

Now that the Target Storage Repositories have been created, we can migrate each VM to this target Repository by using the Clone or Move Option as shown below, note that this procedure required the Machine to be halted during the Migration. 
Also, to avoid trouble during the Server Pool Filesystem migration,we must move all Files (including virtual machine configuration file) related to a single VM under the same Storage Pool (avoiding errors like "com.oracle.ovm.mgr.api.exception.RuleException: OVMRU_002061E Cannot remove clustered file system: ..., from cluster: ... Virtual machine: ..., contains ..., which is in the other clustered file system.")

Note that the Target Repository on the "Clone or Move Virtual Machine" below  is the target location of the virtual machine configuration file.

Once we've all the VMs Migrated from the old storage(s) repository(s), we should un-present this(these) storage(s) Repository(s) from the Server Pool. For that, we just have to select the Storage Repository and use "Present-Unpresent Selected Repos" as seen below. That'll mostly be to make sure that that Repository(s) doesn't hold live data.

3. Server Pool Filesystem Migration:

With The Data in Storage Repositories migrated, we can get to the next step which is the Migration of the Server Pool FileSystem. As previously said, there's no Direct Migration Path for this part, so we're using a trick which consists of creating a new server pool with a new pool file system and then migrating the existing Physical OVM servers  to this new server pool.

Meaning that the first step to take is the creation of a new Server Pool, Note that an additional Virtual IP is needed during this Server pool creation. The new Server Pool is created with no Physical OVM Servers added to it.

Having now a brand new Target Server Pool, we can go through the following 07 steps to complete the Migration, note that it's better to have the OVM VM Servers stopped.

3.I: Un-present one of the Clustered Server from the new Storage Repository

For that, we're editing the new repository as shown below. The same must be done on all the others new Storage Repository.

3.2: Assign the new Server Pool to the new Storage Pool

This is done by editing the new Repository(s) and Change the Server Pool to the new one. Again, it must be done for all the new Repository.
As said in the previous section, If one of the configuration (even Simple CD/DVD) of one of the VM isn't part of the same Repository, this action might fail.  

So, again, in case we're facing error similar to the following ("com.oracle.ovm.mgr.api.exception.RuleException: OVMRU_002061E Cannot remove clustered file system: ..., from cluster: ... Virtual machine: ..., contains ..., which is in the other clustered file system."), we must make sure that all configuration/file related to a VM are part of the same repository 

3.3 Delete the old Storage Repository

This deletion is needed  to complete Step 3.4 which removes all Servers from the old Clustered Server Pool. As no server is available to perform that request on the old Storage Repository, we must re-assign at least one of our Server to complete this task. Note that Storage Repository must be emptied before deletion.

3.4 Remove all the Cluster Server from the Old Server Pool

The Old server pool will have no OVM VM Servers assigned to him after this step, and OVM VM servers which were assigned to the Pool will be under "Unassigned Servers". This is done by editing the Old Server Pool.

3.4 Add these Servers to the New Server Pool

Edit the new Server Pool, under Servers Tab, Select the OVMS Servers that were removed in the previous step

3.5 Present new storage Repository(s) to new Server Pool

Edit the New Storage Repository(s) and select the new Server Pool, send that (using ">") to the "Present to Server Pool(s)"

3.6 Power On and check your VMs

3.7 Delete the old Server Pool (and if needed, disconnect the nodes from the old Storage)



References:

I'd like to highlight the fact that I relied heavily on this document  which is written by a Dell engineer who performed similar Migration on Dell Storage.