Tag Archives: VCSA

Quick Fix: Increase Root Partition Size in VCSA 6.7

Full disclosure, I’m stealing Anthony Spiteri’s ‘Quick Fix’ used in the title of this post.  It’s somewhat related to a post Anthony published yesterday so I hope he doesn’t mind.  Over this past week both Anthony and I upgraded our vCenters from 6.7 to 6.7 U1.  While our problems were slightly different they both had a common issue.  Our root partitions on our Tiny install of VCSA 6.7 had either run out of space or near out of space causing upgrade issues to U1.

While Anthony was adamant in finding the root cause of the issue to free up space my solution was much simpler --just increase the space on the root volume.  I’ve seen this a number of times with Tiny installs of VCSA so I didn’t want to bother troubleshooting a Home Lab problem through the night.

TL:DR

See bottom of post for the full description of my issue.

Issue:

The VCSA root partition is at 100% or near 100% with less than 10% free space available.

[email protected] [ ~ ]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.9G 0 4.9G 0% /dev
tmpfs 4.9G 792K 4.9G 1% /dev/shm
tmpfs 4.9G 696K 4.9G 1% /run
tmpfs 4.9G 0 4.9G 0% /sys/fs/cgroup
/dev/sda3 11G 11G 0 100% /

/dev/mapper/imagebuilder_vg-imagebuilder 9.8G 23M 9.2G 1% /storage/imagebuilder
/dev/mapper/log_vg-log 9.8G 2.3G 7.0G 25% /storage/log
[email protected] [ ~ ]#

Resolution:

Increase the size of /dev/sda3

Edit the settings of the VCSA VM and located Hard Disk 1 (This disk represents device SDA).  Increase the size of the disk from 12 GB (for a Tiny appliance deployment).  In the example below I have increase it to  20 GB.

Click OK and reboot the appliance.

After the reboot SSH to the VCSA and enter the shell.

There’s a few different commands you can run at this point (see my full issue below) but the easiest command to run is below

/usr/lib/applmgmt/support/scripts/autogrow.sh

As its name implies this will auto grow the root partition with the available space just allocated.

You should now see something like below.

[email protected] [ ~ ]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.9G 0 4.9G 0% /dev
tmpfs 4.9G 792K 4.9G 1% /dev/shm
tmpfs 4.9G 696K 4.9G 1% /run
tmpfs 4.9G 0 4.9G 0% /sys/fs/cgroup
/dev/sda3 19G 9.1G 8.5G 52% /

/dev/mapper/imagebuilder_vg-imagebuilder 9.8G 23M 9.2G 1% /storage/imagebuilder
/dev/mapper/log_vg-log 9.8G 2.3G 7.0G 25% /storage/log
[email protected] [ ~ ]#

The root partition should now have sufficient space for normal operation or upgrades.

 

 

Full Issue:

During an attempt to update my VCSA from version 6.7 to 6.7 U1 I encountered the following error in the VAMI.

Update installation failed. vCenter is non-operational

Attempting to log onto the appliance may also cause intermediate issues.

Error in method invocation Field messages missing from Structure com.vmware.vapi.std.errors.service_unavailable

Checking the space usage on my appliance showed that I only had 5% free space which appeared to not be sufficient for an appliance upgrade.

[email protected] [ ~ ]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.9G 0 4.9G 0% /dev
tmpfs 4.9G 792K 4.9G 1% /dev/shm
tmpfs 4.9G 696K 4.9G 1% /run
tmpfs 4.9G 0 4.9G 0% /sys/fs/cgroup
/dev/sda3 11G 9.1G 900M 95% /

/dev/mapper/imagebuilder_vg-imagebuilder 9.8G 23M 9.2G 1% /storage/imagebuilder
/dev/mapper/log_vg-log 9.8G 2.3G 7.0G 25% /storage/log
[email protected] [ ~ ]#

After a little bit of troubleshooting and attempting to locate the correct vCenter Hard Disk that /dev/sda3 represented.  I identified that Hard Disk 1 was the correct vCenter disk.  /dev/sda3 has multiple partitions and the actual size of /dev/sda is 12GB for a Tiny VCSA install.

