RDM mapping of local SATA storage for ESXi

25 10 2010

This post has been sat in my WordPress Drafts folder for sometime since I no longer use local storage this way. I decided to post it however as (a) it’s a good learning curve for ESXi work and (b) others may have more luck that me.

I recently acquired three 1TB drives and decided to do something about my lack of storage at home. Always trying to make best use of existing kit (and save money) I decided to stick the drives in to my HP ML110 and try something in a VM instead of doing the sensible thing of lobbing them in to a dedicated NAS box.

After wasting a few hours I realised that the onboard SATA RAID controller of the ML110 just can’t do RAID5 and to make matters worse, when I gave up and created a RAID1 array with a hot spare, vSphere 4.1 didn’t recognise the array and instead saw the drives as 3 individual drives. I saw this as a chance to try out the WAFL-alike ZFS file system. FreeNAS had been my NAS of choice recently so I chose to try ZFS in that.

I point blank refused to create 3 1TB VMDK’s (one of each of the three drives) so I set about figuring out how to create Raw Device Mappings (RDMs) of the local SATA drives. There were a couple of posts on the net that got me a little closer, but no guide/article had the whole thing down, so that’s my aim with this blog post.

Step 1

Once you had your drives installed, SSH to your ESXi box (now even easier in vSphere 4.1) and go to the /dev/disks directory. There, if you perform a ls -l, you’ll see your drives listed:

Ignore the instances of your drives which show them as VM stores (vm1.*****). We want to look at the raw devices.

Step 2

Now move to the /vmfs/volumes folder. Here you can see your existing local datastore(s). If, like me, you had a solitary hard-drive, you’ll just see localdisk01 or whatever you chose to name the local datastore:

Step 3

Now we are going to use the vmkfstools utility to create our RDM’s. Remember that a RDM is just another VMDK, but instead of the VMDK pointing to a xxx-flat.vmdk file (which is the actual virtual hard disk), the VMDK points to our physical device. Being as we still need to create this VMDK file we need to save it somewhere. Since we just have the one local datastore, we are going to create the RDM VMDK files in it’s root.

The following command creates the RDM VMDK for us:

vmkfstools -z /vmfs/devices/disks/<name of RAW device from Step 1> <location to store VMDK>/<RDM name>.vmdk

In my personal example below, I am creating an RDM called rdm_WD2DWCAVU0477582.vmdk and it is being stored in the location /vmfs/volumes/localdisk01/ I chose the name of the VMDK to match the name of the serial number of the physical drive (and what is shown in Step 1) to help with troubleshooting in the future when I get an inevitable drive failure). You can call your RDM’s whatever you wish.

The name of the RAW device (t10.ATA____WDC_WD10EARS2D00Z5B1__________________________WD2DCAVU0477582 in my example) you will have noted from Step 1 when you listed all local devices attached to your ESXi host. This is why the tech Gods created Copy n Paste! You will want to copy the full device name as shown in Step 1 in to the vmkfstools command.

Step 4

Once you have repeated the steps for all of your local SATA drives, you can navigate to where you created the RDM’s (in my case /vmfs/volumes/localdisk01) and perform an ls -l *.vmdk to see the new VMDK’s you have created:

Don’t panic – the xxx-rdmp.vmdk files will reflect the size of the RAW devices they are mapping to, but rest assured it will be taking no more space than a few bytes on your local disk!

Step 5

You can now add your RDM’s to an existing VM. vSphere doesn’t recognise this as a true RDM (to a SAN) so you just browse the local disk datastore for the VMDK files that we created.

Edit the properties of an existing VM and click Add…

Step 6

Select Use an existing virtual disk and click Next >

Step 7

Click Browse. You now need to navigate your local datastore and select the VMDK’s that we created in Step 3).

Once complete you will be shown a confirmation window. Repeat Steps 5 through 7 to add additional RDM’s to your VM.

Step 8

You should now see your new Hard Disk’s in your VM and vSphere will correctly identify them as Mapped Raw LUN.

NOTE: One thing I forgot to show in the screen shots, is that you should create your RDM’s on a new SCSI controller! You do this by simply selecting a new SCSI ID starting with 1:x instead of 0:x. Existing VMDK’s should be on SCSI Controller 0. Your RDM’s should be on SCSI controller 1. Although my screenshot shows 0:3 this should read 1:3.

