Using TF/SnapVX to copy cold virtual machines

For the past month I’ve been updating the VMAX/PowerMax/VMware TechBook for both our new releases and VMware’s. It requires a lot of testing, screenshots, research, etc. so honestly it can get tedious. That’s why I like when I come across a section to update that is worth sharing ahead of time (or at least I think so). This one is about copying VMs through array technology, in our case TimeFinder. This section has been around since the beginning of this book which is too long ago to remember, but based on questions I get, a refresher never hurts.

I’m going to take you through a simple example of using TimeFinder/SnapVX to copy some VMs from one vCenter to another. Yes, there are lots of ways to copy VMs and what makes sense in one case may not in another, but this post is just about one of them.

SnapVX

Let’s start with an explanation of the Dell EMC technology TimeFinder/SnapVX. On the VMAX3, VMAX All Flash and PowerMax, beginning with Solutions Enabler 8.0.1, a single underlying technology called SnapVX provides the basis of TimeFinder which is our local replication software. SnapVX operations are performed using the symsnapvx command to create point-in-time copies (snapshots) of critical data. SnapVX creates snapshots by storing changed tracks (deltas) directly in the Storage Resource Pool (SRP) of the source device. With SnapVX, you don’t need to specify a target device or source/target pairs when creating a snapshot. If there is ever a need for the application to use the point-in-time data, you can create links from the snapshot to one or more target devices. If there are multiple snapshots and the application needs to find a particular point-in-time copy for host access, one can link and relink until the correct snapshot is located. SnapVX still supports all the old TimeFinder commands like clone through emulation, but it is best to transition legacy scripts to the new command to take advantage of the new capabilities. You can create up to 256 snapshots per device.

The process

When taking a snapshot, devices are managed as an atomic unit by creating a device group, composite group, or if all devices are in the same storage group that can be used. Composite groups must be used if the virtual machines that are being cloned use VMFS and/or RDM volumes from multiple VMAX or PowerMax storage arrays. Solutions Enabler or Unisphere for VMAX/PowerMax can be used to create the device group and to manage the snapshot process. Composite groups can only be created by Solutions Enabler. I’m going to use Unisphere for PowerMax with storage groups for this example because it is by far the easiest way to do this. We’ve been encouraging customers to associate applications to storage groups so that the storage group becomes the unit of local copy, remote copy, or backup. Also, on the PowerMax service levels are set at the storage group level, providing an additional reason to keep application devices together. For customers who have an environment that mirrors mine more closely, you’ll find Solutions Enabler to be incredibly flexible and that example will be in the TechBook.

The environment

I never go crazy with the setup. It’s very easy to extrapolate if you know the steps so keep it simple works just fine.

• PowerMax array
• 2 vCenters – production and backup
• 3 devices
• 2 (250 GB) used for VMFS
• 1 (10 GB) used for RDM
• 2 VMs, 1 in each VMFS and 1 with an RDM

I’m also not scripting any activity here. Everything will be manual to demonstrate the steps. Once you understand how this works, you could script lots of this, much like Site Recovery Manager does for you.

So my 2 VMFS (VMFS_DEV_135, VMFS_DEV_136) and 2 VMs (VMFS_SNAP, VMFS_SNAP_2) are here:

So on with the steps.

Unisphere for PowerMax steps

The following presents the GUI steps required to copy a group of virtual machines utilizing SnapVX technology. Before beginning the process, gracefully shutdown any VMs running on the selected datastores and if the target devices on the backup vCenter are mounted as datastores, unmount them (unregistering VMs first of course).

• In Unisphere for PowerMax navigate to the Storage Groups page under the Storage menu on the left-hand side. Check the box next to the correct storage group name and select Protect from the options in the sub-menu like below.

• In the next step, navigate through the three step wizard:
  1.  Select Point in Time using SnapVX
  2.  Type in the snapshot name
  3.  Run the job
  Unisphere for PowerMax has other options available (which are also available through CLI), but for this example below, the defaults are taken.

• The next step is to link the snapshot. Navigate to the SnapVX Snapshots screen of the selected storage group or simply to the Storage Groups menu under Data Protection. Check the box and select Link. In step 3 choose the existing storage group with the target devices and run. If you do not have a storage group created with the necessary devices, Unisphere will do it for you if you choose a new group instead. The steps are here:

• The copy is now complete. The devices can be presented to a VMware environment, therefore on to the next section…

Presenting the copy to VMware

As mentioned, in the following steps, a backup vCenter is utilized, however copies can be presented back to the original vCenter. In such cases it is important to understand how duplicate extents work which I won’t cover here but are in the TechBook (even the current one).

• Whether you let Unisphere create a new storage group or used an existing one as I did, create a masking view which will present the copied devices to the backup vCenter.

• Rescan the ESXi hosts on the backup vCenter so the devices are discovered.

• Once the devices are available, the two 250 GB with VMFS partitions can be mounted. As vSphere queries the devices during the create datastore wizard, it will recognize that the two copied devices have existing VMFS partitions on them. In so doing, it will show them as Snapshot Volumes, noted below in the red box. The single RDM is also shown in the blue box. As it has no VMFS extent VMware does not recognize a Snapshot Volume.

• Select one of the snapshot volumes from above and click through to the next screen. Here the user will be given three options:
  1.  Assign a new signature
  2.  Keep existing signature
  3. Format the disk
  Dell EMC recommends assigning a new signature to prevent any duplicate extents in the future. If the devices have been presented to a different vCenter, however, it is possible to keep the existing signature. Note that it is unnecessary to type a new datastore name as VMware automatically generates one.

• Repeat the process for the second snapshot volume. VMware will automatically assign a prefix to the volume names, snap-xxxx-. Yes, you can tell VMware not to use the prefix – that information is in the SRA TechBook if you don’t want to have to rename the datastore. The newly mounted volumes are in red.

• Once the volumes are mounted, register the virtual machines. In this example there is a VM in each mounted datastore. Although the VMFS_SNAP VM has an RDM, it is still registered normally.

• As one of the VMs has an RDM, a further manual step is required since the pointer in the vmx file is no longer valid as it points to the original RDM which is not presented to this environment. Edit the VM, and notice that the RDM device is now showing 0 and has an error below.

• Delete the existing Hard disk 2 including the file, and add a new RDM, selecting the snapshotted device from the list. The steps are here:

• The VM can now be powered on successfully.

This process may be old hat for many users but based on my emails, there are still plenty of customers who are not aware of how this works. Anyway I got a couple chapters left of the TechBook so I’m thinking perhaps in the next couple weeks I can get it out there. You can be sure I’ll post when it does.

Advertisement