To correct the issue I increase the size of this disk to 20 GB, rebooted the appliance, and ran the below command.

/usr/lib/applmgmt/support/scripts/lvm_cfg.sh storage lvm autogrow

This command auto grew the root partition with the available space on the disk that I had just allocated.  I later found out that autogrow.sh is a much simpler command to run and that lvm_cfg.sh wasn’t available anymore after upgrading to VCSA 6.7 U1.

Running Docker inside of VCSA 6.7

During this years VMware {code} Hackathon at VMworld Vegas I submitted a team project which ran PowerShell within the vSphere Client.  To achieve this I had to create a Docker container running PowerShell Core.  During development I ran the container on an Ubuntu Linux server.  For my final submission at the Hackathon I wanted to minimise the dependency to run a separate Linux VM.  So I created a process to install and run Docker directly on VCSA 6.7.

The process to install and run Docker within VCSA 6.7 is surprisingly very simple.  As a reference I used a blog post from William Lam but with a small modification to correctly load the Bridge module in VCSA 6.7 (as opposed to VCSA 6.5 in William’s post).

I thought I would share the steps I used below for others to experiment with.

Step 1.
SSH to the VCSA VM and enter the Shell

Install the docker package

tdnf -y install docker

Step 2.
Load the kernel module to start the Docker client. (This step needs to be re-run if the VCSA is rebooted)

modprobe bridge --ignore-install

If successful no information should be returned.

You can check if the module is installed by running the following

lsmod | grep bridge

[email protected] [ ~ ]# lsmod | grep bridge
bridge                118784  0
stp                    16384  1 bridge
llc                    16384  2 stp,bridge

Step 3.
Enable and start the Docker Client
systemctl enable docker

systemctl start docker

 

Making the Bridge module load after a reboot (Optonal)

As with William’s process to install and run Docker Step 2 needs to be re-run each time the VCSA is rebooted.  The solution to make the Bridge module automatically load after a reboot happens to be exactly the same.  I’ve included the specific commands to simplify the process.

Step 1.
Make a backup of the file we are going to modify.

cp /etc/modprobe.d/modprobe.conf /etc/modprobe.d/modprobe.conf.bak

Step 2.
Comment out the line that disables the Bridge module from loading

sed -i "s/install bridge/# install bridge/g" /etc/modprobe.d/modprobe.conf

Step 3.
Create a new config file to load the Bridge module

touch /etc/modules-load.d/bridge.conf

Step 4.
Specify the name of the Bridge module to load at reboot

echo bridge >> /etc/modules-load.d/bridge.conf

That’s all we need to do to start running containers on VCSA 6.7.  Excluding the steps to have the Bridge module persist after a reboot and it’s even simpler.

 

Running a Docker container

If you want to test your first container on VCSA you can try my Docker image I build for the Hackathon.  The steps are very simple and listed out below.

Step 1.
Download the two required files from my GitHub repo

curl -O https://raw.githubusercontent.com/originaluko/vSphere_PowerCLI/master/Dockerfile

curl -O https://raw.githubusercontent.com/originaluko/vSphere_PowerCLI/master/supervisord.conf

Step 2.
Build the Image

docker build -t vsphere-powercli .

Step 3.
Start the container with this image

docker run -d -p 4200:4200 --name vsphere-powercli vsphere-powercli

You can check if the docker container is running with the below command.

docker stats

You can check if the port has been mapped correctly by running

docker port vsphere-powercli

Step 4.
Open a web browser and test if you can connect directly to the container through the browser and login to the PowerShell prompt.

https://{my_vcsa}:4200

Accept any certificate warning and login with the default credentials of powercli / password

I hope that was all fairly straight forward  to understand.  It’s actually all very simple to achieve under VCSA 6.7.  As in William’s post, none of this is supported by VMware, so user beware.  Though I have been playing with Docker inside of VCSA 6.7 for quite a few months now with no noticeable issues.

If you want to see my full VMworld Hackathon project you can check it out over in my GitHub repo

VMware Update Manager (VUM) Fails To Load Within vSphere Web Client

I recently upgraded my lab VCSA from version 6.5 (Build Number 5705665) to version 6.5 U1 (Build Number 6671409).  After the upgrade I noticed that VMware Update Manager was no longer working correctly.  Navigating around the various VUM pages I received the same consistent error message.

