Zsoldier's Tech Blog

I've found this post by  Josh Perkins  helpful in more ways than the one demonstrated.  It's allowed me to not only update my vcops plugin registration w/ vCenter, but also helped me to update my Dell vCenter plug-in so that it connects via its DNS address rather than its IP. http://www.vstable.com/2012/04/02/vcenter-operations-5-x-vcenter-plugin-uses-ip-instead-of-dns-hostname/ However, I decided to explore the possibility of using PowerCLI to fix these registrations. Turns out you can and the change is immediate, so you don't have restart the vCenter service. YAY!  No more cert errors!  You still have to ssh into the vCOPs UI vm and update the viClientConfig.xml file, but that's easy enough. Here is my result (specifically for vCOPs): $BaseURL = " https://myvCOPsRegisteredDNS.Name.local " $ExtURL = " /vcops-vsphere/ " Connect-VIServer my1stvCenterServer, my2ndvCenterServer Foreach ( $DefaultVIServer in $global:DefaultVIServers...

What is it?: Simply put, it's flash acceleration.  You install a VIB in ESXi and register the PernixData Management (virtual management appliance) plugin to vCenter.  You can then take flash drives from each of your ESXi servers and clump them together to make a flash tier across all your hosts. Does vSAN render it obsolete?: Not really, it's a good solution to augment any existing SAN you might have.  It also won't require much change.  The scenery maybe changes as vSAN increases its configs max and traditional SANs fade, but that probably won't be for a long while. The cool things: You can use any SSD you want.  You don't have to purchase high-end or vendor specific SSD's. Reads and Writes can be accelerated. If the SSD fails, if configured, replicates that write to another SSD in the cluster. Yes, you would use network bandwidth @ this point only until the failed SSD is replaced. Most flash caching will only do reads because write redundanc...

Summary: Really a benign error especially if you don't use the function, but quite annoying if vCOPs is looking @ vCenter health. Resolution/Workaround: In my case, it appeared as though the vSphere Web Client service was conflicting w/ this Profile-Driven storage service. Stop vSphere Web Client service Start VMware vSphere Profile-driven Storage Service. Start vSphere Web Client service. For some reason this works and the web client seems to have a bit more intelligence in choosing ports  to connect to rather than the storage service which gives up the second a port it tried is in use.  Probably a hard-coded thing. Other Notes: If you are using the vSphere web client (which I wouldn't even bother with until 5.5 or newer), then it might make sense to install it on a different server to mitigate this issue.  Another possibility is to set its service to a delayed start.

Summary: Connect-VIserver MyvCSAServer was not connecting using my service account's (for scheduled tasks) windows account.  It would always prompt for credentials.  Fairly odd since it has permissions and is able to connect to several other vCenters w/o inputting credentials. By the way, this is very convenient since I don't have to insert passwords anywhere in clear text or come up w/ some crazy solution to encrypt the password. Solution/Workaround: Simply log into the web client using the service account once.  Once authenticated, powerCLI should not have prompt for credentials. [This applied when the VCSA's default identity source is set to Active Directory (Windows Integrated Authentication) and is set as the default domain.  Active Directory as a LDAP server option will not work.] Hypothesis: I'm guessing this is some kind of weird SSO thing, where the account needs to get locally cached prior to allowing Windows integrated authentication.  I...

Summary: Just another standard maintenance, upgrading vCenter from 5.0 U2 to U3.  Nothing special to see here.  Oh wait, it failed?  CRAP.  Restore database, try again.  Can't build vCenter Repository?!  Crap, restore database, try again.  AGAIN!!?  Long story short, SQL Authentication specified in the ODBC connection was experiencing intermittent connection issues.  Windows integrated was much more stable. Behavior: Opened ODBC --> Configure ODBC connection --> Enter SQL Credentials -->  Next... wait --> Error (See below for errors) --> Click OK --> Select Next again --> successfully connects and tests successfully.  Repeat... Hypothesis: This problem was likely due to the firewall in-between the vCenter server and SQL server.  As to what that problem was exactly, I have no clue. Solution/WorkAround: Changed ODBC connection from SQL Authenticated User to Windows Integrated.  For this to work...