VMFS Snapshots and the FlashArray Part VI: Mounting a FlashArray VMFS Snapshot

This is part 6 of this 8 part series. Questions around managing VMFS snapshots have been cropping up a lot lately and I realized I didn’t have a lot of specific Pure Storage and VMware resignaturing information out there. Especially around scripting all of this and the various options to do this. So I put a long series out here about how to do all of this.

The series being:

  1. Mounting an unresolved VMFS
  2. Why not force mount?
  3. Why might a VMFS resignature operation fail?
  4. How to correlate a VMFS and a FlashArray volume
  5. How to snapshot a VMFS on the FlashArray
  6. How to mount a VMFS FlashArray snapshot
  7. Restoring a single VM from a FlashArray snapshot

Using vCenter and our Web Client plugin, recovering a snapshot is a pretty straight forward process. So the pre-requisite here is having our Web Client plugin installed and configured. Info on that here. If you want to know the manual steps, scroll down further and the whole process is described in detail that does not use the plugin–just our GUI and vCenter.

So, in this case, I have a few VMs on a datastore called “ProdVMFS”:

Something goes wrong on my VM called “AppServer” so I need to bring up a copy of the datastore it sits on.

Mounting a Snapshot with the FlashArray Web Client Plugin

When the datastore object is selected in the vCenter inventory, I can choose the FlashArray Snapshot tab (this is under “Related Objects” in vCenter versions prior to 6.5) and see the available snapshots.

There are a variety of options here, but what I want is to choose “Copy to New Datastore”. This will follow this procedure:

  1. Copy the snapshot to a new volume
  2. Connect the new volume to host group on the FlashArray that corresponds to the cluster chosen.
  3. Rescan the cluster
  4. Resignature the VMFS
  5. Rename the resignatured name to whatever was entered

Confirm then populate the wizard. All you really need to enter is a new name and then a cluster to mount it to.

Now let it finish. The snapshot is now recovered!

Manual Process

If you want to follow the manual process (whether to build a script etc.) or don’t use the plugin for some reason, here is the detailed process.

First identify the underlying FlashArray volume, you can do this with one of the methods described in this post here.

Once done click on the volume in the GUI and identify the snapshot you want. The choose the option “Copy Snapshot”.

Enter in a new volume name. This name will be assigned to the new volume that is created from the snapshot image. I am using my original volume name plus the suffix of “Copy”.

Next, click on the new volume and then connect it to the proper host group or host that you want to recover it to. If you are using it to restore a VM or entire datastore or a single virtual disk, attach it to the same host group as the source volume.

Then choose the host group(s) (or hosts).

Now back to vCenter and rescan your cluster.

Make sure you choose the default options to scan for new devices and VMFS volumes.

Lastly, in the same menu, choose “New Datastore”.

Choose VMFS and the next.

Find the proper device in the next screen, match the NAA to the FlashArray volume,  you will also see the original VMFS name in the “Snapshot Volume” header. Don’t bother entering a new name, as the datastore will always just get the resignature name of (snap-<identifier><original VMFS name>.

The last part is to choose the resignature option. It is NOT the default selection, so make sure to choose “Assign a new signature”.

The process will complete and the datastore will be ready for use/recovery:

14 Replies to “VMFS Snapshots and the FlashArray Part VI: Mounting a FlashArray VMFS Snapshot”

  1. Hi Cody

    You have some great blogs on here, incredibly helpful.
    I have a question which isn’t completely related (but kind of).
    Here goes.

    I have a scenario I wonder if you can help with please?

    Basically a number of VMs with datastores on array,
    take VMware snapshot,
    take array based snapshot of relevant luns on the array,
    delete vmware snapshot
    replicate array snapshot luns to another array at the remote site
    backup luns at remote site using networker. (Networker is running on a Windows server)

    This used to be achieved by using NDMP on the remote site array, but now we have a new array that doesn’t support NDMP.

    Is there any way we can mount the target arrays luns, to back them up?

    Or is there a better way to achieve this?

    Not currently using VVOLs, although even though that makes the whole process better, I’m not sure it completely achieves what we want.
    Thanks

    1. Thank you! Glad they are helpful! I suppose you could mount the VMs on the far site and back them up directly from using VADP and your backup solution. Then unregister and delete the datastore until the next backup window. That might require some scripting. That being said, most backup products can do a backup offload of VMs with using NDMP, but without knowing the particulars of the backup solution and the array it is hard for me to say. Rubrik and Commvault can do this quite well. Might be best to ask your Networker resource. sorry if that is not a great answer 🙁

  2. Hi Cody,
    Great series.
    I’m looking to achieve this and part 7 through powershell.
    Does one of your modules have the ability to mount a FlashArray VMFS Snapshot to a new datastore connected to a host?

    New to Pure Storage and I’m going around in circles trying to figure out if/how that step can be done through powershell.

    Thanks and regards
    Jeremy

      1. Thanks! Works perfectly. I was looking through that module but hadn’t figured out the correct cmdlet to use…
        🙂

  3. Hi Cody,

    Great post as usual.
    I am trying to follow the same procedure in my environment but I get an error stating that the LUN cannot be resiganatured because there are duplicate extents (LUNs).
    What I see is that we end up with two LUN eui.111111111 and eui.222222222 bot h having the same Label (Datastore name).

    If I hexdump the LUNs, they both show the same name.

    hexdump -C /dev/disks/eui.111111111 -s $((0x1400000)) | less

    hexdump -C /dev/disks/eui.222222222 -s $((0x1400000)) | less

    I want to recover the snapshot LUN and mount it as a different datastore.
    Shouldn’t PURE put a different label in the LUN when we copy the snapshot?

    Best regards,

  4. Thanks Kenneth.

    The label is given by VMware–which is the original datastore name. So not something that we apply. VMware has a limitation of not being able to resignature a volume is there happens to be two unresolved (i.e. not yet resignatured) volumes present. I talk a bit about that here. https://www.codyhosterman.com/2016/01/vmfs-snapshots-and-the-flasharray-part-iii-why-might-a-resignature-fail/

    So the only option here is to only present a single unresolved copy at a time and resignature them one at a time. You might be able to “detach” the device in ESXi and then do it, but I have not tried that.

  5. Hi, we are trying to snap a vmdk volume that belongs to a server A and copy that snap to a vmdk volume of server B on daily basis. Can you please suggest how we can achieve this especially with re-signature? Thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.