interface com.vmware.vim.binding.integrity.VcIntegrity is not visible from class loader

VUM management page

VUM Tab within an ESXi host

Checking the vCenter services within Administration > System Configuration they all appeared Up and Running.  Though all services were running I never the less restarted the VMware Update Manager service which unfortunately didn’t help.  I also tried restarting a few other services without much success.  So rather than just continuing to randomly restart services I decided to take a tougher approach and restart all services from the CLI.

After the stopping and starting of all vCenter services, which took a few minutes, VUM was back up and running again within the vSphere Web Client.  While this was a fairly drastic step to take, so would have been rebooting the vCenter server, which I’m glad I managed to avoid.

I’ve previous written about restarting vCenter services.  The process is quite simple.   First connect up to the CLI of the VCSA box.  Then run the below two commands.  Both the stopping and starting of services will take a few minutes each.  Once the services are restart the Web Client will take a further few minutes to fully start up and be accessible.  If all is successful Update Manager should be accessible once again.

Command> service-control --stop --all

Command> service-control --start --all

Restarting all the vCenter services like this is obviously a disruptive action.  Connectivity to vCenter will be dropped while the services restart.  Usually restarting all services on vCenter via the CLI is my last ditch attempt to resolve an issue before I attempt a reboot of the appliance.  While restarting the VCSA might have been the easiest thing to do to resolve this issue it’s not always necessary.

Modify HTML5 vSphere Client Idle Timeout

Before I go any further, just to make it clear, we’re talking about the new HTML5 client in vSphere 6.5 (GA Build 4602587).  Not the older Flash based vSphere Web Client in vCenter 5 and 6.  So lets call it the vSphere vCenter HTML5 UI Web Client.  Clear now?  Ok, just refer to the pic below.

Below are the steps I used on the vCenter Server Appliance.

Just like the old Web Client I know of no way to change the idle timeout from within the UI today.  So we have to revert to connecting to the console and making the changes through the shell.  We do this by opening up a console window to the VM or using SSH and login with root (remember to enable SSH first).

At the Command prompt of the VCSA type the following to enable Shell access.  You may received a Shell is disabled message.  If you do, enable with shell.set.

Command> shell
Shell is disabled.
Command> shell.set --enabled true
Command> shell
vc01:~ #

Now at the Shell type the following below and locate session.timeout.

cat /etc/vmware/vsphere-ui/webclient.properties

You should find something similar to session.timeout = 120 as this is the default value in minutes.

Make a backup copy of webclient.properties.

cp /etc/vmware/vsphere-ui/webclient.properties /etc/vmware/vsphere-ui/webclient.properties.bak

If you’re comfortable using an editor like VI go ahead and use that to increase or decrease the value in minutes.  Probably for the best, it doesn’t appear that you can set this value to never timeout.  I tried 0 and -1 and both caused the vSphere Client to timeout instantly on login.  The timeout value, though, can quickly and easily be modified using the sed command.

The sed command below locates the specific string session.timeout = 120 and replaces it with session.timeout = 720, which is 12 hours (or in other words my standard work day).  Change 720 to however many idle minutes you want.  If sed doesn’t find the specific string, don’t worry, it won’t modify anything.

sed -i “s/session.timeout = 120/session.timeout = 720/g” /etc/vmware/vsphere-ui/webclient.properties

Run the cat command again and check that the session.timeout value has changed.

cat /etc/vmware/vsphere-ui/webclient.properties

If the session.timeout value has been modified correctly we now have to stop and restart the vsphere-ui service by running the following commands below.  I covered stopping and starting all services on a VCSA in a previous post HERE.

service-control --stop vsphere-ui
service-control --start vsphere-ui

Wait a few minutes for the service to start up fully and open a new browser windows to the vSphere Client.  It should now be running with a new idle timeout.

 

SCP to a vCenter Server Appliance (VCSA)

For some this may be a rare situation but from time to time I find that I’m needing to copy files to and from a vCenter Server Appliance (VCSA).  I had one of these situations recently on vCenter 6.  I needed to move some log files off a VCSA box.