You can now save your VM configuration. Your VM will now access the RAW SATA drives  and be able to use things like SMART to monitor its health.

See below; I am adding my three 1TB drive to FreeNAS to create a new ZFS pool.

Stay tuned for an upcoming blog post on FreeNAS and NexentaStor which may or may not put you off ZFS [in a VM] altogether!





Working with HP MSA 2000 via command line

25 10 2010

This statement is becoming almost cliche in the blogging world, but this post is more for my own benefit to help me remember some of the work I’ve been doing on MSA lately:

The MSA 2000 series has a pretty dire web interface – when you compare it with other SAN’s – and to make matters work, it mixes and swaps terminology with HP’s own EVA’s (a vdisk on an MSA refers to a RAID array made up of physical disks. A vdisk on an EVA is a virtual RAID array which sits on top of the underlying RAID 0 structure). The web interface is challenging enough as it is when it works, but recently the web page of the management interface has been timing out.

Thankfully SSH access still works and responds well. I’ve been using…

restart mc a

…to restart the management interface which helped things for a short while but ultimately I found myself falling back to SSH more and more.

The following procedure follows the steps I took to rename and prevent a volume to a host.

To give a host a friendly name (from its WWN):

set host-wwn-name host <wwn> <friendlyHostName>

To rename a volume:

set volume <volName> name <new_volName>

To view what hosts a volume is currently presented to and what volumes map to what hosts:

show host-maps [<friendlyHostName>]
show volume-maps [<volName>]

To actually present a volume to a host:

map volume <volName> [lun <lunID>] host <friendlyHostName> access rw

In theory the LUN ID can be left blank, but in practise I found that it would not map unless I specified an ID. Don’t forget to map both HBA’s for a host.

After presenting the volume to the Windows 2003 host I was dismayed when the Storage MMC could not see the new lun. Hitting F5, of course, was not enough. On the Disk Management section folder in the left hand side of the MMC window, right-click and select Rescan Disks.

I’ll update thist post if I use and feel the need to remember some other command line options for the MSA 2000 but hopefully we’ll be migrating off it to EVA soon!





Netbackup script to report scratch tapes

4 05 2010

I’ve seen Netbackup used in two completely different ways now. In my last environment all tapes rotas, movements and scratch tapes were handled manually. We had a spreadsheet showing tape sets (see below for an example), when these tapes were collected by Iron Mountain, which days of the months we defined as Monthly/Quarterly backups and so on. In this scenario each set of tapes is a number of tapes – on some days you may use less, on some days you may not have enough loaded.

In the new environment we let Netbackup dictate which tapes are in the scratch pool and free for re-use based on the expiration policy of the jobs written to those tapes. In theory this should mean that you only ever use as many tapes as you need for a given backup job. The problem with this set-up is that although it is, in theory, more efficient, you don’t always know which tapes you will need each night and how many you have free.

Each day guys were running NBU command lines to show which tapes were in the scratch pool, but having to manually sift through them to see which tapes were currently sat in drives/libraries and of the ones held off-site, which tapes were of which format (LTO2, 3 or 4).

The following script can be scheduled to email out a list of tapes in the scratch pool, which are in what library and also groups the offsite tapes by format. It was knocked up in a hurry so isn’t as parameterised or dynamic as it should be, but the comments should help you fix it for your needs…

Read the rest of this entry »





Using CrashPlan to backup a network share

12 03 2010

Some time ago I started using CrashPlan with CrashPlan Central to finally start backing up my family photos and important documents off-site. It’s been working pretty well, despite my frustrations over slow upload speeds. It’s pretty much a fire and forget solution.

Recently I’ve installed FreeNAS on to an old PC to (a) start getting some stability to my storage solution, and (b) play around with ZFS and iSCSI at home. I tried OpenFiler but it pales in comparison to FreeNAS. I’ve gone against my better judgement and I’m using some of the cooler plugins including the Torrent client, Dynamic DNS and I’ve even installed SABNzbd on it. FreeNAS comes with rsync built in and even Unison which is an interesting solution to cross platform backup/synchronisation, but I’ve payed for my CrashPlan Central plan so want to make use of it!Only problem now is backing up my data!

CrashPlan doesn’t support backing up from a network share – either mapped drive or UNC path. There is a work around on the CrashPlan site which works but is a little convoluted so wanted to post a nice, quick version here.

