So the first part of my article has appeared on SearchVMware.com….. enjoy! =)
Not sure when part 2 will be released… =)
So the first part of my article has appeared on SearchVMware.com….. enjoy! =)
Not sure when part 2 will be released… =)
So post VMworld, I wrote a long article about what’s new for vSphere 6.5 which I was hoping would be published on SearchVMware.com…. unfortunately I’m still waiting on it to be published, last I heard the article was too long and they were splitting it up into two articles! ¬_¬”
Anyways, whilst I wait for the article to be published, I’ll give a quick summary of things I’ve learnt about the new vSphere/vCenter 6.5 that was released 2 days ago.
To find out more information, head along to the following:
In addition to the GA of vSphere/vCenter 6.5 there were a load of other releases on the same day:
I’m still waiting on the launch of vRealize Automation 7.2 and NSX 6.3….. those should be imminent as well!
As always, all downloads are available via the My VMware Portal.
Last year I blogged about the vCS to vCSA converter tool that VMware Labs released as a fling and how I had used it to pretty much convert all my lab vCenters (all bar one) to vCSAs….. since then I’ve been following the releases and a few months ago I noticed the Fling was deprecated (ie you can’t download it). I didn’t think much of it as VMworld 2016 was only round the corner, so thought it might be rolled into an impending vSphere/vCenter release….. unfortunately that never quite materialised in Las Vegas, and rumours are that vSphere 6.5 might be released in Barcelona.
So I was quietly surprised when I got an email notification from VMware Blogs to inform me that a new minor update of vSphere had been released specifically for migration puposes – vSphere 6.0 Update 2m (where the ‘m’ stands for migration).
vSphere 6.0 Update 2m is an automated end to end migration tool from a Windows vCenter Server 5.5 (any update) to a vCenter Server Appliance 6.0 Update 2 (so pretty much what the Fling used to achieve).
It’s common knowledge that trying to migrate from a Windows vCenter Server (with a SQL backend) to a vCenter Server Appliance was not an easy task – in fact in 90% of my customers I’ve just told them to start a fresh rather than go through the pain of scripting a migration. However, I’m so glad that VMware have rolled out the Converter fling into an actual production release – now we have an end-to-end migration tool which takes all the pain out of the equation!
Those of you who are interested in migrating from your Windows vCenter Server 5.5 (any update) to a vCenter Server Appliance 6.0 Update 2 should download and use this release. The vSphere 6.0 Update 2m download is an ISO consisting of the Migration Tool and vCenter Server Appliance 6.0 Update 2, roughly about 2.8GB in size.
Note: you cannot use this release to deploy a new installation of vCSA! To do that you just use the vCSA 6.0 Update 2 install.
Somethings that are worth mentioning prior to starting a migration are:
The only annoying thing is that because I’ve used the fling previously to convert all my Windows vCenter Servers, I now don’t have anything I can test this migration tool on!! >_<”
I’m currently in the process of digging out an old vCenter Server 5.5 ISO so that I can deploy it and upgrade it using the new release!
Anyways, those of you who haven’t yet upgraded to vCenter Server 6.0 and to an appliance, now there’s no reason why you can’t as you have a fully supported tool from VMware!
Best of all, they’re in the process of improving the migration tool so that it can be used to migrate from a Windows vCenter Server 6.0 install to a vCenter Server Appliance 6.0. One feature I hope they will also include is the ability to migrate from an existing vCSA to another vCSA.
vCenter Server 6.0 Update 2m links:
One of the plus points with upgrading your vCenter Server Appliance to 6.0 update 1 is the fact that VMware have re-introduced the Virtual Appliance Management Interface (VAMI). This was one of my bug-bears with 6.0… how any sort of administration/configuration work required you to access the vCSA shell!
Recently after upgrading a customers vCSA from 6.0 to 6.0 update 1, we couldn’t access the VAMI to change the network and password policy settings. We rebooted the vCSA several times but still the VAMI was inaccessible, within Chrome we were getting the following error:
I couldn’t work out why the VAMI services wasn’t coming online….. After several minutes of searching on Google, I came across the following VMware KB:
It turns out that there is a known bug with the VAMI web-service if you disable IPv6 within the vCSA console (which is what I had done as there was no requirement from the customer to use IPv6).
There is currently no resolution to this bug, and in order to solve the issue you have to edit the lighttpd configuration file.
(lighttpd is a light-weight open-source web server)
So now that VMware have released their latest updates, I thought it would be a good time to upgrade my demo environment. Whilst I’ve carried out numerous upgrades/patches on previous releases of the vCSA, I’ve not yet carried one out for the vCSA 6.0.
BTW, I’ve previously documented my vCSA upgrades, so pop along to these posts if you want more info:
Upgrading vCenter Server Appliance to 5.5
Upgrading to vCenter Server 5.5.0a
Installing/Upgrading vCenter Server Appliance 6.0
One of the first things you will notice with the vCSA 6.0 is the lack of the Virtual Appliance Management Interface (VAMI) page – all configuration is now carried out via the Web Client! (Although this has been re-introduced with update 1, see further down this post).
For previous versions of the vCSA there were 2 upgrade/update processes:
In order to update or patch the vCSA 6.0 you will need to use the appliancesh command-line interface. There is a command called ‘software-packages’ which is used to update/patch the software on the VCSA.
One of the new features with vSphere 6.0 Update 1 is the ability to do an in-place update for major releases – accomplished by mounting the update ISO to your existing vCSA and performing the upgrade using the ‘software-packages’ command. This is a handy new feature that reduces the need to copy data between your old and new appliance which occurs with the migration update – obviously helping to reduce the overall downtime!
(Note: a vCSA 5.x to vCSA 6.0U1 upgrade still requires the migration approach as the vCSA has been re-architected!).
Another new feature is the reintroduction of the VAMI page (https:// <vCSA_FQDN> :5480), and the best thing about it is that VMware have now completely re-written it using HTML5…. Yay! =)
TBH, most of the features available on the VAMI page can be accessed by using the appliancesh CLI.
As part of the re-introduction of the VAMI page, you will be able to update the vCSA directly from the Update tab and configure it to point to VMware’s online repository to pull down the latest patch/update.
Anyways, I digress….. here are the instructions on how you go about upgrading the vCSA 6.0 to 6.0 update 1 (Remember, take a backup or snapshot your vCSA prior to upgrading!)
The whole upgrade process took me about 15mins to complete….. it’s quite a pain-free process (assuming you don’t run into any issues). =)
A couple of days ago, the clever bods at VMware Labs released a new fling that allows you to migrate from a Windows-based vCenter Server to the vCenter Server Appliance: https://labs.vmware.com/flings/vcs-to-vcva-converter
This is a great Fling idea as a lot of end-users are now considering the vCSA given the enhancements made to it in 5.5! (BTW, vCSA has been further enhanced in vSphere 6.0!!!)
Check out my previous blog article on the subject……
Anyways, one of the problems in the past was how would a customer go about migrating data from their old Windows-based vCenter Server onto the new Linux-based vCenter Server Appliance!
Previously I’ve had to ensure that the customer was aware that moving to the appliance means they can’t migrate over their vCenter Server data – and the majority of the time they’re happy to bite the bullet and do a fresh install!
Having used the Fling to migrate my lab vCenter Server to the appliance, I can say that it works pretty well! The Fling migrates the vCenter database, roles, permissions, privileges, certificates and inventory service… It even migrates events/tasks lists, folders, vApp settings and pretty much anything that’s stored in the VCDB! The only thing it didn’t do was migrate the SSO configurations which has to be setup manually (pretty simple to re-do).
There are some limitations though (this is not the full list):
TBH, the one thing the documentation doesn’t mention is whether it migrates Distributed vSwitches, and having played around and used the Fling, I’m happy to say that it looks like it does as I could view and manage the dvSwitch on the vCSA after migration (although if I’m honest I haven’t delved into all the nitty-gritty configs you can do with a dVS).
I found the process pretty simple to follow, deploy a vCSA, ensure it is configured with the same IP and hostname as the old vCenter Server, fire up the migration appliance and follow the wizard!
The only issue I encountered was when trying to configure the Active Directory settings during the vCSA configuration wizard and I got the following error:
Failed to execute '/usr/sbin/vpxd_servicecfg 'ad' 'write' CENSORED 'xxxxxxx.com'': VC_CFG_RESULT=302 (Error: Enabling Active Directory failed.)
This was easily rectified by changing the hostname of the vCSA to the FQDN and checking the DNS entry is correct as outlined in this VMware KB: http://kb.vmware.com/kb/2062610
Once this was sorted, the migration was quite pain-free……. this is one great Fling, and I hope they continue to work on it and enhance it!! Well done VMware engineers!!
So it slipped my mind that the root/admin passwords for the vCenter Server Appliance expires after 90 days by default….. and when I tried to access the admin webpage today in my demo environment so that I could update the appliance, I couldn’t log in…… dammit…..!
Surprisingly this must be a really common issue with customers using vCSA as VMware have written a KB to step through the process of *cough* breaking into *cough* your vCSA in order to reset the root password.
The only drawback is you need to enter the GRUB password which should be the last password set for root. If you’ve forgotten this then you’re in for a world of pain! =)
Recently had to regenerate the SSL certificates on my vCenter Server Appliance as I had noticed they were originally created with
localhost.localdom as the DNS name.
Quite easy to regenerate the SSL certs, just log onto the admin page of the vCSA (
http://ip-address:5480) and log in as root. Click on the Admin tab and by Certificate regeneration enabled select Yes.
When you next reboot the vCSA, the SSL certs will be regenerated – just be sure to change it back to No after it’s complete otherwise it will regenerate a new certificate every time you reboot!
A problem I discovered after regenerating the SSL certificate of my vCSA was that I could no longer connect to Site Recovery Manager using vSphere Client.
It would try to connect and then fail with a Connection Error.
As I knew this was working prior to regenerating the SSL certificate, I guessed that SRM was still trying to authenticate with the vCenter Server using the old SSL certificate.
The SRM logs show a certificate error:
Failed to connect: std::exception 'class Vmacore::Ssl::SSLVerifyException' "SSL Exception: Verification parameters:
The remote host certificate has these problems:
Quickest way I could think of in order to solve my issue was to modify the installation of SRM to update the certificates.
Log into the SRM server, open up Programs and Features from the Windows Control Panel. Select the entry for VMware vCenter Site Recovery Manager and click Change.
At the SRM wizard, select Modify.
You won’t be able to change the vCenter Server details but you will be able to change the authentication method. Regenerate the certificate by selecting Automatically generate certificate.
Ensure you select Use existing database, otherwise you will lose all your protection groups and recovery plans.
Once the SRM installer was finished, I was able to reconnect to SRM using vSphere client.