I’ve found the easiest way to do this is via SCP -- Secure Copy, which uses the SSH protocol.  It’s a relatively simple process to enable the VCSA to accept SCP connections.  It’s a two step process which first requires enabling SSH on the VCSA and then switching the default Shell.

Step 1, involves enabling SSH  

I’ve written a previous post on how to enable SSH on a VCSA here.  Since that post VMware have re-released the VAMI on vCenter Server Appliance V6 U2.  So I thought I might show this new method to enable SSH.  Only if using VCSA 6 U2 or greater else use my previous post steps.

Connect to the VAMI URL of your vCenter on port 5480 using HTTPS.  In my case it was https://vc.ukoticland.local:5480/login.html

vami-000298

Login with your VCSA root account and password.  Then navigate to Access and click Edit on the far right.  Select Enable ssh login and to make life a little easier also Enable bash shell and click OK.  The timeout refers to how long the Bash shell will stay enabled.  The default is fine.

vami-000299

Step 2, changing the default shell

Even though we enabled the bash shell above the default shell is still the VMware appliance shell which prevents us from connecting to the VCSA via SCP.  So we need to SSH to the VCSA and change the default Shell from the Appliance Shell to Bash.

In my case I used Putty.  Logged in with my root account and type shell.

putty-000300

Now i can change the default shell for the root user to bash using the below command.

chsh -s /bin/bash root

putty-000301

We’re now ready to SCP to our VCSA with the ability to transfer files to and from the VCSA.  I use the simple Windows app, WinSCP.  I change the File Protocol to SCP.  I enter in my vCenter as my host and my root credentials.

winscp-000302

When you’re complete just reverse the changes you made.   In the SSH Putty session type the below to permanently switch the Bash shell back to the default Appliance Shell.  Then log back into the VAMI as above.  In Access deselect SSH and Bash.

chsh -s /bin/appliancesh root

References

Toggling the vCenter Server Appliance 6.x default shell (2100508)

Onyx For the Web Client now supports vSphere 6.0 U1

It’s been a while since I’ve used the Onyx VMware Fling.  The last time I used it was way back in 2013 running the Project Onyx version that sat as a proxy between the C# vSphere Client and vCenter.  It was a great little Fling back then.  I had a good laugh when I looked at one of my old blog posts about Project Onyx and how I felt its lifespan was limited due to the C# client being phased out for the Web Client.  Two years later and the C# vSphere Client is still going strong.  Com’on VMware, do it already 😛

Well, Onyx is now back in an all new way and it now supports the vSphere Web Client.  In fact it was released back in July 2015 but has just undergone another update for vSphere 6.0 U1.  If you’re not sure what Onyx is.  It’s a tool that allows you to record your vSphere Client actions and display them back as PowerCLI API method calls.  I found Onyx useful in years past when the PowerCLI cmdlets weren’t as mature as they are today.  Thought, today there’s still a lot of things you can’t do with the standard PowerCLI cmdlets and recently I’ve been finding I’ve been delving into the API methods more and more.  So it’s great to see support for the Web Client in Onyx now.

There are two versions of Onyx For the Web Client.  The 6.0 release and the 6.0 U1 release.  It’s important that you use the version matching your vSphere.  I learnt the hard way recently how dangerous VMware Flings can be.  I installed the 6.0 release onto vSphere 6.0 U1 and broke my vCenter good and proper.  With the latest release of Onyx only a few weeks back it now once again supports the latest vSphere Web Client.

Installation is quite simple.  In my case I’m installing to the vCenter Server Appliance (VCSA).  You download the Onyx Fling from here.  Then extract its contents to a local folder.

I then console into my VCSA and enable and change my shell to BASH

shell.set --enabled True
shell
chsh -s /bin/bash

I can now use SCP to copy the files from my local computer to the VCSA using WinSCP.  It’s just a matter of dragging the onyx-setup-60u1 folder from my computer the to the /root directory on the VCSA.

onyx_winscp-000248

Now back on the VCSA I run

cd /root/onyx-setup-60u1
chmod +x ./install.sh
./install.sh

When the install script completes it will restart your vCenter web services.  It will take a few minutes to fully restart so don’t panic if you start receiving errors when trying to browse to the Web Client.  Once the services completely restart make sure you have closed you web browser tab and reopen it to the Web Client.