Read on after the break… Read the rest of this entry »





Using Powershell to report on Netapp filer snapshots

2 03 2010

We had a few issues recently where SnapManager for Exchange and SnapDrive were failing to communicate properly which resulted in a weeks worth of missed snapshots before anyone realised what was going on.

I wrote this script to report on the status of snapshots. The filer name is passed as a variable and a list of volume names is stored as a variable at the top of the script. The output is nicely formatted email.

  1. The script uses SSH to connect to the filer (see my SSH guide for Netapp filers)
  2. For each vol listed in the array, the list of snapshots is returned
  3. Any line with “__daily” in is processed – all others are ignored (we only care about our nightly verified snapshots which are all named __daily)
  4. The snapshot name contains the date/time it was taken – this is read and if the date is within 24 hours of now a success is return (since reports are run the day after the verified job). If the date is over 24 hours a failure is returned.
  5. A nicely formated HTML email is sent out which looks a little something like this…

Please see below for today’s backup report.

VOL Name Status Snapshot name
Vol_Exc02_DB Success 0% ( 0%) 0% ( 0%) Mar 02 01:44 exchsnap__exchange02_03-01-2010_23.00.14__daily (busy,backup[0],dump)
Vol_Exc02_LOG Success 0% ( 0%) 0% ( 0%) Mar 02 04:38 eloginfo__exchange02_03-01-2010_23.00.14__daily
Vol_Exc02_DB1 Success 0% ( 0%) 0% ( 0%) Mar 01 23:00 exchsnap__exchange02_03-01-2010_23.00.14__daily
Vol_Exc02_LOG1 Success 1% ( 0%) 0% ( 0%) Mar 02 01:27 eloginfo__exchange02_03-01-2010_23.00.14__daily
Vol_Exc03_DB Success 1% ( 1%) 0% ( 0%) Mar 02 00:50 exchsnap__exchange03_03-01-2010_23.00.13__daily
Vol_Exc03_LOG Success 0% ( 0%) 0% ( 0%) Mar 02 02:06 eloginfo__exchange03_03-01-2010_23.00.13__daily
Vol_Exc03_DB1 FAILURE 1% ( 1%) 0% ( 0%) Feb 26 23:00 exchsnap__exchange03_03-01-2010_23.00.13__daily
Vol_Exc03_LOG1 FAILURE 0% ( 0%) 0% ( 0%) Feb 26 00:32 eloginfo__exchange03_03-01-2010_23.00.13__daily

See the script and HTML files after the jump… Read the rest of this entry »





NTFS permissions lost when copying from a snapshot

1 03 2010

Something I just remembered when performing a restore for a user.

When copying files from a CIFS snapshot using the hidden .snapshot directory NTFS permissions are lost. Instead they are inherited from the folder you are copying to.

To maintain permissions, use NDMPCOPY specifying the snapshot name in the source (first) parameter…

ndmpcopy "filer1:/vol/vol_A/qtree_A/.snapshot/nightly.1/MyDocs" "filer1:/vol/vol_A/qtree_A/MyDocs"

You can enclose the path in quotes if the path has spaces in.





Netapp Rapid Cloning Utility v3.0

26 02 2010

Netapp have released their new version of their Rapid Cloning Utility – a vCenter plugin which allows you to provision and new datastores and clone hosts (including VMware View 4 VDI’s) with ease right inside of the Virtual Infrastructure Client. vCenter 4 is needed but it is compatible with ESX 3.5 and 4.

The great thing is that all the storage processing is offloaded from vCenter and is performed entirely on the filers. I’ve not had a chance to play with the RCU yet but this just looks utterly awesome! Check out this preview blog post and video from Netapp:

http://blogs.netapp.com/virtualstorageguy/2009/12/preview-rapid-cloning-utility-30-vcenter-plug-in.html

If you don’t have time to sit and read, then at least check out the video. I dare you not to be impressed!


Do any other storage vendors have similar tools?

Source: http://www.ntapgeek.com/2010/02/netapp-updates-rcu-for-vmware-vsphere-4.html




Scripting Netapp filers

26 02 2010

Scripting the Netapp filers can be accomplished by using either RSH or SSH. Both of these options must be enabled on the filer(s) in question using.

