May 19, 2012

Removing VM snapshots left by CommVault or NetApp

Since I tend to focus on CommVault and NetApp this post is mentioning those two products in particular, but if you’ve used any VM level backup product that quiesces the VM prior to taking the backup – you have likely seen that these VMware snapshots aren’t always removed by the application.  I’ve seen a few different ways to handle this, but since I am a beginner at PowerShell I thought I’d see how I could remove them without using the vSphere Client.

This all started due to a power outage over the weekend in the middle of a VMware backup so I was left with a number of VM’s with the all too familiar ___GX_BACKUP___ snapshot name which I determined by running the following command:

Get-VM | Get-Snapshot | Select Name,VM,SizeMB

Output from PowerCLI showing the existing VM snapshots

This part didn’t tell me anything that I didn’t already know, I have a number of VM snapshots that are left behind from CommVault all with the same snapshot name.  In this particular case I had a backup job that failed, so it had already created the snapshots but hadn’t done the backup which also meant it hadn’t yet come through and removed the VM snapshots.  Next up was running the following command to delete all of those snapshots:

Get-Vm | Get-Snapshot -Name __GX_BACKUP__ | Remove-Snapshot -Confirm:$false

Snapshots being committed

This should kick off a Remove Snapshot job if you have the vSphere Client open.  Let it run and you should have all of your VM snapshots initiated by CommVault committed to disk.

If you are using NetApp SnapManager for VI to backup your virtual machines, your snapshot name will be different.  Instead of ___GX_BACKUP___ it will be something along the lines of smvi_<string of numbers>.  To remove those snapshots you can run the following:

Get-Vm | Get-Snapshot -Name smvi_* | Remove-Snapshot -Confirm:$false

Keep in mind that will delete ALL snapshots that start with smvi_, if you have valid snapshots you’d like to keep that were taken by SMVI, that command isn’t for you.  That should be it, this is pretty basic but I seem to always have to deal with leftover snapshots so I wanted to document this for easy reference.

Popularity: 10% [?]

CommVault SnapProtect with NetApp NFS Volumes

Introduction

One of the newer features of CommVault Simpana is the ability to perform SnapProtect backups for various applications such as Exchange, SQL or VMware.  This post will focus on VMware and specifically on virtual machines that are on a NFS datastore hosted on a NetApp storage array.

If you aren’t familiar with SnapProtect it allows you to take hardware based snapshots called from CommVault.  Being a NetApp reseller, I would compare it to providing SnapManager-like functionality that you can control from within the CommCell console.  If you are already a CommVault shop I think there are some pretty compelling reasons to take a look at it (and if you are currently licensed by capacity then you really should be looking at it as there is no extra charge).  If you’ve seen CommVault’s demo video of taking a backup of 500 virtual machines in 17 minutes they are taking advantage of this functionality.  The only thing I would point out is if SnapProtect is your only method for backing up your virtual machines, all you are getting is a hardware based snapshot for a backup.  Ideally you should configure a backup copy to pull that data from the snapshot off the storage array and into your magnetic library within CommVault and ideally replicate it over to a disaster recovery location as well.  All of that is possible within CommVault, it just requires a few extra things to configure in addition to basic SnapProtect functions.

Configuration

One of the things we ran into immediately when configuring this was an issue over whether NFS was even supported (yet) with SnapProtect.  We were originally implementing this shortly after v9 was released and there wasn’t yet a lot of documentation on it.  NFS is fully supported as a datastore type for SnapProtect backups and hopefully this post will help with a few of the stumbling blocks you may hit while configuring it.

Initial SnapProtect error

The first challenge I hit was network related.  I installed the Virtual Server Agent on my Media Agent, which is on the server network VLAN (for the purposes of this post, I’ll use VLAN 10).  We have another VLAN specifically for NFS/IP storage traffic used in our vSphere environment (again, for the purposes of this post I’ll use VLAN 20).  Initially the media agent wasn’t configured on the storage VLAN 20 and the screenshot to the right shows the initial error I ran into.  Simple enough solution, the network link from the media agent to the switch was configured as a trunk link with access to VLANs 10 and 20.

Array Management Control Panel

Now that I had the media agent configured with a storage VLAN my next issue was it was still trying to use the server VLAN when it connected to the NetApp array.  This ended up being caused by how I setup the NetApp array within the Array Management Control Panel in the CommCell.  After removing the entry that was configured with a hostname and instead using the IP address of the storage VLAN on the NetApp I was able to successfully connect.  Lesson learned was this isn’t just a communication channel between the media agent and the storage device, it will match the IP address listed in the Array Management Control Panel to the datastore IP address that is used within vSphere.  One thing we didn’t run into, but that you should keep in mind, is if you are using IP aliases you would then need to add in multiple entries for the same NetApp host, one entry per IP alias.  It will continue on through the list trying to find a match so the order of the arrays within the Array Management Control Panel isn’t important.

Current Limitations

