Category: Uncategorised

vCenter “FLUP-grade” Part II: Upgrade vCSA 5.5 to 6.0 on VMware Workstation

The second part of my FLUP-grade was to use the tool for vCenter Server Appliance 5.5 to upgrade to 6.0! The issues for me were:

– I use VMware Workstation for a nested lab using AutoLabs.
– The tool relies on your vCSA being hosted on an ESXi Server.
– There are only a few blogs for deploying vCSA 6 on Workstation, that I found.

I’d love to have a proper lab with real equipment, but sadly that is not the case at this moment in time; one day perhaps! Given that my home machine is only so fast, I don’t like to run many nested VM’s on my already virtualized ESXi servers as things become a bit slow. On the the Workstation Layer I have:

– A Domain Controller & VUM Server
– 2-3 Virtual ESXi hosts
– vCSA 5.5
– Openfiler + FreeNas storage VM’s
– A Router

In the ESXi layer, I run small lightweight VM’s mainly for testing features and deployments.

Here is how I upgraded:

1) I downloaded and installed the latest vCSA v6 .ISO file from VMware and mounted it. From within that ISO, I installed the VMware Client Integration Plugin 6.0.0
CAP3

 

 

 

 

 

 

 

 

 

 

2) Next, I shutdown my existing 5.5 vCSA and exported it as an .OVA.

3) Whilst this was happening, I increased the Memory on my ESXi hosts to 12GB each and powered them on. I then used the vSphere client to connect to the hosts directly and imported the vCSA to my first host. I checked the networking of the VM and powered it on.
CAP12

 

 

 

 

 

 

 

 

4) After checking services, I disabled DRS temporarily because I didn’t want any VM’s to be moved. I then went back to the .ISO of vCSA 6 and opened the vcsa-setup.html file.
CAP4

 

 

 

 

 

 

 

5) At this stage, my browser (chrome) opened but I needed to enable the plugin that I had installed previously.
CAP5

 

6) Once the plugin was sorted, I selected Upgrade from the menu.
CAP6

 

 

 

 

 

 

 

7) Checked the warning prompt and confirmed that I was on 5.5 and therefore supported. I also fully read and accepted the EULA.
CAP7

 

 

 

 

 

 


CAP8

 

 

 

 

 

 

 

 

 

8) Next I entered in the information of the host that I wanted to deploy the new vCSA 6 appliance on.
HOST2CAP

 

9) After accepting the SSL certificate warning, I was able to select my lab information for deployment.CAP15

 

10) Another SSL and environment check,  a warning about Postgres username/ password and SSH port requirement.
CAP16

 

 

 

 

 

 

 

 

11) I then chose the smallest deployment type for obvious reasons. At this stage, if I hadn’t increased my hosts memory I wouldn’t have been able to proceed as a warning appears stating insufficient memory. The destination host must have more than 8GB for the VM to live! CAP17

 

12) Chose which storage the VM should temporarily live on.
CAP19

 

13) I then assigned a static IP address for the vCSA 6 to take on my network. As stated in the text, it’s only temporary and when the whole operation is complete the new vCSA assumes the identity of the existing vCSA!
CAP20

 

14) Reviewed the summary and took a screenshot for your pleasure, before commencing with the big “Finish” button.CAP21

 

15) The process took a while and goes through several stages; extracting/installing packages, migrating data, starting services, etc.
CAP22  CAP24

 

16) Migration was complete, so I logged into my vCSA as if nothing had changed. Yep! All good!
CAP25

 

17) At this stage, it was time to shut down my new vCSA6 and then run an export back out of the nested virtual layer. (At this stage I felt like Cobb from Inception, only better looking!;))
CAP26

 

 

 

 

 

18) Getting close, I imported the vCSA6 .ovf file back into VMware Workstation.
CAP27

 

 

 

 

 

 

 

 

 

 

 

 

19) One final check of the network (my main hosts subnet) and I booted it up and crossed my fingers!
CAP28

 

 

 

 

 

 

 

 

 

 

 

 

It worked! It might not be the prettiest/recommended/sane method and is only for my home lab scenario, but I really wanted to upgrade from 5.5 to 6.0 vCSA using proper methods in case this is ever needed in Production (and it will be!).

So that ends the chapter of my vCenter FLUP-grade. A bit of a strange journey, but I got there in the end!