In either case scripts are not processed on the filers themselves. They are scheduled and run on Windows/Linux systems using their native languages (e.g. Vbscript or Powershell). These scripts simply call native OnTAP commands against a filer which then returns data in the form of text. This is important to note as although Powershell is a useful language to use OnTAP will not return native PS objects which means you are limited to text/string based manipulation.

RSH

This method is the least secure but is the quickest and easiest to set up. Users need not necessarily be filer administrators. Although there is some degree of security in the sense that access is restricted to a set user account and accessible only via a set IP address, data is not encrypted.

RSH is not natively supported in Windows 2008 [from the command line] as it is in Windows 2003.

To enable RSH on the filer use the following command:

options rsh.enable on

You must also specify user accounts and IP addresses via the FilerView web interface.

SSH

Windows 2008 does not natively support SSH either so this is accomplished using plink.

To enable SSH on the filer use the following commands:

secureadmin setup
secureadmin enable ssh

Read more after the break…

Read the rest of this entry »





Netbackup Report Scripting

25 02 2010

Hi everyone. I’m going to jump right in to my first post (the main reason for starting this blog in the first place) and show you the progress I’ve made with automating daily reports using our backup solution of choice, Symantec (used to be Veritas) Netbackup.

Until now our users have demanded daily reports to be emailed out to key individuals. The format of these emails was quite basic in theory…it simply showed a list of all servers (clients) that were backed up, their status from last night (e.g. successful, failed, etc…) but then, crucially, a list of files that had been skipped.

The reason for listing each file that had failed was due to Netbackup’s poor poor (don’t get me started on how poor) feedback in the Activity Monitor and it’s built in reports. You see sometimes jobs could be marked as “Successful with warnings” if the job completed but the odd file had been skipped (if it were in use, for example). But other times, although it still listed which files had been missed if you double-clicked on each job, it showed the overall status as Successful. This meant that to report on the servers in the format that was required by our users we had to manually trawl through the 360 jobs across two Netbackup servers just to copy and paste the lines of the files that had been missed.

Needless to say it didn’t take me long to get bored of this so I started looking at a way of reproducing our reports automatically. After some time, I’ve come up with a solution – it uses VBScript to parse the logs files which I output using a few key Netbackup command-line tools.

The basic process and components to the script are as follows…

  1. A VBscript calls a number of external batch scripts
  2. These batch script run NBU commands and spit their output to text files
  3. The VBscript then reads these text files
  4. The VBscript reads a servers.txt file to determine what jobs to report on*
  5. A LOT of array and string manipulation is used to catalogue which jobs have run and which have errors and if so, it collates all skipped files
  6. These arrays are then parsed and dumped to either an HTML file (which can be used directly in the body of an email) or, as I’ve recently changed to script, outputs to an Excel file.

There are some nice bits to the script(s) and some really nasty bits – I welcome you to improve on the original and share it with everyone (for example, I know there is a much neater way of calling and parsing the output of batch jobs rather than the nasty wscript.sleep I have used).

* A text file (called servers.txt) is kept along side the scripts. This file is manually edited and must be kept up to date. The file is a number of lines, each one representing a client/job that we wish to report on. The format is as follows:

60, myserver, mypolicy, GroupName

The number at the start represents what days of the week the report should be generated. myserver is obviously the client that is to be reported on. mypolicy is the name of a policy that you are reporting on (since a client may me a member of multiple policies). Finally, GroupName is free text and can be used to group similar clients (that may not necessarily be grouped by the same policy.

The scripts necessary to generate a report are…

  1. generateReport.vbs
    The primary script which calls the others and also performs of the processing and HTML/Excel generation
  2. jobs_summary.bat
    Issues the bpdjobs – simmary command and pipes output to a text file. This provides a simple overview of number of total jobs and the number that have succeeded, failed or errored.
  3. jobs_report.bat
    This is the main batch script upon which the report is generated. It is a hideous mess of space-formatted garbage and why so much processing is needed to generate a useful and nice looking report.

Clicking the scripts above will take you to a separate page with the code and more explanations of how to use it in your environment.

UPDATE: Okay, so enough of you have expressed an interest that I decided to put it up for public download. Please note that it is not currently protected via any kind of license so please use your discretion. I have included a very basic READ ME that I encourage you to go through. Post your comments here if you have any problems.

Download: Dave’s Netbackup Reporting script








Follow

Get every new post delivered to your Inbox.