As you may be aware, VMware has released patches for the latest security vulnerabilities. There’s patches for both ESXi and vCenter. A client reached out to me asking if I could apply these patches for them. The client has a rather small infrastructure with two sites, two Windows vCenters and few hosts per site. The host updates installed rather easily (I used VUM for this). vCenter however, was a different story.

While I wish they were using the vCSA, they aren’t there yet. I mounted the ISO and began the installation. It was going well for about 15 minutes and then I received the following error :

I am currently working for a large client that has multiple vCenters. The environment consists of three vCenters all with external PSCs. I am helping the client build out a new datacenter and it’s to the point where we can deploy a new vCenter and external PSC for this site. After deploying the VCSA and an external PSC for this site, I configured everything such as NTP, authentication, made sure DNS servers were all correct..etc. Signed into the new vCenter and verified authentication was working as intended.

Now for the fun part…

I noticed that logging into the web client, thick client or even PowerCLI with cached credentials (the check box use windows session credentials) would result in an error. PowerCLI would do something a little different and prompt for credentials which didn’t make sense because if I typed out my credentials, it logged me in just fine.

At one of my clients, I recently came across a datastore that we were unable to delete. We are in the process of migrating from an EMC VNX to a new EMC Unity SAN. Part of this process requires us to clean up the legacy datastores. Unfortunately, this isn’t a small environment and the datastores span across approximately 30+ hosts. Some quick things to check are HA and even VDS configs. In my case, I’ve reviewed everything and the datastore had absolutely nothing on it but the sdd.sf folder which stands for – SCSI device Description system file. This usually can’t be deleted and should’t be an issue. Below, I’ll walk you through a method that I used to delete the datastore. This method should be used as LAST resort as it involved deleting the partition table. You must verify that you have the correct datastore!

VMware Distributed Switches can be great in large environments or even small to mid sized environments that have quite a bit of VLANs. It makes adding portgroups/VMkernels easy because, the configuration is centralized and stored in vCenter with each host holding on to a portion of the config in case vCenter were to go down. Networking would still function but changes cant be made until vCenter is back online. I recently ran into an issue at one of my clients where we added new hosts to vCenter, configured them with networking (VMkernels/portgroups) and then needed to change their host names. This sounds like an easy task right? My client also had VMware Distributed Switches which meant that this process was going to be far from simple.

Welcome to my blog! In case you haven’t guessed it, most of my posts will involve virtualization and some Microsoft/Networking. If you’ve found your way to one of my posts and I was able to help you solve an issue, please leave a reply!