vCenter “FLUP-grade” Part I: Migrate vCenter Server 5.5 to vCenter Server Appliance

What happens when you Fling and then Upgrade? My best guess is a FLUP-grade!

A while ago I thought of making changes to my virtual home lab. I have become slowly frustrated with the amount of “stuff” and “things” running on my Windows 2008 R2 vCenter Server; to the point where the thought of booting it up, makes me yawn! It’s not useful for getting quick answers or to test something, which is most of the time!!

I saw the VCS to VCVA converter fling being pimped out a while back by the genius that is William Lam and thought that I’d really like to give it a go! It would enable me to remove my old vCenter Server, have a cleaner estate and let me get stuck in with the vCenter Appliance!

Here is the FLing part of my UPgrade. The aim is to publish Part II which will then move my environment forward to VCSA 6! I followed the documentation provided with the converter fling, which was excellent! I’m not going to post the entire process as you can download instructions that are in .docx format, but I’ll post the interesting bits.

Requirements:
– vSphere 5.5 – Check!
– VCS and VCSA same version – Check!
– Same hardware on both – Check!
– All VCS components on same host – Check!
– External  MS SQL 2008 R2 Database – Partial Check:- I’m running SQL Express DB and it’s not supported. But I’ll give it a go anyway (It’s only a simple lab!)
– Web Client Plugins registered with AD User – Check!
– Comms on 22, 443 and 445 enabled – Check!
– All Admin/DB credentials ready – Check!

1) After following the guide; stopping services, deploying/configuring the converter, building and snappnig an empty vCSA, I entered in my existing vCenter Server  local admin credentials:
CAP6

 

 

 

 

 

 

 

 

 

 

2) The migration appliance then collects what it needs from the existing VCS:
CAP7

 

 

 

 

 

 

 

 

 

 

3)  When prompted, I powered down my VCS, powered up my new VCSA and continued with the install, accepting the prompts for SSL key and entered the root password for my VCSA and entering in DNS information.

4) Then I proceed to login to the VAMI Interface (http://VCSAHOST:5480) and setup the embedded database & SSO.  Once that was all complete, I came back to the migration tool and entered in my AD details as I had joined my appliance to a domain.CAP24

 

 

 

 

 

 

 

 

 

 

5) I then had to wait for a while with files copying from the migration tool. Then, I was presented with the SQL database login credentials. The first time I attempted the DB migration, I selected “Migrate stats/events/tasks”.
CAP30

 

 

 

 

 

 

 

 

 

 

6)  This didn’t go so well, and the installation hung:
CAP27

 

 

 

 

 

 

 

 

 

 

7) After using  “Alt+F2” to get to the console, I took a look in /var/log/migrate.log and found this:CAP28

 

 

 

 

 

 

 

 

 

 

8) It seems that choosing to migrate the stats/events/tasks might not have been a good one for a simple home lab migration! (167,943 rows! Ooops!). This process took a LONG time and after watching it thrash my poor little 1 vCPU for ages, I got bored and left it overnight and went to bed 🙂CAP29

 

 

 

 

 

 

 

 

 

 

9) I came down the next morning and the process had got stuck, so I started again and at Step 5 chose NOT to migrate that information!
CAP31

 

 

 

 

 

 

 

 

 

 

That was it! I logged into the VAMI and all was well. I followed the final steps of the guide; re-enabling plugins, etc and then gave the new VCSA a reboot for good measure!

All in all, I was very impressed with this tool, it is a superb effort from the engineers involved. The next part of the plan was to upgrade from 5.5 to 6.0!

vCenter 5.5 – Host migration and version upgrade

I’ve seen a few posts in the VMware Communities recently asking about host migrations, rebuilds and re-installations of vCenter. I’ve answered a few of them as best I can with stock answers that could relate to any environment. I thought that this might be an interesting blog for future users to refer to. I decided to run through this in my lab with the following prerequisites:

  • vCenter Host migration (2008 R2 to 2012 R2)
  • Maintain the same SQL database (SQL 2008)
  • Upgrade vCenter from 5.5 (U1c) to 5.5 (U2d)
  • Do not backup maintain existing configurations E.G:- SSL Certificates, SSO Configuration, Inventory Service, Plugins, etc.

