VM Creation Historical Report

I needed something that I could look back upon to determine who created what VM in vCenter and from what template.  This works when dealing w/ just vCenter and not vCloud Director.  It's painfully slow, but it works as a stopgap until I figure out how to query the same information from SQL instead.

Here is an screenshot example of what the PowerCLI script outputs:

Although, I can probably gather a longer historical view through CSV's than vCenter's SQL if those events/tasks are cleaned up after a period of time.  It's meant to be run on a daily basis.

Script found after the break:

HP Discover 2013 VMware-sponsored sessions

Those interested in some VMware-sponsored sessions @ this HP Discover 2013 can look forward to the following:

  1. BB4361 Optimizing HP Storage for VMware: Current Integrations and Software-Defined Storage
  2. DT4364 Top Strategies to Simplify Datacenter Management with vCenter Operations Manager and vSphere Web Clients Integration
  3. TB4362 VMware End User Computing - Transforming your Workspace
  4. TB4363 Managing the Software-Defined Datacenter

The two that I will probably be attending are DT4364 and TB4363.  They seem to be the most interesting to me.

Details of sessions past the break:

2013 vExperts Announced

I'm proud to say that I made the list again this year.  Look forward to continue providing helpful content to the community.  I think I'm going to expand more into the Japanese community this year.

http://blogs.vmware.com/vmtn/2013/05/vexpert-2013-awardees-announced.html

NFS: Unable to create datastore: The specified key, name, or identifier already exists.

Summary:
I have a shared NFS datastore mapped to all my hosts.  So I found it strange that two hosts in a cluster of 5 were not seeing it.  When I would try to map it, I would get the following error:
Unable to create datastore: The specified key, name, or identifier already exists.

This worked for me:
It seems I had an old mapping in place that wasn't showing up in vCenter until I refreshed the storage view to show the 'inactive' mount:
Once the inactive mount appeared, I was able to unmount it, then remount the correct path.
[If the refresh doesn't work, you may need to SSH to the host and run the ESXCLI commands listed toward the bottom of the post]

I found it interesting in that running "vicfg-nas <a bunch of connection options here> --vihost myesxserver -l" did not list this inactive path either.  It might have shown up if I connected directly to the ESXi host w/ the vSphere client, but I did not check.

ESXi 5, you'll need to use the esxcli commands like so:
esxcli storage nfs list

esxcli storage nfs remove -v nameOfDatastoreVolume

New Google Maps

I just received my invite to the new Google Maps.  It is everything as advertised in their promo video embedded below:

The only real downside is it's speed right now.  I'm used to google maps being real snappy, but what I'm exploring right now is painfully slow.  I assume the reason is their backend systems are not as robust for this 'preview'.

Storage DRS: A general system error occurred: Failed to start disk migrations.

Summary:
I've recently started putting together datastore clusters and implementing storage DRS.  The error above does not lead to a obvious conclusion.

Observation:
In the case of a "Recent Task" named "Execute Storage vMotion for Storage DRS" and error "A general system error occurred: Failed to start disk migrations." appears to be caused by vmdk's associated w/ a singular VM being named the same.

In my case, my vCOPs UI VM has 3 disks, two on one datastore, and the third w/ the config files.  Storage DRS acting upon consolidation of vmdk's and maintaining 80% free space has determined that it needs to move the disks to where the vmx and 1 of the vmdk's resides.  This is where the conundrum occurs and the above useless error presents itself.  Below are screenshots examples:


Workaround:
Break the Storage DRS rule "if you have the space to do so" move all vmdk's and vmx files to a completely different datastore.  This will consolidate all files to meet the consolidate vmdk rule, then storage DRS should pick up and move all files to a datastore w/ enough space bringing you back into full compliance.  All without any downtime. :)