unregistering virtual machine hangs

We were migrating 40 VMs from one Netapp filer to another and implementing IPSpaces at the same time, so we needed to power down all 40 VMs for this.
Once the VMs were migrated, we powered on the DB VMs first - no issues.
Once the DBA verified Oracle was up, I started powering on app VMs.
But they all hung on  
 "unregistering virtual machine from source host system"

Turns out this was due to 3 of the vmwaretools updates hanging - I had started these vmwaretools updates while the DBA was working on Oracle.
These were not the same App VMs I was trying to power on, but once 2 of the hanging vmwaretools updates finally timed out, some of the App VMs finished powering on.
I manually killed the remaining hung vmwaretools update using the ESXi command line then everything proceeded fine.
Hope this helps someone else since it was not obvious at the time the vmwaretools updates were preventing other VMs from powering up.

vCenter 5.1 SSO login failed

I've worked through a few SSO issues, but this one was new.  Newly provisioned Power VM type role users were failing to authenticate (login or password incorrect) on the classic vi client, and "ns0:RequestFailed: Internal Error while creating SAML 2.0 Token" on the web client.

VMware finally posted KB 2043070 on 02/08/2013, which solved this issue for my users (even though I was not seeing the same log errors mentioned by the KB article).  

To resolve this issue, remove the the localOS identity source from vCenter Server Single Sign-On (SSO).

To remove the localOS identity source from the SSO configuration:

1. Log in to the vSphere Web Client as the SSO administrator, admin@system-domain.
2. Click Sign-On and Discovery.
3. Click Configuration.
4. Identify the Local Identity Source. Its domain name should match the machine name.
5. Right-click the Local Identity Source and click Delete Identity Source.

There is another, older KB article 2zero34798 which is the TOP google hit for this error which was a timewaster for me (talks about misconfigured AD DNS - not relevant in my case)

Hope this saves some folks and their users time and aggravation!

Also ensure your vcenter service can restart following this change.
Ours failed with an error in the c:\programdata\vmware\vmware virtualcenter\logs\vpxd log (programdata is hidden by default)
This was because the service account the vcenter service runs as was missing from the VPX_ACCESS table.
We followed  KB 1005680 and inserted the row with:

insert into vpx_access (ID, PRINCIPAL, ROLE_ID, ENTITY_ID, FLAG) values ('100', 'DOM\dom.user', '-1', '1', '1');

Aligning VMs via Netapp VSC 4.1

With Netapp's release of VSC 4.1 for VMware comes support for online alignment of VMs residing on NFS datastores.  We aligned 99% of our VMs 1-2 years ago the only way possible back then, by powering them down and running mbralign - which meant large VMs soucle be down for hours.

So we were excited to see the Scan Manager go through the datastores we chose and classify our VMs



As either Aligned (actually or functionally) or Misaligned (online or offline)



But when we went to align the NFS based VMs we received the error:



Selecting Yes, you are given the choice to Use and existing datastore or create a new one



We selected Create new but got this error

The iscsi devices were enabled on the controller (according to the command line)
dr-na-01> iscsi interface enable -a
Interface e0a already enabled
Interface e0b already enabled
Interface e0c already enabled
Interface e0d already enabled

But to make them VSC enabled we had to go Provisioning and Cloning -> select the controller -> Resources  and shift all the resources to the right


Once we did all this, VSC was able to create the iSCSI VMFS datastore and migrate the VM from misaligned on NFS to "functionally aligned" on the iSCSI datastore.

However we don't run iSCSI (or FC) datastores - we need VSC to support creating optimized (functionally aligned) NFS datastores.

According to Netapp support: "there are quite a few Gotcha’s when it comes to NFS alignment, so we have not yet made it a standard feature of VSC online migration"

Well, maybe in VSC 4.2?