It’s also ideal to change the shell back to the Appliance Shell

chsh -s /bin/appliancesh

onyx-000249

Using Onyx is super simple.  It can be found under the Inventories in the Web Client.  Also pinned to the top right corner you have to two buttons.  A Red Record icon and a PowerCLI button.  Pressing the Red Record button starts recording your web session interactions.

onyx-000251

When you’ve completed with you actions we click the same record button which has turned to a Stop button.  Pressing the PowerCLI button now shows us the PowerCLI API calls that took place to perform our actions.  All cleanly laid out with syntax highlighting.  There’s also the ability to save the output as a PowerCLI script.

That’s it really.  There’s not a great deal to this Fling.  If you don’t do much PowerCLI you might not find this Fling overly special.  If on the other hand you are using PowerCLI on a regular basis I’m sure you’ll find it interesting.

Word of warning; Onyx For the Web Client is a VMware Fling and as such does not come with official VMware support.  Onyx is best suited to a Dev and Test environment and is not really recommended for Production environments.

References:
Onyx For The Web Client

VCSA 6.0 Update 1 returns the VAMI

Earlier this month Update 1 for the vCenter Server Appliance 6.0 was released.  With all the cool things coming out of VMworld, like vSphere Integrated Containers, Photon, EVO SDDC, I think Pfft, Update 1 for vCenter and the return of the VAMI was the most exciting thing for me.  But no, seriously, this has been something I’ve been hanging out for.  I always found it odd that it was missing in vCenter 6.  It appears that it was really just a priority issue and not being ready in time for the GA release of 6.0.

If you’re not familiar with VAMI or as it’s better known now as Appliance Management User Interface.  It’s been in the vCenter Server Appliance since version 5.0.  It allowed an easy way to manage host based settings on the appliance such as networking, time & NTP, and the ever important patching.  When I started moving to VCSA 6.0 I had to learn new ways to configure these settings.  So thank God I can now forget.  The Interface has been completely rewritten in HTML5 keeping to the VMware theme.

Photos-000239

