SAN Shutdown Script

Here's a short python script that you can use to automate a clean shutdown of a Equallogics PS6000xv. I threw it together so that I could run/schedule it from an ESX 4 host; it implements the telnetlib module to automate a telnet session with a Dell PS6000xv (tested on firmware v4.1.3, R91175). I thought it might come in handy for someone else, as Dell/Equallogics doesn't publish any code to do this kind of work for you. Make sure that when you run this, you don't have any active I/O going on.


import sys
import telnetlib

hostIP = "192.168.0.2"
user: "sanadminaccount"
password: "password"

tn = telnetlib.Telnet(hostIP)
tn.read_until("login: ")
tn.write(user + "\r\n")
tn.write(password + "\r\n")
tn.read_until("SANNAME> ")
shutdownstring = tn.write("shutdown" + "\r\n")
tn.read_until("[no]")
shutdownresponse = tn.write("yes" + "\r\n")
tn.write("logout" + "\r\n")

print tn.read_all()



Equallogic PS 4.3.6 firmware upgrade process

Dell released their PS-series 4.3.6 firmware upgrade last week. I've applied the update to one of the PS6000xv devices that I have running. While Dell seems to do a thorough enough job with validating these before they get released... I thought I'd document my experience with applying the firmware in case anyone's interested in knowing what to expect.

The environment that I'm working in on this one consists of 7 vSphere 4.1 hosts, with all of the VM's running off of this particular PS6000xv.

1. My first step was to shutdown most of the VM's and make sure the SAN doesn't have a lot of I/O running on it. Depending on what firmware you're at, you don't need to have your I/O completely stopped , Dell just recommends not having much I/O going on. While your thinking about that statement, make sure you factor in any I/O that's happening outside of your virtualization stack. For instance, if you have servers mounting LUNs directly off of the PS, they too will create I/O.
2. Download the firmware 4.3.6 from the Equallogics support site using your individual credentials. If you get the zip, extract it because the PS6000xv just wants the *.tgz
3. FTP into the PS using your grpadmin credentials and upload the tgz file to the root of the FTP site.
4. If you have old *.tgz's in there, you can delete them to clear up space. So if you get a failure notification about not having enough free space, it's probably talking about the FTP site - check and see what all you have in there.
5. After the upload, logout.
6. SSH into the PS using grpadmin credentials - connect to one of the individual ports, not the group IP.
7. Use the "update" command, and the firmware will validate and begin updating the controllers - 1 at a time. It took about 4 minutes per controller for me... I had shut all of my VM's down (expect 1), so there wasn't much I/O going on at the time.
8. Use the "restart" command when finished... keep in mind, this restart effects the controllers 1 at a time. It does the first, and then the second. The Group IP will stop responding during the update of the second controller restart, in my case there were 6 dropped packets during in a continuous ping to the Group IP. Also realize that your SSH session will drop at some point... that point depending on which IP and controller you connected to earlier.
9. After the second controller is restarted, go ahead an login into the Web UI (or the CLI if that's your preference) and check that the PS has been successfully upgraded by looking at the controller tab and verifying that the firmware was upgraded to version you expect. If you have vCenter open, you might notice that very briefly (less than 10 seconds in my case) some of the VM's and/or datastores will read as "unavailable".

If you happen to be a bit impatient and login to the Web interface too soon and check the firmware, you might notice an error like "battery failed" on whichever controller was second to restart (even if the firmware revision is not updated). If that's the case for you, just wait a few minutes and refresh the info. Also, if you connected immediately back in via SSH, or were using a serial connection - after your ping to the group IP started to drop, you can wait around in the CLI until the restart firmware complete notification echo's in the CLI.

Using FreeNAS as a SAN for an ESXi demo

I recently had to do a virtualization demo for a client. The need was to show a particular application stack running under ESXi, using storage mounted from a SAN. This all needed to be portable, inexpensive, and completed quickly. The requirements limited me to stuff I could find quickly, and that would work. As such, I really only considered FreeNAS, OpenFiler, and Windows Storage Server since they were all readily available.

I ended-up using FreeNAS, and was actually quite impressed. FreeNAS runs the FreeBSD distribution, and interestily, like pfSense (another favorite of mine), it too is based on Monowall. What worked really well for me, was that FreeNAS is downloadable as an ESX virtual machine - which meant I could just download it and run as a VM inside an existing ESXi host. After getting it fired-up on "serverA", I stepped through the base configuration, got some storage carved out and exposed via iSCSI, and then just mounted it up inside a different ESXi machine (serverB). After doing do, I was able to copy my pre-configured VM's to the newly created datastore. I fired up my VM sessions on "serverA", they used the FreeNAS storage provided from serverB, and I had my portable demo environment. I'll follow-up with the steps I used to setup and expose the storage.