Zsoldier's Tech Blog

Really short post This can occur when an ESXi host that is not completely configured is introduced to the cluster even when in maintenance mode. i.e. it is still missing an NFS share. Long story short, don't introduce ESXi hosts that haven't been completely configured yet.

Summary: A very cool little appliance that looks @ your VM's and everything they interact with.  Unfortunately, the installation can be fraught w/ issues.  I for one found a bug w/ vCenter 5.0 and VIN 1.1.1 (where VIN 2.0 might have been introduced before).  Specifically, I was unable to apply a VIN 1.0 license to my VIN 1.1.1 installation because I tried to introduce VIN 2.0 first.  Interestingly, my 2.0 key worked fine w/ the 1.1.1 version. Long story short and to make it simple don't introduce VIN 2.0 unless you are on vCenter 5.1. PreReqs for 5.0 users: vCenter 5.0 VIN 1.1.1 vCenter Web Client 5.0 Details: If you have not deployed VIN ever to your 5.0 environment, then I recommend you deploy VIN 1.1.1 and save yourself some headaches.  Otherwise, here are some remediation steps you can take to deploy VIN if you did what I did or set it to auto-upgrade w/o knowing better. Steps to Remove VIN extensions from vCenter Remove VIN...

What does resetting the vCenter Inventory Service database mean exactly? [Update: Additional Info added thanks to anonymous feedback] In 5.0 , this simply is the search/index function in the vSphere Client, previously handled by the Tomcat service.  So going through the reset steps outlined here , should cause little to no grief. You could attempt the restore steps, but I don't really see a point in doing so in 5.0 You usually need to go through the reset steps if the client's search begin to slow down and you get "Operation Timed Out Errors" In 5.1 , this database seems to now house the 'tags' info feature. This is where it's now important that you have backups because resetting the database effectively wipes out all your entered 'tags' from existence. Things affected by resetting inventory service database: o vCenter tags (version 5.1+ only) o Storage Profiles o Storage Capabilities o Index of which VMs have which Stora...

Summary: EMC documentation is atrocious.  Needless to say, their 'auto-registration' capability is poorly named and represented in my opinion.  It makes you think, deploy a vApp, copy license file, and you're done.  SOOOO NOT the case.  So here is my attempt to hopefully help make the license application portion 'automated' using PowerShell and PowerCLI cmdlets. PreReq: PowerPath 5.8 License vApp PowerPath License File RTools for Windows Details: Deploy the vApp Generate a license file from EMC's website, you'll need the IP and DNS name of the vApp. or contact your EMC support team to have them do it for you. Copy the license file to the vApp's /etc/emc/licenses/ directory Install RTools on a Windows server or your workstation I prefer to have my tools on a shared general purpose system.  This allows me to run scheduled scripts from one location. Copy the same license file to C:\ProgramData\My Documents\emc\PowerPath\rpowermt The...

Summary: vCenter was able to connect to and seemingly manage hosts fine, however when a user attempts to clone, an error "Cannot connect to server" is returned.  NAT's are NOT SUPPORTED .   That being said, here is what I did to track down what was causing this issue. Details: First I tailed the vpxa.log while I attempted a clone.  What I found was actually quite interesting.  When attempting the clone, @ some point w/ the destination IP of the ESX host was changed.  It ended up targeting an IP to which I was unaware of what that IP might be. So I performed a traceroute from vCenter to the ESXi host.  It turns out the IP was a firewall in the route. With the firewall IP in hand, I went to the firewall security team and had them check the settings.  Turns out there was a source NAT setup that was causing me the errors.  Once that was removed cloning worked w/ no problems. From my perspective as a VMware admin, I would have had no ide...

Summary: This alarm means that server's CIMC system event log has filled up.  Below you will find the steps to clear this type alarm. PreReq: This assumes you are utilizing B-series UCS servers.  C-series may be slightly different in practice. Resolution: If you're vCenter is configured w/ default alarms, you'll likely see something like pictured below in vCenter under the hardware status tab: To clear this alert, you'll need to empty the SEL Logs in UCS of the blade related to your service profile.  You are not likely to find SEL Logs as part of the service profile. Once you've opened the related blade, select the SEL Logs tab.  Review and/or export the logs so you simply do not clear something that may need to be investigated.  Once done, you can safely clear the logs: Once the SEL Logs have cleared, the alert in vCenter should reset to green in a few minutes.

Rather than regurgitate all the information whole here is the skinny: SSH into your UCS chassis (aka primary fabric interconnect) connect nxos ethanalyzer local interface mgmt limit-captured-frames 2000 write volatile:/mycapture.cap ethanalyzer is the command local is default interface so we can tell it where we want to capture packets from. mgmt is the one I'm interested in limit-capture-frames is there because it limits to 10 by default and is way too fast when troubleshooting. write to output a capture file located in volatile memory (deletes when FI is rebooted.) Exit connect local-mgmt cp volatile:/mycapture.cap scp://username@linuxservername/somepath Where 'scp' is defined, can be ftp, sftp, tftp, volatile, or workspace as well. The capture file can be read in applications like wireshark . This helped me figure out my LDAP Authentication issues . Full article and explanation of how to do what I've outlined above was found here: http://...