Access to the new Appliance Management User Interface (I guess AMUI for short now???) is on the same original port of 5480, (https://<fqdn or ip>:5480).  Log in with the root account and password.

When you log in you are faced with a Summary screen.  Here you get an overview of your Health Status, SSO status, version and Installation Type along with options to Reboot and Shutdown.

Photos-000240

On the left you have the Navigation Pane.  From here you can select and modify a number of different settings.  The Access page allows you to enable SSH and the Shell.  Networking for your DNS and IP details.  Time is a big one.  Prior to this you had to use the Shell to modify NTP settings, I recently wrote up a post on the process to modify VCSA NTP settings with the VAMI.

The Update page is also another important one.  Checking for patches is now no harder than a simple click or better yet a daily scheduled time.  Installation is just as easy with another click.

VMware Appliance Management-000241

The last page is Administration.  Here you can easily change the root password and change the Root Password expiry mode.  Most places may want this on but if your managing many vCenters it can be quite hard to stay on top of and if using strong passwords maybe not that critical.

VMware Appliance Management-000242If you’re currently running a vCenter Server Appliance you can get to version 6.0 Update 1 by either Upgrading or Patching.  The two methods are very different.  The upgrade method, by all accounts, is similar to previous.  It involves deploying a new appliance and performing a migration.  All relatively simply.

The patching process on the other hand is a little less involved and my preferred option.  It requires downloading a much smaller ISO and mounting it to the appliance.  You’ll need to already be on version 6.0.  As mentioned above the VAMI doesn’t currently exist so it has to be patched from the console.  I’ve written previously about patching a vCenter Server Appliance from the Shell.  The process is essentially the same and worth a look if you’re not familiar with it.

I highly recommend reading the Release Notes and looking at patching up to this latest version.  It resolves a number of outstanding issues from previous releases.  JRE has been updated along with SSLv3 being disabled.  My initial home lab upgrade took only 10 minutes.

So get to it!

References

Update for VMware vCenter Server Appliance 6.0 Update 1 (2119924)

VMware vCenter Server 6.0 Update 1 Release Notes

Increase vSphere Web Client Idle Timeout on VCSA 6

What I really like about the vCenter C# Client was that you could stay logged indefinitely.  Maybe not the best thing from a security stand point but it was damn convenient.  The vSphere Web Client on the other hand has always had an idle timeout value.  From a home lab point of view it’s really frustrating constantly being logged out.

The default idle timeout in the vCenter Server Appliance 6 (VCSA) is 120 minutes.  I know of no way to modify this via the Web Client itself but it is modifiable via the Shell.  The timeout value is contain in the webclient.properties file.  The location of this file has changed from previous versions of the VCSA.    Prior to version 6 it was found in /var/lib/vmware/vsphere-client/.  In version 6 it’s found in /etc/vmware/vsphere-client/.

At the Command prompt of the VCSA type the following to enable Shell access.

Command> shell
Shell is disabled.
Command> shell.set --enabled true
Command> shell
vc01:~ #

Now at the Shell type the following below and locate session.timeout.

cat /etc/vmware/vsphere-client/webclient.properties

You should find something similar to session.timeout = 120 as this is the default value.

Make a backup copy of webclient.properties.

cp /etc/vmware/vsphere-client/webclient.properties /etc/vmware/vsphere-client/webclient.properties.bak

If you’re comfortable using an editor like VI go ahead and use that to increase or decrease the value in minutes.  The timeout value, though, can quickly and easily be modified using the sed command.

The sed command below locates the specific string session.timeout = 120 and replaces it with session.timeout = 1440, which is 24 hours.  Change 1440 to however many idle minutes you want.  If sed doesn’t find the specific string, don’t worry, it won’t modify anything.  To set the client to never idle timeout set the value to 0.

sed -i “s/session.timeout = 120/session.timeout = 1440/g” /etc/vmware/vsphere-client/webclient.properties

Run the cat command again and check that the session.timeout value has changed.

cat /etc/vmware/vsphere-client/webclient.properties

If the session.timeout value has been modified correctly we now have to stop and restart the vsphere-client service by running the following commands below.  I covered stopping and starting services on a VCSA in a previous post.

service-control --stop vsphere-client
service-control --start vsphere-client

Wait a few minutes for the service to start up fully and open a new browser windows to the vSphere Web Client.  It should now be running with a new idle timeout.

As a general disclaimer you should only be going into the Shell on the VCSA if you are comfortable with what you are doing.  Of course make a backup of any files you are modifying and, of course, to play it safe take a snapshot of the VCSA VM.

References

Configure the vSphere Web Client Timeout Value

Stopping and Starting Services on vCenter Service Appliance 6 (VCSA)

In my previous post I wrote about patching a VCSA box.  At the end of that patching processes a reboot (according to VMware) is an optional step.  However, in my case, the vCenter Web Services didn’t appear to have restarted correctly.  A reboot ultimately did resolve that issue for me, but it did start me thinking about how would I go about restarting VCSA services if the Web Client was down.  It turns out vCenter 6 has a new recommended way of restarting services using the Service Control command for both the VCSA and the Windows version.

As with my post on modifying NTP settings.  Restarting services can be done via two methods, the Web Client or via the console.  Method 1 is the easiest when access to the Web Client is there.  Method 2 relies on using the VCSA console when access to the Web Client doesn’t exist or is lost.k

Method 1.
Restarting services via the Web Client

On the Home screen of the Web Client select Administration -> System Configuration

enable_ssh-000182

Click on the Services button on the right pane.

restart_ssh-000210

As I’ve mentioned previously finding what you want in the Web Client isn’t always intuitive as you might think.  Clicking on Services in the left pane isn’t what you want.  Rather clicking on the Services tab button on the right pane gives you a better overall status of services.

restart_ssh-000219

From here was can right click on any services, start, stop, restart, edit startup, and change settings on that service.  Not all services have modifiable settings via the Web Client.  This options will show up grayed out.  Once you change the state of a service you’ll find you have to refresh the page for the next state to be displayed correctly.

restart_ssh-000220

Method 2.
Restarting services via the Console

I’ll assume you already know how to enable and have access to SSH or at least the Remote Console.  If not I cover enabling SSH here.

You may come across doco that says you have to enable and enter the pi shell / bash, but this isn’t required.  Everything can be done from the VMware Command prompt

We can start of by running a command that simply lists services.

Command> service-control --list

This will list all vCenter specific services.  We can then run service-control --status for a bit of a messy view of what’s currently Running and Stopped.

Command> service-control --status

Unlike the Web Client there is no restart Service Control switches, Only start and stop.  To stop a service we run the below at the prompt.  servicename being the name of a service displayed using --list

Command> service-control --stop servicename

or to start

Command> service-control --start servicename

You can also use the --all switch in place of servicename.  I see this as a bit of a catch all.  Using this switch will only start services that have a startup type of Automatic and are currently stopped.  If a service is currently running it will be skipped.  This is a great way to get everything back up and running quickly.

Command> service-control --start --all

The reverse is true when using --all to stop services.  All services that have a startup type of Automatic and are currently running will attempt to be stopped.  Everything else will be skipped.

Command> service-control --stop --all

There are two final switches that can also be used with the --all.  --ignore and --dry-run.  The --ignore will continue to start or stop all services if an error is encountered at any point.  --dry-run will display what actions the take place with the service without actually changing anything.

Command> service-control --start --all --ignore
Command> service-control --start --all --dry-run

References

Stopping, starting, or restarting VMware vCenter Server Appliance 6.0 services (2109887)

 

Patching vCenter Server Appliance 6 (VCSA)

The biggest thing I miss from the v5.x release of the vCenter Server Appliance was the VMware Appliance  Management Interface (VAMI).  I first realised it was missing in VCSA 6 when I needed to modify NTP settings.  What I liked about the VAMI was that it could auto check and install patches.  With it now removed we’re back to a manual check and apply process 🙁

So to get started… The easiest way to check what build you are on is in the vSphere Web Client.  Navigate to vCenter Inventory Lists -> vCenter Servers and click on your VC.

Windows 8.1 Pro - VMware Workstation-000174

Once you know what build you are on head over to Product Patches at https://my.vmware.com/group/vmware/patch#search

Select VC as the product and 6.0.0 as the version.  Note the releases.  One will be for the Windows version and one for the Appliance.  Windows versions still require downloading the full product to update.  While the Appliance gets away with a smaller yet still relatively large 1 GB patch file.  Both releases, though, can still apply minor patches individually.

https___my.vmware.com_group_vmware_patch#search-000175

Download the 1 GB ISO file (or whatever is current at the time).  Mount the ISO to the vCenter Appliance VM as you normally would with any ISO file.

vcsa_patch-000176

Now login to a console session on the Appliance and run the following command

software-packages install --iso --acceptEulas

vcsa_patch-000177

The --acceptEulas is optional.  If you choose to leave it out you will have to scroll through the VMware End User License Agreement and type yes to accept.

Command> software-packages install --iso
[2015-06-13T12:21:59.164] : Staging software update packages from ISO
[2015-06-13T12:21:59.164] : ISO mounted successfully
[2015-06-13 12:21:59,076] : Running pre-stage script…..
[2015-06-13T12:22:00.164] : Verifying staging area
[2015-06-13T12:22:00.164] : Validating software update payload
[2015-06-13T12:22:00.164] : Validation successful
VMWARE END USER LICENSE AGREEMENT

Do you accept the terms and conditions? [yes/no] yes

This process will now automatically Stage the patches to the VC and proceed to immediately install.  During this process management to the VC will be lost.  So keep this in mind for your users.

Once complete you will receive a message that a Reboot is required to complete the installation.  According to VMware doco this is an optional step.  That said, after my upgrade completed, I still had no management connectivity via the Web Client or C# client and so ran shutdown reboot -r and proceeded to reboot the appliance.

[2015-06-13T12:29:53.164] : Packages upgraded successfully, Reboot is required to complete the installation.
Command> shutdown reboot -r “I have been patched”

Additional Commands (optional)

If you want to see the last patches that were applied run the below command

Command> software-packages list --history
[2015-06-13T12:54:03.164] :
‘Name’ ‘Install Date’
VC-6.0.0a-Appliance-FP 2015-06-13 12:29:52

References

VMware reference doco
Patching the vCenter Server Appliance