I recently had a storage network outage in my lab environment, and after powering back on my vCenter Server Appliance (VCSA) I was rudely greeted with the following information at the console:

Ouch!  I’ve never dealt with file system corruption in a VCSA before, and the internet doesn’t seem to contain much information on what to do next.  This post is my effort towards changing that.

In yesterday’s post, I updated my VCSA 6.0 appliance to version 6.5.  Today, logged into the Appliance MUI and noticed that my appliance was not able to check for updates using the default web repository.

Before we really start, a quick note on terminology.  The Appliance MUI (which means Appliance Management UI) is the new name for the old VAMI (vSphere Appliance Management Interface).  The MUI is a HTML5 web interface for configuring basic and low-level settings for the VCSA.  It’s accessible by connecting to your VCSA on port 5480.

So, what’s the deal?  Well, when browsing to the update section of the MUI and checking for updates, I would receive the following error:

With today’s exciting release of VMware vSphere 6.5, I thought I’d celebrate by upgrading the vCenter Server Appliance (VCSA) in my lab from version 6.0 u2 to version 6.5.  Since I’m doing this more or less blind, without having read any documentation whatsoever, I thought I would write a (hopefully short) post about the problems that arise during the upgrade process, and how to get past them.

A vMSC - perhaps more commonly known as a “metro cluster” -  is an architecture in which individual vSphere clusters will be spread across multiple geographical sites.  Since a vSphere cluster requires shared storage to allow VM’s to migrate across hosts, in a vMSC environment this will mean that storage must be shared or replicated across the geographical sites.  As you might expect, this kind of architecture comes with a number of gotchas and limitations, especially around the configuration of the storage arrays.  For this reason, storage vendors who support vMSC architectures have released best practices documentation specifically for designing vMSC’s with their storage products.

This is an (extremely) quick post to cover the steps required to decommission a Platform Services Controller (PSC) or vCenter Server from the vSphere single-sign on (SSO) domain.  The steps below are for a VCSA; steps for a Windows VC are very similar, and are contained in the VMware KB article I used as a reference for writing this post: KB 2106736.

Here’s a quick guide on how to query and change the Platform Services Controller (PSC) being used by vCenter.  Querying for the in-use PSC is possible on vCenter 6.0, but changing the PSC is only possible on 6.0 Update 1 or newer.  Note that I performed these steps on the vCenter Server Appliance (VCSA), and while I have also included some commands for a Windows-based vCenter server, I haven’t tested them myself.

As VMware continues to push in the direction of unix-based appliances for their vSphere management components, those without a Unix background (like myself) are having to come to grips with the Unix versions of common administrative tasks. Increasing the disk size on a vCenter Server appliance (VCSA) is one such task.  In vCenter 6.0 VMware has introduced Logical Volume Management (LVM) which really simplifies the process of increasing the size of a disk, and allows it to be done while the appliance is online.  VMware KB 2126276 covers all the steps required to increase the size of a disk, but this guide will cover it in slightly more detail.

Coming from a Windows background without much knowledge of Unix commands, I often find myself at a loss when trying to figure out how to do things on VMware’s vSphere appliances.  Managing disk space from the command line on an appliance is something I’ve had to do more than a few times, so I thought I’d create a quick list of the Unix commands I use most often to identify which partitions are filling up, and then which folders and files on that partition are consuming the most space.

If you’ve set up a vCenter 6.0 appliance or a Platform Services Controller and tried to connect via WinSCP, you will have noticed the following error: test3

Host is not communicating for more than 15 seconds. Still waiting…