Tag Archives: vsphere

Deploying HCX Cloud Manager – Part 1

HCX is a magical tool. It allows “Modernization of Mission-Critical Application Infrastructure with a minimal operational overhead, without requiring a retrofit of your legacy infrastructure“. It’s a mouthful right, straight from the HCX product pages. My explaination, in clearer terms, is “it allows you to connect one vCenter in one SSO domain to another vCenter in another SSO domain and migrate VMs“. That’s about as simple as I think I can put it. Yes it can do other stuff but in a nutshell this is its biggest use case.

It’s this exact scenario that I want to try and cover in the next few posts. Deploying and configuring HCX in a datacenter to migrate between two on-prem vCenter servers. Going from a legacy vCenter environment to a new SDDC environment with NSX. I plan on covering just the fundamentals to get HCX up and going as quick and easily as possible.

This guide is going to be long, there’s no way around that. We will initially cover the installation in the destination / target site using the Cloud version of HCX. Along the way I’ll call out anything notable. I recommend going through the pre-installation checklists and covering off the requirements prior to starting.

The first thing we want to do is download the HCX Cloud installer from the My VMware portal and start an OVF deployment. I’m basis the deployment off the R133 release. I recommend using the old Flex Client vs the new H5 client which will no doubt fail to deploy the OVF.

Give the HCX Cloud manager a name and location to deploy.

Select a Datacenter and Cluster.

The OVF Template will validate and present its details.

Scroll down and accept the license agreement.

Select your storage and policy.

Select your network. It’s critical you pick a network that has good connectivity to the rest of your network to save yourself a lot of grief later on. HCX connects to many different services. Ideally it’s on your same management network as vCenter and the rest of your services. There’s a good London Underground PDF map of all the services and ports you will require. If your using firewall rules between your services and network segments this will no doubt be one of the more trickier tasks.

Fill out all the customisations. Passwords, IP addresses, DNS, NTP, etc.

Review your settings and deploy the appliance.

