Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

Convert existing VMware RDMs to VMDKs without downtime

Created: 15 Feb 2013 • Updated: 15 Feb 2013 | 3 comments
Language Translations
Virtually_LG's picture
+4 4 Votes
Login to vote

One of the requested operations that seems to be popular at the moment is how to migrate existing RDMs to VMDKs, especially more so since Veritas Cluster Server 6.0.x now supports VMDKs .  In this two part article we shall take a look on how to achieve this with the first part highlighting how to convert RDMs to VMDKs on a standalone VM with minimal downtime using Storage Foundation. The second part will take a look at what steps need to be taken when Veritas Cluster Server is in the mix.

Let’s take a look at a typical virtual machine that has a RDM attached and walk through the steps needed to migrate the data from RDM to VMDKs

In Fig 1 a virtual machine would typically have RDMs attached to them these would be in either virtual or physical mode.

Fig 1 – RDM configuration for a virtual machine

From within the virtual machine the RDM would be seen as a disk and within the disk there would typically be a number of volumes that would contain the data for the application, the example show is for SQL 2008. A number of mount points had been created within a drive letter for the SQL instance and it is these volumes that will be live migrated to the new VMDKs.

 

Fig 2 – Storage Layout for SQL2008 from within a virtual machine

 

On the virtual machine add new VMDKs that will be used for the new placement of the application data.

 

Fig 3 – Adding VMDKs to the configuration of a virtual machine

 

Inside the virtual machine notice that the new disks will be seen, perform a rescan or the SCSI bus if required. Once Disk Signatures have been written with the Veritas Enterprise Administration UI the new disks can be added to the Dynamic Disk group which currently holds the volumes for the SQL application, “PROD” in this case.

 

Fig 4 –Adding VMDK disks to the Dynamic Diskgroup configuration for a virtual machine

 

Once the new disks are added to the diskgroup then data can be started to live migrate from the RDM disk to the new VMDK disks. This Subdisk move process will leverage a feature of Storage Foundation called SmartMove, this will assist in copying over only the writen blocks on the RDM to the new disks instead of all blocks from the volumes which a traditional block copy method whould use, this SmartMove process will reduce the data migration process especially if the writen blocks are much less then the overall disk size that’s being moved.

Fig 5 – New VMDKs ready for volume migration

 

The process of moving subdisks with the Veritas Enterprise Administrator is possible to use a drag and drop method for the sub disks from one disk to another but with multiple operations and also for accuracy it’s much easier to do this via CLI and create a script to do this.

 

Fig 6 – Moving a volume subdisk by dragging and dropping

 

Finding the subdisks that need moving from the CLI can be achieved by using the command vxprint as highlighted below.

 

C:\Users\administrator.WINDOM>vxprint


Diskgroup = PROD

TY NAME         ASSOC        KSTATE   LENGTH(KB)   PLOFFS   STATE    TUTIL0  PUT

IL0

sd Disk3-01     PROD_MNT-01   ENABLED  204800   0        -        -       -

sd Disk3-02     PROD_DATA-01   ENABLED  2097152  0        -        -       -

sd Disk3-03     PROD_REG-01   ENABLED  1024000  0        -        -       -

sd Disk3-04     PROD_DB-01   ENABLED  2097152  0        -        -       -

sd Disk3-05     PROD_LOG-01   ENABLED  1843200  0        -        -       -

sd Disk3-06     PROD_MNT-01   ENABLED  818610   204800        -        -       -


dm Harddisk1    Disk1        -        4192193  -        -        -       -

dm Harddisk2    Disk2        -        4192193  -        -        -       -

dm Harddisk3    Disk3        -        62652349 -        -        -       -

dg PROD         PROD         -        -        -        -        -       -

v  PROD_DATA    -            ENABLED  2097152  -        ACTIVE   -       -

pl PROD_DATA-01 PROD_DATA    ENABLED  2097152  -        ACTIVE   -       -

v  PROD_DB      -            ENABLED  2097152  -        ACTIVE   -       -

pl PROD_DB-01   PROD_DB      ENABLED  2097152  -        ACTIVE   -       -

v  PROD_LOG     -            ENABLED  1843200  -        ACTIVE   -       -

pl PROD_LOG-01  PROD_LOG     ENABLED  1843200  -        ACTIVE   -       -

v  PROD_MNT     -            ENABLED  1023410  -        ACTIVE   -       -

pl PROD_MNT-01  PROD_MNT     ENABLED  1023410  -        ACTIVE   -       -

v  PROD_REG     -            ENABLED  1024000  -        ACTIVE   -       -

pl PROD_REG-01  PROD_REG     ENABLED  1024000  -        ACTIVE   -       -

 

The subdisks that need moving are subdisks Disk3-01 to Disk3-06, these will be moved to the new disks, the move operation is carried out with the command vxsd –g(DiskGroup) mv –b Disk03-01 Harddisk1, or vxsd -gPROD mv -b Disk3-01 Harddisk1 in the example shown below.

Fig 7 –Movement complete for the first subdisk using SmartMove.

Notice the –b in the command will carry out the command in the background so that multiple moves can be carried out in one go.

Fig 8 – Subdisk volumes being migrated with SmartMove.

 

Now that the volumes have been migrated the RDM can be safely removed from the VM, this can be carried out without powering down the VMs too using the hotplug features of vSphere.

Fig 9 – Final Storage migration complete

That’s all the steps needed to move the data from the RDM disks to VMDKs, in the next part of this article we shall take a look at the steps needed when Veritas Cluster Server is in the mix, 

Comments 3 CommentsJump to latest comment

Armando Crisafo's picture

Very useful article Lorenzo. Many thank indeed.

0
Login to vote
John Worachek's picture

LG,

In the example, are the RDM based LUNs under the control of VCS to begin with? or under the control of a 3rd party clustering solution from a different vendor?

 

Thanks-

-John

PS: good article...

0
Login to vote