This guide could also be used to migrate an existing install of 5.5 to another host on the same O/S, I’m just choosing to upgrade my O/S and vCenter at the same time!

Key points to consider:

  • Be aware of your environment (Login Credentials, DNS, IP’s).
  • Take a backup of the existing SQL Database and ODBC connection information.
  • Do you want to back up your SSO configuration and Inventory Service?
    Backup vCenter DB Blog
    VMware KB on SSO Backup
  • Build new host and re-create ODBC connection.
  • Shutdown old server (causes a vCenter outage whilst you re-install).
  • Install latest vCenter version using the existing DB.
  • Complete install and check components.
  • Reconfigure any components and test.

 

The Process:

1) Firstly I checked that my vCenter server was working as intended with no issues. I made sure I knew my: administrator@vsphere.local password, SQL ODBC connection details and my host/IP information.

Cap1

Logged in and everything is working as expected. Check!

cap3

Found my ODBC details and recorded them.

cap4

Checked I knew the password and can connect to the DB.

cap2

My host name and IP details recorded.

2) Next I took a backup of my vCenter Database, just in case!

cap6

3) I then rebuilt a brand new 2012 R2 server, patched it and configured it exactly how I wanted it.

cap7

4) I then shut down my old vCenter Server (VC).

5) I configured my new vCenter Server (VC2012) with the same IP address of my old one, for simplicity, and ensured that DNS records were all correct.

cap8

6) I then re-installed the SQL Server Native Client on my new server and reconfigured my ODBC connection to my SQL DB Server and tested it.

CAP21

CAP22

7) At this stage, I inserted the vCenter 5.5 U2 media into the server and began the installation process, ensuring all of the following components were installed as per a usual install (I’ve not included all screenies here as they can be found and depend on your environment).

CAP23

8) The key part in this entire process was when installing vCenter Server. Selecting existing DB and choosing to upgrade.

cap13

This is the ODBC as selected in step 6.

CAP15

Upgrade the DB as we are moving from 5.5 U1 to 5.5 U2 in this process!

CAP16

Ensure that vCenter automatically upgrades the latest host agent.

9) At this point let the installation process complete and ensure you have also got the latest vSphere client. Do a check of all services to make sure they are started and everything is running as expected.

CAP20

10) Finally log in and check your vCenter is working as intended with the latest version!

CAP17

To conclude:

Migrating/upgrading/re-installing  vCenter is really not difficult. In this example I migrated to  a new host and also did an upgrade at the same time. This was a slightly more straightforward example as I was not maintaining certain configurations which might add a little extra complexity. From this point on, you can consider other things such as updating your VUM Server and upgrading your ESXi hosts to the latest version too!

The most important thing to take home is that the database is key!

VMware SSL Certificate Automation Tool: “Cannot determine if Inventory Service is registered with Single Sign-On”

An issue I have encountered recently that I thought I would share, is an error when using a combination of the brilliant SSL Toolkit by @DerekSeamen and the VMware SSL Certificate Automation Tool.

All certificates had been generated absolutely perfectly by Derek’s toolkit. After proceeding with the SSL Certificate Automation Toolkit, the SSO certificate update appeared to work without an issue. However, when the Inventory service came to be updated, the error that appeared was as follows:

SSLError
Troubleshooting steps included:

1)      Checking all certificates to ensure no errors.

2)      Tested log in credentials for administrator account.

3)      Re-generating certificates and retrying.

4)      Digging out the scripts from the Automation tool and running them manually.

At this stage during the troubleshooting, I noticed that at the command prompt we were seeing errors and a partial password being entered into the batch file as it was running.

It transpired that the problem was because of our SSO administrator@vsphere.local password!! It seems that having a password that contains the “ = “ character is not great for using the VMware SSL Automation Tool as it parses your password into the batch scripts which then misinterpret the character and throw an error.  I checked the documentation on the Deploying the SSL Certificate Automation tool KB and there is no mention in the known issues section about using “=” for the admin password.  This KB Article from VMware states that there are characters that mustn’t be used with SSO admin password and equals (=) is not one of them!

After changing the SSO password and re-implementing the certificates, everything worked as expected!

This problem occurred because during the vCenter install, a random password generator for the SSO password. It is not in the unsupported list of characters so the installation proceeded as normal.