Once the OVF is deployed, power on the VM and browse to its URL on port 9443 to start the configuration wizard (https://hcx-manager:9443). Login with admin and the password you defined during deployment.

Once you login you are given the option to Activate the HCX instance. You can skip this step for now and Activate later. Notice that the type is Cloud. Cloud is what other HCX types (Cloud & Enterprise) connect to.

Define the location of your datacenter. This really doesn’t matter what you select.

Give the manager a system name (hostname).

Select the type of instance to configure. vSphere in this case.

Next we configure vCenter and NSX details that we want to pair up to. This is the vCenter and NSX Manager in the destination / target site we are deploying to. HCX Cloud Manager requires NSX. HCX Enterprise does not. Enterprise can only pair to HCX Cloud but Cloud can pair to other HCX Cloud Managers. This is an important point if you have more than two vCenters and you want to create multi site pair relationships.

Enter in your PSC details. Internal, External, whatever the flavor of the month was when you build vCenter.

Add in the public URL of this HCX Cloud Manager. Most likely this is just the same as your internal DNS name you gave this server.

Finally review your settings and click restart. In a few minutes it will auto login to the management interface.

We’re on the home stretch now. Just a few final pages to check. Click on the Administration Tab and if you’re using a Proxy enter it in. HCX Manager needs to access two external URLs. (connect.hcx.vmware.com and hybridity-depot.vmare.com). I also recommend putting in your internal networks in the Exclusions.

The last thing we need to update on this tab is the Trusted CA Certificates. If you’re using Self-Signed certificates for HCX you need to add them here. You haven’t built a second HCX Manager yet so when you do come back here and add it in. I also like to add in my vCenter servers and NSX servers I’ll be using. I do this really just to sanity check that HCX Manager still has connectivity to this servers after I add a proxy server.

Now head over to the Configuration Tab. You can now enter in your HCX Advanced Key under Licensing. In my case I’m using my NSX key. You may also have an HCX Enterprise key for advanced features but I won’t be discussing any of them so we can ignore it for now.

Finally update the vSphere Role Mapping. This is granting access to log into the User Interface of HCX Manager.

Head over to the Appliance Summary Tab and give the appliance one last reboot and we’re done with the appliance configuration.

Super simple right? Now do it all again for the second HCX Manager in your second (source) datacenter! You have two options at this stage. Use the same HCX Cloud Manager installer or log into the HCX Manager User Interface (drop the 9443 in the URL) and under System Updates download the Enterprise version. Again, the difference being that Enterprise doesn’t ask for or use NSX, at least in the use case I’m covering.

In the next part I will cover creating Site Pairs and Interconnects between these two HCX Managers. This will all be performed from the source site HCX Manager.

VMware {code} Hackathon – VMworld Vegas 2018

It was a tough decision.  Hit up the Cohesity party and watch Snoop Dogg perform or participate in the VMware Code Hackathon.  No, the decision was easy, I was always going to take part in the Hackathon.  I had regretted not taking part last year and I was super keen for this year’s hackathon, I wasn’t going to miss it.  I think it’s safe to assume I chose wisely.  With my team, Team vMafia, coming away with the winning project and an impromptu segment on Virtually Speaking!

Left to right: Anthony Spiteri, Matt Allllford, Mark Ukotic, and Tim Carman

This year’s Hackathon broke from the format from previous years.  Whereas in previous year you showed up, attempted to form a team and an idea, then execute all within a handful of hours.  This year the Hackathon chose to leverage HackerEarth and give participates three weeks to create a team and build out a hackathon idea.  Without a doubt this was the single biggest improvement to the format of this years event.  Leading to some great projects being built.

Rewind a month, In the week leading up the Hackathon I started thinking about an idea I could submit.  Struggling to think of something I started playing a bit of buzzword bingo.  PowerShell and PowerCLI were big passions of mine.  Docker was an area I wanted to explore more into and I had wanted to learn more about what the vSphere SDK could do.  At that point an idea just naturally presented itself.  Could you run a PowerShell console with PowerCLI modules inside the new HTML5 vSphere Client?

At this point I didn’t know I had a good idea, let alone just an idea.  I ran it past some friends within a local Aussie Slack group I’m part of.  It went down extremely well but I still had my doubts.  So I did what anyone would do and went to ‘other’ friends who also thought it was a great idea.  So OK I thought, I have an idea.

Having recently quit my job I was able to focus 100% of my attention to the project.  Great for me and the Hackathon, I guess bad for everyone else with jobs 😛  I formed a team and without any persuasion a number of the Aussie Slack team jumped on-board including Anthony Spiteri, Matt Alffford, and Tim Carman.  We were going to need a lot of help so I reached out to a few friends for assistance.

First up was my ex-manager John Imison for some assistance around Docker.  Installing Docker and running a container is one thing.  But building a container image was something new.  John provided some great advice and ideas around building the docker image.  Actually far too many for a Proof of Concept hackathon idea that I could implement in a practical timeframe.  If this project continues to develop past hackathon expect to see some more of his ideas integrated in.

Next I hit up my Developer brother-in-law Simon Mackinnon.  After spending a couple days crying in front of my computer attempting to build and configure my vSphere SDK environment.  I went to Simon for help in decipher the vSphere Plugins.  Simon helped put us on the right track with finding the easiest solution to embed a console into the vSphere Client.

After a solid week of learning Docker and the vSphere SDK it was time to actually build something and put it all together.  Believe it or not this was actually the easiest part of the whole project.  Once I knew how to build a Docker image it was just a matter of customising it for my purpose.  The same went for the vSphere Plugin.  Take a sample plugin and modify it for purpose.

The night of the Hackathon at VMworld was fairly cruisey for Team vMafia 2.0.  Our project was built.  We performed some final testing to prove it all worked.  We gave some of the judges a walk-through of what we built.  I should point out that the night was extremely well run.  Previous years had some controversy around the event.  None of that existed this year.  Two rounds of hot food was served with lots of drinks and candy lollies to be had.  With WiFi and Internet stable and strong.  The event was pushed back from an original start time of 6:30 to 7:30.  This was due to some of the judges holding training sessions / presentations on some of the hackathon themes.  At 10 PM all the teams were given two minutes to present their ideas and projects in front of a projector.  A completed project was not a requirement to present.  The judges had a number of criteria they were working off for judging, such as how well you kept to your 2 minutes and how well you conveyed your idea.

Team vMafia were one of the last to present.  I was certainly not confident as there was some great ideas before us.  I spoke for our team.  I’m not sure how long I presented for but it was definitely less than the 2 minutes.  During the entire presentation i had Anthony Spiteri whispering in my hear, ‘hurry up, don’t waste time, go go go’.  Distracting, yes, but he did keep me on point.  The judges then left the room to vote.  They came back pretty quickly with it being a unanimous decision that Team vMafia had the winning idea of an integrated PowerShell console inside the H5 vSphere Client.  It was not until they called our name that I thought, ‘Hey, maybe we do have a good idea’.

Screen of vSphere PowerCLI being used within the vSphere Client

The night didn’t quite end there for Team vMafia.  After the event we passed by Eye Candy in Mandalay Bay where we ran into the Virtually Speaking guys, Pete Flecha and Glenn Sizemore.  While Anthony denies it , I think this was his master plan for us to bump into them.  We had some great conversations with the guys and they were super excited for our Hackathon project and win that they invited us onto the podcast the following day.

The episode of Virtually Speaking with Team vMafia can be found here.   While I find it hard to listen to myself I’m assured that the segment was really good and funny.  Our segment also managed to make the cut in the same episode as Micheal Dell and Pat Gelsinger which I have to say is pretty cool.  I huge thank you to Pete and Glenn for allow us to come into the show!

Finally I can’t end without linking to the actually project.  During the development I used my own private repos but have now moved it over to my GitHub page.  The project has the very original name of vSphere PowerCLI.  As far a disclaimers go the project is free to download and use at will.  I’m not really holding any restriction on it.  It was always just a Proof of Concept idea I had.  The instructions are hopefully fairly easy to follow.  Most people have been taking a snapshot of their VCSA and using the option to run Docker on their VCSA.  If the support is there I’ll be considering developing the project past hackathon idea.

Thanks for everyone’s support and kind words and let me know if you’d like to see the project developed further.


Getting Started With Ansible And VMware

For a little while now I’ve been playing around with Ansible and exploring its VMware modules.  While using Ansible with the VMware modules is not overly complex.  I quickly realised there were very little examples out on the web for the VMware administrator.   So I thought I would put together a very simple crash course on getting starting with Ansible and VMware.

The intention here is not to explain how Ansible works.  There’s a lot of information out on the web around that, plus I’m still learn too.  Instead I just wanted to put together something relatively simple.  Show how to quick and dirty get Ansible installed on a Linux box with the required VMware SDK.  Then create an Ansible playbook to build a basic environment in vCenter.  This will involve a new Datacenter, a Cluster, and a Resource Pool.

So let’s get started.

Installing Ansible

Firstly let’s install Ansible.  Ubuntu and CentOS are common distros so I cover them both below.  With Ubuntu I also add the Ansible repository.  While I don’t believe it’s really required it seems to be what most people do.


sudo apt-add-repository ppa:ansible/ansible

sudo apt-get install ansible


sudo yum install ansible

Once installed we can run a simple verification check to see if the install was successful.

ansible -m ping localhost

localhost | SUCCESS => {
"changed": false,
"failed": false,
"ping": "pong"

Installing pyVmomi

Now we install pyVmomi.  This is VMware’s Python SDK for managing vCenter and ESXi and is required to use the VMware modules that come with Ansible.

sudo pip install pyvmomi

And that’s all that we really need to install to build our first playbook and run it against vCenter.  To run our playbook we’re going to need to create a few folders and files.  The structure will look something similar to below.

├── ansible-vmware
│   ├── group_vars
│   │   └── all.yml
│   └── vmware_create_infra.yml

Let’s create a folder called ansible-vmware and a varibles folder called group_vars below that

mkdir ansible-vmware
mkdir ansible-vmware/group_vars

Now even though this is a crash course to running our first VMware playbook I want to at least do things half right and not have any plaintext passwords.  So before I go too far into creating the yaml files I want to create an encrypted string of our vCenter’s administrator SSO password.  I do that with the following line.

ansible-vault encrypt_string {admin_sso_password} --ask-vault-pass

You’ll be asked for an Ansible vault password and then receive back an encrypted string.  The vault password will be used when we run our play (don’t forget it).  Copy and paste the output and put it aside for a minute.  We’re going to pasta it in our group_vars file that we’re about to now create.

Let’s now create that variables file inside the group_vars folder and call it all.yml

touch ansible-vmware/group_vars/all.yml

Using vi or nano or whatever you prefer to edit the file.  Let’s edit the all.yml file and add in all the variables we will use in our playbook.  Again, crash course, so don’t worry too much about what each one does right this minute.  Just know that we have to reference these values multiple times in our playbook and having a variables yaml file really helps with that.

For the vcenter_password variable use the encrypted string we created in the step above and paste it in so it looks similar to below.  Obviously feel free to change any of the values, datacenter, cluster, etc.

datacenter: ansible_dc1
cluster: ansible_cluster1
resource_pool: ansible_resource1
datastore: datastore01
vcenter_username: administrator
vcenter_password: !vault |

Now we create our main playbook.  This is going to contain all our plays and reference all our variables we just created in global_vars/all.yml

touch ansible-vmware/vmware_create_infra.yml

Like we did with the variables file lets edit this file. Again, vi, nano, whatever.  Copy and past the information below.  Things to note.  Yaml files don’t like tabs.  So spaces only and position is very important.

- hosts: localhost
  connection: local
    - name: include vars
        dir: group_vars

    - name: Create Datacenter in vCenter
        module: vmware_datacenter
        datacenter_name: "{{ datacenter }}"
        hostname: "{{ vcenter_ip}}"
        username: "{{ vcenter_username}}"
        password: "{{ vcenter_password}}"
        validate_certs: False
        state: present

    - name: Create Cluster in datacenter
        module: vmware_cluster
        hostname: "{{ vcenter_ip}}"
        username: "{{ vcenter_username}}"
        password: "{{ vcenter_password}}"
        validate_certs: False
        state: present
        datacenter_name: "{{ datacenter }}"
        cluster_name: "{{ cluster }}"
        enable_ha: yes
        enable_drs: yes

    - name: Create Resource pool in cluster
        hostname: "{{ vcenter_ip }}"
        username: "{{ vcenter_username}}"
        password: "{{ vcenter_password}}"
        validate_certs: False
        state: present
        datacenter: "{{ datacenter }}"
        cluster: "{{ cluster }}"
        resource_pool: "{{ resource_pool }}"

Assuming you created the files correctly and have the right password we are ready to run our first Ansible playbook against vCenter.

ansible-playbook ansible-vmware/vmware_create_infra.yml --ask-vault-pass

This should produce something similar to below

PLAY [localhost] ***************************************************************************************************************************

TASK [Gathering Facts] *********************************************************************************************************************
ok: [localhost]

TASK [include vars] ************************************************************************************************************************
ok: [localhost]

TASK [Create Datacenter in vCenter] ********************************************************************************************************
changed: [localhost -> localhost]

TASK [Create Cluster in datacenter] ********************************************************************************************************
changed: [localhost -> localhost]

TASK [Create Resource pool in cluster] *****************************************************************************************************
changed: [localhost]

PLAY RECAP *********************************************************************************************************************************
localhost : ok=5 changed=3 unreachable=0 failed=0

The resulting output in the vSphere Client should look similar to below.

The cool part is we can run the same command again and again and nothing will change as long as our environment is consistent with our defined yaml files.  They in essence become our working as-built doco.

So the goal from what we’ve just done above was not to actually build an environment but rather to show you how quick and simple we can get Ansible up and running and configuring a vSphere environment.  I’ve avoided a lot of the technical stuff so instead you can think about how this might help you in your environment.

In future posts I might go into more details on specific modules and how to use them but for now I think I might just focus on what’s possible with Ansible and VMware.


Ansible VMware Getting Started

pyVmomi GitHub Page


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.


vCenter In VR (Is This VCSA 7?)

The last few months have been extremely fun for me.  I purchased a HTC Vive and have been enjoying every minute with it.  I’m not a huge gamer but I absolutely love the immersion factor.  I’ve lost count of the times I have got lost in games like Onward for hours on end.  The realism and social aspect of coordinating with your team mates on how to take the objective.  The absolute fear of crouching behind a wall while the enemy next to you discusses where you are.  An experience that’s hard to convey.

Games aside though, VR also has the ability to mirror your desktop and applications too.  Nothing like Minority Report or that awesomely realistic movie Hackers.  But think more a VR room with a computer screen in front of you that you can enlarge or shrink to suit your view.

So that got me thinking.  There are a few different VR apps that let you mirror your desktop in VR.  I decided to try out Bigscreen, mainly because it’s free!  And hell, because this is a virtualization blog, I obviously had to try out the vSphere Client to see if I could practically manage my vCenter Homelab environment.

It took a few attempts to find the best viewing mode and way to manage vCenter with the vSphere Client.  I first tried the large projector view on the wall in the VR room.  This turned out to be an absolute joke.  Imagine the worst, lowest, quality projector, and then try reading small text from the other side of a room.  Then think of something worse.  Okay… it wasn’t that bad but still.

Failing to use vCenter in the large projector mode view

The best mode I found was literally just sitting down in a chair.  Switching to the floating screen mode and enlarging the screen to encompass my field of view.  Then placing a small curve to the screen to rap a little around me.

omething’s red in my vCenter environment

I first tried managing vCenter with the HTC Vive controllers.  The controllers basically act as laser pointers.  You can pull up a virtual keyboard and laser zap the keys with the controllers as well as move the laser point around on the screen like a mouse cursor.  Using projector mode this was okay but up close it was really awkward.  Ultimately using the physical mouse and keyboard was most practical.  And it was practical.  As long as you can position your hands in the right spot and touch type there was no issues.  You just have to adjust to what feels like a 100 inch screen in your face.

Bigscreen has what they call Mutliplayer rooms.  This is where you can join and create a new room where people can share you screen experience.  I did jump into some of these rooms where movies were playing and had a little chat to the other guests.  I wasn’t game enough to create a room and share my vCenter screen though.  I just felt that the VR community wouldn’t have the same appreciation for my vSphere Homelab environment 😛

umping into someones VR cinema room

You can imagine how this multi-user room experience could be interesting though.  Inviting a friend / service desk into your private VR room to help you out on an issue in your environment.  Actually being able to point on the screen and talk through resolving an issue.  Waving your hands in frustration when the service desk can’t fix your issue.  It reminds me of the book Ready Player One.  A dystopian future where lives are lived out in a VR world and virtual chat rooms.

So alright, all of this was a big gimmick.  An excuse to talk about my HTC Vive and somehow justify it on my virtualization blog with vCenter.  It was fun, though, I’m not holding my breath for vCenter 7 VR.  But maybe a fling 🙂


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.


Configure the vSphere Web Client Timeout Value

vSphere Update Manager 5.x to 5.5 Upgrade

A few days back I upgrade a vCenter Server Appliance from 5.0 to 5.5.  With that prerequisite out the way I can now upgrade vSphere Update Manager (VUM) from 5.0 to 5.5.  This will bring me one step closer to being able to use VUM to upgrade my ESXi hosts to 5.5.

The process is very simple and just a matter of a few clicks.  VUM still requires that it runs on a Windows Server, VMware having yet provided an appliance alternative --yet.  So you will have to download the entire vSphere vCenter 5.5 Windows installation from VMware.

The process for a fresh install of VUM is similar to an upgrade.  As I’m upgrading I’ll be running through the process I used. The first step is executing the installer.


Select vSphere Update Manager and Click Install


Click OK


If you have a previous version of VUM installed you will be prompted to upgrade.


Click Next to start to installation wizard.


Accept the license agreement.


A few things have changed in the latest version of VUM.  Take note of what will be removed.  Make sure the checkbox to download updates after installation is selected.


Enter in your vCenter details.  Port 80 is the default unless you have changed this during vCenter installation.  Enter in a user account and password that has admin rights into vCenter.  If you’re running a vCenter Server Appliance like me you can use the root account.


If you haven’t already upgraded your vCenter to 5.5 you will receive the following warning and will need to upgrade vCenter before you can continue any further.


If you’re upgrading you won’t be able to change any database DSN or driver details.  Click Next.


Select ‘Yes, I want to upgrade my Update Manager Database’.  Select the checkbox ‘I have taken a backup of the existing Update Manager database’.


If your windows server’s IP address is resolvable its name will be listed in the drop down list.  Select the server and leave the default ports unless you wish to change them.  If you need to go through a proxy to access the internet select the checkbox below else click Next


Click Install to start the installation.


Update manager will need to be shutdown to upgrade it.  Select ‘Automatically close and attempt to restart applications’.


Once the installation is complete open up the vCenter 5.5 C# client.  Select plugins on the menu bar.  Scroll down to Available Plug-ins and click Download and Install on VMware vSphere Update Manager.


So that’s it.  Maybe a little more than a few click though 😉

You can now access Update Manager as you normally would in the vCenter Client.

vCenter Server Appliance 5.0 to 5.5 upgrade

VMware has recently released their latest version of vSphere 5.5.  This includes a new version of the vCenter Server Appliance.  If you’re still running vCenter Appliance 5.0 now is a great time to upgrade to the recently released VSA 5.5.  With a switch from the embedded IBM DB2 to PostgresSQL the vCenter Server Appliance 5.5 now scales out far greater than before.

Earlier on in the year I wrote up a post on Why I don’t virtualize vCenter.   I still like my physical vCenter.  Slowly VMware are knocking down those barriers.  With the latest version of VSA 5.5 they’ve removed the scalability issue for all but the largest deployments.  Things like Update Manage and SRM are the few remaining obstacles to a VSA only environment.

Upgrading your VSA from a previous version is a simple and quick process.  There are only a couple things that you really need to take into account before starting the process.  Make sure you take a snapshot of your current VSA 5.x and a backup of any external DB you may be using.  Don’t attempt to change the hostname of the VSA during the installation.   Finally, and really less of a concern, if using custom SSL certificates make sure you met VSA requirements for signed certs.

Download the latest vCenter Service Appliance 5.5 OVF file from VMware.  In vCenter import the OVF into your datacenter and Power On the VM.

Using a web browser connect to the Admin Management Portal of both Appliances on Port 5480 in two separate windows.  e.g. https://vCenter_ip_address:5480

When you browse to the admin management portal on the new 5.5 appliance for the first you will be presented with a Setup wizard.  Accepted the end user license agreement and click Next.


Select the second option, ‘Upgrade from previous version‘, and click Next.


The Setup wizard will skip a bunch of steps and present you with a key.  Click click on it and select copy.


Now change browser tabs and navigate to the original 5.0 appliance.  Click the Appliance Upgrade tab.


Select Source as the appliance role and click Set Role.  You should receive the message, ‘Operation was successful’.


Click on Establish Trust and in the Remote appliance key field paste in the key you copied from the New (Remote) appliance and click Import remote key.


Copy the key from the old 5.0 appliance (Source).


Navigate back to the new (remote) application and paste in the key you just copied and click Next.

If you attempted to set or change the hostname of the new 5.5 appliance you will receive a warning prompt.  To save you a world of pain after the install it’s honestly best to cancel at this point and not set a hostname during the OVF import process.  Trust me!


If you are using self-signed certificated you will most likely receive a prompt with certificate issues.  Click Replace the SSL certificate and click Next.


The Setup wizard will now jump back up a few steps.  Set an SSO password for [email protected] and click Next.


Confirm and select your hosts.


The Pre-Upgrade Checker now runs, hopefully with no errors and you can click Next.


As a final precaution before the upgrade you are required to confirm that you have made a backup/snapshot of the source 5.5 vCenter Server Appliance --which of course you have and so you click Next.


The Upgrade process now begins.


The new 5.5 VSA will now reboot.


If you were running vCenter Appliance 5.0 you would have no doubt still been working with the C# client.  That’s still available and will need to be upgraded.  You will be prompted to perform this action if you connect with an old client.  After you upgrade and run the client a message states that all new features are only available via the vSphere Web Client.


You can access the new vSphere Web Client with a browser on port 9443.  e.g.  https://vCenter_ip_address:9443



Upgrading vCenter Server Appliance 5.0.x/5.1 to 5.5 (2058441)

vCenter Server 5.1 Inventory Service

Way back in October 2012 when I was upgrading a vCenter Server to 5.1 I wrote up a few Installation guides for the various services of vCenter.  In one of the guides, Installing vSphere 5.1 -- vCenter Inventory Server.  I joked about how I had little or no idea what the inventory service is.

Recently I was listening to a podcast with Justin King (@vCenterGuy) doing a Tech Deep Dive on vCenter Server 5.1.  In it he briefly discusses what the Inventory Service is.  He did an excellent job of filling in a lot of the missing gaps I had about what the Inventory Service does.

Below is the summary from Justin on the Inventory Service.

  • Used since vCenter 5.0.
  • Used by web clients only.
  • Cache for vCenter inventory
  • Used to offload read-only requests from the VPDX
  • Allows for better performance, more connections, to vCenter.
  • Enables use of Tags (only in web client).  Can lead to better organisational structure.
  • Inventory Service uses an XML xDB file to store data.

I can’t believe it’s taken this long to get some of these answers on the Inventory Service, but I’m glad I finally have them.  Full credit to Justin and his Tech Deep Dive on vCenter Server 5.1, well worth a watch.


#vBrownBag Follow-up vCenter 5.1 Technical Deep Dive with Justin King (@vCenterGuy)

Why I don’t virtualize vCenter

because I can…

Traditionally, historically, we use to keep our vCenter physical.  Nowadays it’s fairly well accepted, and there’s even VMware best practices, to virtualize vCenter, which is the direction I see most taking.  I almost feel dirty telling people I still choose not to virtualize vCenter.  I can feel my street cred dropping.  I feel that I’m losing a battle here and my times of running vCenter on separate physical hardware are coming to an end.

I choose to run my current vCenter on physical servers.  It has local RAID disks separate from a SAN.  A local SQL Server not reliant on a shared SQL server.  It also runs a local DNS accepting zone transfers from an internal DNS.  Physical servers generally tend to be way gruntier than a vCenter will usually need too.

This gives the vCenter real high independence from the rest of the infrastructure.  During infrastructure maintenance I can power down an entire ESXi datacenter farms and still have vCenter connectivity.  I can performance SAN maintenance with complete independence from vCenter storage and without fear that a datastore that could have been hosting a vCenter VM might be effected.

I’ve had a lot of great success using this method for vCenter.  Infrastructure maintenance windows seems to go much more smoothly when I have full vCenter connectivity.  The physical server actually turns out to be a good jump box during these periods as well.  I’ve even had unplanned outages that have been recovered from much quicker had I not had an independent vCenter.

In normal operation running vCenter virtualized isn’t an issue.  It just works, right!  There’s little tricks you do, of course, to make life easier for yourself though.  You usually disable DRS on the vCenter VM to make it easier to identify which ESXi host it’s running on.  You put a High restart priority on the VM itself to cater for HA situations.

In my eyes though, that’s just thinking small events.  We’re not foreseeing how we’ll manage the VMware infrastructure during large scale failures.  We’re running vCenter on the same SAN storage as our production VMs.  A SAN failure of some sort can instantly affect our vCenter and ability to manage our Vmware environment.  I’m sure many of us install the vCenter DB onto a shared SQL server too.  What happens when that SQL server goes through maintenance, has an outage, or is just under high load?  vCenter becomes effected immediately.

Perhaps I’m placing way too much importance on vCenter?  Maybe I’m just stubborn and old school?  I really don’t know.  The latest version of the vSphere 5.1 virtual appliance is really good.  So good that I’m considering moving away from the Windows version permanently.  I have a feeling this is going to start leading me down the virtualized vCenter path forever.