Having followed NetApp’s best practice guide the page file was on a separate VMDK file that was stored on a separate datastore in the vSphere environment.  Unfortunately today SnapProtect doesn’t support this, the VMDK files must all reside within the same datastore.  You also don’t have the ability to exclude a VMDK file or datastore, something that I hope will be added in a future release.  This is one area where NetApp’s SnapManager tool has an advantage as you can choose to not snap the volume used for pagefiles and keep your space used for backups to a minimum.  I like that approach so I can keep the snapshot sizes as lean as possible, I don’t need to backup transient data like the pagefile.  If you followed the (optional) recommendation in NetApp’s best practices for vSphere (TR-3749) you would need to storage vMotion it to the same datastore as the rest of the virtual machine files before continuing with SnapProtect.

Another limitation I’ve run into with NFS volumes and NetApp is that if you follow best practices and disable the setting for automatically exporting a volume copying the snapshot into your magnetic library will not work.  When you configure the backup copy to CommVault’s magnetic library it creates a FlexClone of the volume and that is what it will use to bring the data in.  Without the options nfs.export.auto-update value set to on it won’t have the necessary NFS permissions and will fail to mount that FlexClone into vSphere.  After installing CommVault SP2 recently I no longer have this issue, although I don’t see it mentioned in the release notes for the service pack.

The SnapProtect features are relatively new and hopefully these items are on the roadmap to change as it really is impressive seeing array level snapshots being orchestrated by CommVault.

Popularity: 19% [?]

VMware Data Recovery (vDR) for Home Lab

Overview

My goal was to backup my current VMware environment running on my NetApp FAS270 to a cheap 1TB SATA disk that is attached to the ESX host.  Space is at a premium on the NetApp so using NetApp backup tools isn’t an option.

vDR Documentation

vDR Download Link

Installation

vDR is pretty flexible with backup destinations – you can choose to back up VMs to a CIFS share, VMDK, or RDM.  As I mentioned before I wanted to have my backups on a 1TB SATA drive that I have connected into my whitebox ESX host.  What I liked about this approach is I can keep my “production” virtual machines on my NetApp FAS270 and the backups on the single 1TB SATA disk.  A few of the benefits of vDR:

  • Uses changed block tracking (if the VM hardware is version 7) to only send the changed data blocks to the backup destination
  • Ability to expand the storage destination on the fly (up to 2 1TB dedupe volumes per backup appliance)
  • Deduplication

My first step was to create a VMFS datastore on the 1TB SATA disk, knowing that you could have up to (2) 1TB dedupe volumes per backup appliance I formatted the datastore with a 4MB block size.

I ran into an issue creating a datastore on the SATA volume, it gave me an error that said “failed to get disk partition information” I found that the drive was using a GUID partition table and needed to resolve that (covered in a separate blog post).

At this point I had the datastore I wanted to use ready, and I had the ISO from VMware downloaded and mounted on my vCenter server (which is a VM).

Then click to install the Data Recovery Client Plug-In

After the install is completed open the vSphere Client and go to Manage Plug-Ins and make sure that VMware Data Recovery is enabled.

Now that the client is installed it’s time to install the vDR backup appliance, from the vSphere Client go to File –> Deploy OVF Template

Select the option to Deploy From File and click Browse

Browse to the VMware Data Recovery CD and go into the VMwareDataRecovery-ovf folder, select the VMwareDataRecovery_OVF10.ovf file and click Open.

Continue through selecting the default options, when you get to the IP Address Allocation screen you will have to leave it at DHCP – you can set a static IP address later through the vDR console after it boots up.

After it is done importing, edit the settings of the virtual machine and add another hard drive.  In my case this VMDK will reside on the backup datastore I created from my 1TB SATA disk.

Power on the vDR virtual machine and after it boots select Configure Network and assign the appropriate network information

Plug-In Configuration

From the vSphere Client select Solutions and Applications –> VMware Data Recovery.  Enter the IP address of the vDR and select Connect. Enter the appropriate username/password when prompted.

Backups

By default it will create Backup Job 1, click Edit on this job.  I needed to format the VMDK I gave the vDR appliance yet, after you format the volume it will automatically mount it as well.

On the next screen you can set your Backup Window times, see the note at the bottom of the post about backups that exceed backup window times.

On the next screen you can define your retention policy.

It automatically kicks off the first backup job, and I can see the backup when I click on the Restore tab

Notes

  • The default schedule for backups is Monday through Friday at night, as well as Saturday and Sunday.  vDR will attempt to backup the VM once per day, however if the backup does not complete during it’s backup window the backup will not continue – it will stop and resume during the next backup window.  Something to keep in mind if you are backing up a large amount of virtual machines (the maximum is 100)
  • Does not backup templates
  • vDR from what I have seen/read is not fully ready for large enterprise deployments.  Judging by some of the posts on the VMware communities site it may not even be ready for smaller deployments but since this is just a home lab I decided to give it a go and get more familiar with it.  I’m expecting to swap it out for something else at some point in the future.
  • This is a simple disk to disk based backup, it does not (by default) allow you to do disk to tape, although this document seems to go over the subject.

Popularity: 10% [?]