The VMguy

One of the greatest things VMware ever did in vSphere was add the Storage Views tab.  Storage views let’s you see detailed information on the size of your VMs, how much space each VM takes up in snaps, etc.  One question I very often get asked is:  “How do I export that information from Storage Views to excel or CSV?  The answer is simple, but it’s probably not where you have been looking.

Let’s go thru an example.  First things first, before you export, make sure you have all the information you need.  In the vSphere client, pick your level to look at the Storage View (the vCenter Server, the datacenter, a cluster, a host, etc) and select the Storage Views tab on the right.  Right-click the title bar in the right pane and make sure you have all of the fields you need.  The menu will look something like this one here:

Make sure you select all of the columns of data that you want (or don’t want).  Once you have that cleaned up, we go for the export.  Your instinct would be to go to File and Export like this:

Notice how the Export List option is greyed out?  That’s where you would expect to find the export function for the Storage Views.  I think there is a bug in the interface as that is not really where it is located in this case.  For Storage Views, move the cursor to some white space on the right or the bottom of the right pane and right-click.  You should see a popup menu that looks like something like this:

Select “Export List” from the menu and you can save the storage view as Excel, HTML, CSV, etc.  There, now you have some great data for graphs or whatever you like.

One more tip:  If you export the fields to Excel, the cells will all be text and the data values will have “GB” in the cells with them.  If you want to remove the “GB” and convert to numeric so you can work with the values here’s how:

Let’s say Cell C3  has a value of “7.77 GB”.  Create a new column and for the value put in  =VALUE(LEFT(C3,LEN(C3)-3))

The LEFT() function will cutoff the “GB” and the VALUE() function will convert the TEXT to a numeric value that you can add, subtract, etc.

Now you can add a cell at the bottom and use the AVERAGE() function and find out what your average VM size really is!  Or SUM() the Snapshot column and find out how much space your VM snaps are taking up on storage.  There are all kinds of options, have fun and enjoy!

I have been doing a number of presentations on vCenter Ops Manager over the past few weeks.  This concern was raised at one of the sessions.  If you were not aware, VMware had a promotion from November 23, 2010 to March 1, 2011.  The promotion was for 50 VMs worth of “Alive VM” (the product now known as vCenter Operations Manager.)  There were a set of VMware SKUs that were applicable for the promotion (unfortunately this was the link for it but it no longer works.)  I believe the SKUs were almost all of the upgrade or new purchases of Standard, Advanced, Ent or Ent+ editions of ESX.  I’m trying to find the list of SKUs but most of the links to detailed information are now broken.  So if you bought the applicable SKUs, you got 50 VMs worth of Ops Manager.

Beginning on March 15, 2011, VMware began sending out the email notifications with the Redemption Codes in email.  The customer contact on the original order for the products should have received the email.  It has instructions for redeeming the code and getting the Ops Manager licenses.  If you have not received (or can’t find) the email and believe you are eligible, you should contact your VMware Sales team.  Here’s the main point: If you have received your email, you only have until May 31, 2011 to redeem your code and get your licenses.

If you think you are eligible, make sure to find your email and get your licenses, time is running out.

Got this lovely message yesterday when installing a new vCenter 4.1U1 for a customer.  Never seen this one before.  Until I found this thread. I was very suprised to see the resolution.  Here’s a tip for all of you:  Don’t name your vCenter Service account the exact same name as your vCenter Server.

When we renamed the service account to have a different name from the vCenter server itself, all installed fine.  I had to post it, this issue really surprised me.

Hopefully this issue will get fixed soon.  I was working on a new deployment for a customer when I noticed this issue.  The issue is this:  I created a few windows VMs for this customer to use as templates.  I created them as thick, figuring I would patch, defrag, shrink, then convert to thin.  When I did, I noticed that my disks went from 50GB to 49.9GB, huh?  Looking inside the VM, the C drive was using 8GB of space.  Where was this 49.9GB coming from?  After a bit of searching on the net, I came across this thread in the communities. I looked thru the article and sure enough the listed fix works.  I had a extra LUN for this customer that had not been used yet.  I deleted the datastore and created a new one with a different block size as the others.  I tried the svmotion with converting to thin again and this time, Bingo, 8GB as expected.  I was then able to svmotion back to my original LUN telling the svmotion to keep the same type.  Worked great and stayed 8GB.

Duncan wrote an explanation in the community thread for what is going on:

“It most definitely has to do with the type of datamover used. When a different blocksize is used for the destination the legacy datamover is used which is the FSDM. When the blocksize is equal the new datamover is used which is FS3DM. FS3DM decides if is will use VAAI or just the software component, in either case unfortunately the zeroes will not be gobbled. I have validated it and reported it to engineering that this is desireable. The team will look into it but unfortunately I cannot make any promises if or when this feature would be added.”

It sounds to me like if your storage supports VAAI and ESXi offloads the svmotion to it, there’s no hope of shrinking because VAAI is not that intelligent.  When you svmotion between two different LUN block sizes (or between iSCSI, NFS or FC) it uses old-school svmotion (probably because the VMFS block layout changes) which will actually convert the VM to thin when it moves.

Hopefully VMware engineering will change svmotion to automatically use old-school svmotion when you select to change from thick or thin and only use VAAI when you choose to keep the same format during the move.  We’ll have to wait and see….

I was installing Site Recovery Manager in Miami today for a customer who replicates to Atlanta.  I’ve been working with them the last few days to setup SRM and get their Protection Groups and Recovery Plans in place.  One suggestion that I made was to add a Message to their Recovery Plans to pause after the Shutdown of the Primary Site VMs.

Here’s why:  In a true failover in SRM, the first step of the Recovery Plan is to shut down all of the VMs in the primary site that are protected.  This is so that when the VMs restart in the recovery site, they do not conflict on the network with the original VMs.  Here in Miami the typical disaster is, of course, hurricanes.  Hurricanes are typically predictable with a decent notice.  I can then assume that my odds are higher than normal that when the person hits the failover button here, both sites are still available and I will be avoiding a disaster and not recovering from one.  For this reason, I recommended to my customer that they add a message in their recovery plan right above “Prepare Storage” in the Recovery Plan.  You can do this by right-clicking “Prepare Storage” and selecting “Add Message”.

I added the following message to their Recovery Plan: