Posted by mike on Jul 16, 2010 in VMware | View Comments
So this is an error / issue we’ve had to live with for some time. It’s a bit strange to be sure. Essentially in Command View, the Disk Group occupancy is completely incorrect, and continues to grow. Yes, that’s right, I said grow. For some photo-visual enjoyment, here is what a NORMAL Disk Group looks like.
So as you can see, we have a total Capacity (which is correct and accurate), and the Occupancy. The information listed is correct, and it’s refreshing. Now, for the problematic Disk Group (and please ignore the name as it was before my time).
Here we see the correctly calculated Capacity, but lo! What’s this? What on earth is going on with that Occupancy? It seemingly continues to grow a bit here and there as we take snapshots of various. HP doesn’t know what’s wrong either. When we upgrade from Command View 9.0 to 9.1, it did not fix the issue either. The big problem here is that we have to figure out how much space is actually used since we’ll never get alerted. It is a pain. I can turn to Replication Solutions Manager to obtain the correct size by simply adding all the luns (easy way to view them, as opposed to Command View), so that’s the workaround. Not very satisfying if you consider how much money was spent on these beasts.
read more
Posted by mike on Jul 16, 2010 in VMware | View Comments
This is a walkthrough for HP Command View for EVA. Part of my daily routine is to take a jaunt through CV, to check things over and look for alerts that I may not already be aware of.
Launched from the shortcut on the Windows host, or is accessible via a web browser at https://servername:2372
You are presented with the login screen:
It is here that you will also see the version number (down below). We have not yet upgraded this server to version 9.2 as we are building a VM to run Command View from and retire this physical box.
After login, you are greeted by the overview page. Here you will see all the EVAs listed, as well as the stats for your overall environment. The first thing of note is that two of my EVAs have bang lights on them, indicating something is amiss. I’ll investigate both as part of my next posting.
On the top right, there are some hyperlinks, your login id, and the ip of the Command View server. Most are self explanatory. Server Options provides for a place to enter license codes, setup RSM relationships, and a few other features. I seldom visit this page, so like once a year?
Moving right along, let’s take a look at a healthy EVA, in this case DS-SAN-2:
As you can see from the above, a healthy EVA has a number of folders beneath it. It breaks out into many subfolders. On the right hand side are the numbers. It would be here that you can get the logs for HP support (I’ll cover that in a separate blog post). You can see the current capacity level, view the Version level (this is the XCS code release running on the EVA. 6220 is the latest for the 8100 series). The left column is broken down like such:
Virtual Disks – this is where the luns (vdisks in EVA-speak) are listed. The folder structure is entirely man-made. That is to say, it’s for human organizational purposes (and plays an important role for setting up RSM jobs. More on that will be covered on a separate posting).
Hosts – here is where hosts are setup in Command View. You will provide the host’s OS, and it’s WWN’s for fiber cards. Hosts MUST be setup on every single EVA that you want to present disks from. Annoying, I know.
Disk Groups – these are comprised of physical disks. Best practice says to build these in multiples of 8, and of all the same speed and size. You can choose to not follow these and your performance will suck majorly. I’ve worked on rebuilding two of the 4 EVAs that had improperly constructed Disk Groups. It is PAINFUL to correct, but I’m glad I did. I will cover that also as a separate blog post. FYI: The ungrouped disks folder is for disks that have failed or been ungrouped on purpose. Ungrouping takes time as the EVA moves data from the drive to free it up to be removed or replaced.
Data Replication – it is here that you can create DR groups. This allows you to replicate (synchronous or asynchronously) between EVA arrays. A replication group is comprised of 1 or more vdisks. Sounding like a broken record, I will have a separate posting on replication.
Hardware – it is here that you can check out the status of the hardware. Both controllers are listed, as are all the disks. If there are hardware issues (per a bang light) then you can come here to find out why. The status of failed items is usually fairly straightforward and understandable as to what happened and what should be done.
read more
Posted by mike on Jul 12, 2010 in VMware | View Comments
I’d like to start discussing the storage I have at my work. I’ve had some good experiences in learning and working with it, and I’d like to share! I haven’t found alot specifically regarding working with the EVAs like I do daily, so I hope some folks find this useful!
So, as an overview for the environment, we currently have 3 8100 series and one 4400 series. EVAs arrays use two controllers, and our models are active/active. Our VMware environment at work is currently a VI3 schmorgesborg and we are planning an update (well migration) to vSphere. For SAN switches, we have older Mcdata’s that are workhorses! We manage them using EFCM software (also java, sigh).
HP provides Command View for EVA as the management tool for the EVAs. This installs and runs on Windows, and is now supported running in a VM as of the current release (9.2). Replication is handled with Business Copy and Continuous Access (separately licensed features). Automation of replication is handled using Replication Solutions Manager, which is a java-based App. :-/
For my next post, I’ll be giving a walkthrough of Command View and discuss how the EVAs we have are configured. Lots of screenshots too!
read more
Posted by Brian on Jun 10, 2010 in VMware | View Comments
Well I knew this day would come eventually, we had run out of space on this HP MSA. I knew going into this small project but this is the direction that the team took. So we purchased another 2 TB of space and I needed to add it to the configuration. We ended up buying 6 450 GB SATA disks to use in the MSA 2312sa unit. The drives were used to create one vDisk with just over 2 TB of usable space that was split up into 2 Datastores in VMware.
The configuration was a breeze just like the initial setup. The disks were placed evenly across the disk shelves and appeared into the console as expected. A couple of clicks later I had a vDisk setup and then created to volumes and assigned them to my hosts once I had created the Datastores from the first Host.
If you need to know more about how to setup these you can read my initial post on how to setup a HP MSA 2300 series array here.
read more
Posted by Brian on Apr 9, 2010 in Troubleshooting, VMware | View Comments
This is something that I have to do on Windows boxes all the time, but less on our ESX boxes. In the past we used to just run the vm-support to collect the support logs and turn those over to the storage team. They no longer are happy with those and since EMC now has a grab that supports both vSphere and VI3.5 it’s hard to deny them now. In case you do not know what a grab is, it’s a log collection utility that will provide the storage admin with all of the details about WWN’s, paths and which LUN’s a host can see. They can use this for planning upgrades and troubleshooting issues.
First thing you will need to do is to download the proper EMC grab version to support your hosts. At the time of writing this its a version 1.2.1 and is supports both ESX 3 and 4. Proceed on over to http://powerlink.emc.com and download it from the support programs area.
Once you have the file you will need to upload it to your host with something like WinSCP. I always upload it into the /tmp folder and unzip it there. It will create a folder called “emcgrab”. You can use the following command to do the unzip in case your not familiar with what to do.
tar -xvf emcgrab_ESX_vSphere_v.1.2.1.tar
Next thing is to move into the emcgrab directory that was created. From within there you will need to execute the following command. If you read the help file included in the directory it will explain some options to supress some annoying confirmation screens about the licensing and such.
./emcgrab.sh -nomsg
Once the program starts to run depending on the options you used it will prompt you to confirm and read the licensing. After you pass that part it will ask you a string of questions about your contact details and some questions about your environment. These are not necessary to complete it you are using these grabs in house. If you plan on sending these to EMC then I would advise to fill them out.
Once the script completes it will ask you if you want to run vm-support to collect the VMware support logs along with the EMCgrabs. This is up to you, if you have a need for them go ahead. Once the script finished it will place the zipped up file in the Output folder and you can pull off the file with WinSCP.
In closing it’s not necessary to be running Powerpath on your hosts to collect these grabs.
read more
