Goodbye vCenter Server for Windows and Flash-based vSphere web client!

Hmm…. it’s not even VMworld yet and VMware decide to make 2 big-ish announcements.

Although tbh, since vSphere 6.5 was released these 2 announcements have long been coming!

Finally, after loads of speculation, VMware had announced that vCenter Server for Windows and the Flash-based vSphere web client is to be deprecated with the launch of the next version of vSphere. Updates to 6.5 will continue supporting the 2 features, but come vSphere 7.0 it will be no more….

https://blogs.vmware.com/vsphere/2017/08/farewell-vcenter-server-windows.html

 

“vCSA-exclusive capabilities such as file-based backup and restore, unified update and patching, native vCenter High Availability, and a significant performance advantage mean that the VCSA has become the platform of choice for vCenter Server.  Additionally, due to the integrated nature of appliance packaging, VMware is able to both better optimize and innovate vCenter Server at an accelerated pace.  Finally, with the VCSA, VMware can provide support for the entire vCenter Server stack including the vCenter Server application, the underlying operating system (Photon OS), and the database (vPostgres). By doing so, VMware can ensure that customers can focus on what matters most while having a single source for updates, security patches, and support.  The VCSA model is simply a better model for vCenter Server deployment and lifecycle management.”

That pretty much sums up why VMware are 100% behind the vCSA, although they miss out the whole “screw you Microsoft licensing!!” part! Plus given that 6.5 ships with a migration tool that helps you move/upgrade from a Windows vCenter to an Appliance vCenter, it’s no surprised that more and more people are moving over when it comes round to upgrade time!

In fact ever since 6.5 was released, I’ve not even deployed a single Windows vCenter Server – all my customers have been moved over to the vCSA.

https://blogs.vmware.com/vsphere/2017/08/goodbye-vsphere-web-client.html

With regards to the vSphere Web Client, loads of people found the flash-based version was frustratingly difficult to use – it was slow, it was notoriously prone to crashing and frankly it was based on in-secure Flash technology (not to mention that Adobe themselves are dropping flash). HTML5 is the way to go baby!

So with those announcements in mind….. I may think about changing some of my VMworld sessions to jump on the vCSA and Web Client update sessions!!

 

RIP…..

Advertisements

vSphere/vCenter 6.5 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.

  • New HTML5 vSphere Client
  • Fully Integrated vSphere Update Manager and AutoDeploy with vCenter Server Appliance
  • Native High Availability for the vCSA
  • Native backup/restore for vCSA
  • Built-in monitoring web interface for the vCSA
  • Over 2x increase in scale and 3x in performance
  • Easy to migrate from Windows vCenter to vCSA
  • Client Integration Plugin for the vSphere Web Client is no longer required
  • The vCSA deployment installer can be run on Windows, Mac and Linux
  • The installer now supports install, upgrade, migrate and restore
  • vSphere API Explorer
  • VM Encryption / Encrypted vMotion
  • Secure Boot (for ESXi host and VM)
  • VMware Tools 10.1 and 10.0.12 (for older guest OSes that are out of support)
  • Multi-factor authentication with Smartcard or SecurID
  • VMFS-6 (4k drive support in 512e mode – emulating 512 sectors)
  • Automatic Space Reclamation – VAAI UNMAP now automatic and integrated it UI
  • VVOLs 2.0 plus VASA 3.0
  • vSphere HA is now known as vSphere Availability, enhancements to Admission Control
  • HA Orchestrated Restarts (adding in dependencies when HA restarts a VM)
  • Proactive HA (when host components are failing they are put into a quarantine mode)
  • Enhancements to DRS (VM distribution, CPU Over-commit, Network aware)
  • Predictive-DRS if vRealize Operations 6.4 is deployed (forecasted trends will kick off DRS)
  • vSphere Replication enhancements (now 5min RPOs like vSAN)

 

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.

vCenter Server Migration Tool: vSphere 6.0 Update 2m

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.

What’s Supported:

  • Previous versions of Windows vCenter Server will need to upgraded to vCenter Server 5.5 prior to migration.
  • The best thing is that all database types currently supported with vCenter Server 5.5 will be migrated to the embedded vPostgres database in the vCSA!
  • It’s worth noting that if VMware Update Manager is installed on the same server as the Windows vCenter Server 5.5, it will need to be moved to an external server prior to starting the migration process.
  • VMware and 3rd party extension registrations are migrated, but may need to be re-registered.
  • vCenter Server 5.5 both Simple and Custom deployment types are supported.
  • Configuration, inventory, and alarm data will be migrated automatically, historical and performance data (stats, tasks, events) is optional.
  • If the source was a Simple vCenter Server 5.5 install (so SSO + vCS) then it will be migrated to a vCSA with embedded PSC.
  • If the source was a Custom vCenter Server 5.5 install (so separate SSO and vCS) then it will be migrated to a vCSA with external PSC.

Somethings that are worth mentioning prior to starting a migration are:

  • It preserves the personality of the Windows vCenter Server which includes but not limited to IP Address, FQDN, UUID, Certificates, MoRef IDs.
  • Changing of your deployment topology during the migration process is not allowed. For example, if your vSphere 5.5 Windows vCenter was deployed using the Simple deployment option, then your Windows vCenter Server 5.5 will become an embedded vCenter Server Appliance 6.0.
  • During the migration process the source Windows vCenter Server will be shutdown, plan accordingly for downtime.
  • The migration tool will also be performing an upgrade, standard compatibility and interoperability checks will still apply. Please use the interoperability matrix to make sure all VMware solutions are compatible with vSphere 6.0. Also talk to your 3rd solution vendors to make sure those solutions are also compatible with vSphere 6.0.

 

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:

 

vCenter Server Appliance – filesystem out of space

So it’s all happening this week with this upgrade/clean up of the MTI solution centre!! =)

Upon finishing all the upgrades and reconfiguring vSphere Replication and Site Recovery Manager, I noticed the DR vCSA was a bit unresponsive…. taking ages to log into Web Client (sometimes it didn’t even get that far) – signing into the VAMI, I noticed that there was a critical error regarding the log file.

vcsa01

If you weren’t aware, one of the changes to vCSA with 6.0 was the deployment of 11 VMDKs with the appliance, one for each component service of vCenter. In previous versions there were only 2 virtual disks and this proved problematic when trying to increase disk capacity for particular components of vCenter Server (ie if you only wanted to increase the log directory).

As the vCSA was running in a demo environment, I decided to only do a ‘Tiny’ install – and it turns out that vCSA just ran out of capacity for logging – a quick jump onto the console proved this to be true:

vcsa02

The following VMware KB provides details into the 11 VMDKs and what mount points are attached to each vdisk: https://kb.vmware.com/kb/2126276.

vcsa04

I followed the instructions to increase the capacity of the log vdisk (VMDK5) and then gave the vCSA a reboot…..

vcsa03

The vCSA is now healthy and back to normal. =)

As a footnote, here’s a VMware KB that explains how to increase he maximum backup size and index of the vCSA to try and resolve he issue of the log directory fill up: https://kb.vmware.com/kb/2143565

Cannot connect to vCenter Server via vSphere Client – timeout

I’ve been upgrading my company’s solution centre to vSphere/vCenter 6.0 update 2 the past week and noticed that I was having issues logging into the vCenter Server Appliances I had deployed.

It was a strange issue because I could log into the Windows vCenter Server I had deployed in my primary cluster, but couldn’t log into the vCenter Server Appliance I had deployed in my secondary cluster….. hmmm…. Web Client worked fine for both, but it was the vSphere C# client that was timing out for the vCSA!

vc01.jpg

After much head scratching and trawlling through logs (Found at C:\Users\username\AppData\Local\VMware\vpx\viclient-x-0000.log), it turns out the problem is with the default time out value of the vSphere client for authentication.

The default timeout value is 30 seconds, and my suspicion is that the vCSA was taking slightly longer to respond to authentication…. changed the value to 60 seconds and it all worked fine!

Fire up vSphere Client and connect to another vCenter Server or ESXi host, then click Edit->Client Settings. Change the Client-Server Command Timeout value to Use a custom value and the Timeout in seconds to 60.

vc02

Here’s the VMware KB article about timeout values: https://kb.vmware.com/kb/2072539, there’s also instructions on how to edit the Windows registry if you can’t bring up vSphere client.

Just for the sake of it, here’s the error log:

[viclient:Error :P: 3] 2016-09-06 10:12:35.520 RMI Error Vmomi.SessionManager.Login - 4
<Error type="VirtualInfrastructure.Exceptions.RequestTimedOut">
 <Message>The request failed because the remote server 'xxxxx' took too long to respond. (The command has timed out as the remote server is taking too long to respond.)</Message>
 <InnerException type="System.Net.WebException">
 <Message>The command has timed out as the remote server is taking too long to respond.</Message>
 <Status>Timeout</Status>
 </InnerException>
 <Title>Connection Error</Title>
 <InvocationInfo type="VirtualInfrastructure.MethodInvocationInfoImpl">
 <StackTrace type="System.Diagnostics.StackTrace">
 <FrameCount>17</FrameCount>
 </StackTrace>
 <MethodName>Vmomi.SessionManager.Login</MethodName>
 <Target type="ManagedObject">SessionManager:SessionManager [xxxxx]</Target>
 <Args>
 <item></item>
 <item></item>
 <item></item>
 </Args>
 </InvocationInfo>
 <WebExceptionStatus>Timeout</WebExceptionStatus>
 <SocketError>Success</SocketError>
</Error>
[viclient:Critical:M: 6] 2016-09-06 10:12:35.531 Connection State[xxxxx]: Disconnected
[viclient:SoapMsg :M: 6] 2016-09-06 10:12:35.532 Attempting graceful shutdown of service ...
[viclient:SoapMsg :M: 6] 2016-09-06 10:12:35.534 Pending Invocation Count: 0
[viclient:SoapMsg :M: 6] 2016-09-06 10:12:35.535 Graceful shutdown of service: Success
[ :Error :M: 6] 2016-09-06 10:12:35.543 Error occured during login
VirtualInfrastructure.Exceptions.LoginError: The server 'xxxxx' took too long to respond. (The command has timed out as the remote server is taking too long to respond.)
 at VirtualInfrastructure.LoginMain.Process(BackgroundWorker worker, DoWorkEventArgs e)
 at VirtualInfrastructure.LoginWorkerImpl.Worker_DoWork(Object sender, DoWorkEventArgs e)
...
 at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)
 VirtualInfrastructure.Exceptions.RequestTimedOut: The request failed because the remote server 'xxxxx' took too long to respond. (The command has timed out as the remote server is taking too long to respond.)
 at VirtualInfrastructure.Soap.SoapServiceWrapper.DoInvokeSync(ManagedObject mo, MethodName methodName, Object[] parameters, Int32 timeoutSecs)
 at VirtualInfrastructure.Soap.SoapTransport.VirtualInfrastructure.Transport.InvokeMethod(ManagedObject mo, MethodName methodName, Object[] pars)
 at VirtualInfrastructure.ManagedObject.InvokeMethod(MethodName methodName, Object[] pars)
 at Vmomi.SessionManager.Login(String userName, String password, String locale)
 at VmomiSupport.VcServiceImpl.LoginNormally(LoginSpec loginSpec)
 at VmomiSupport.VcServiceImpl.Login(LoginSpec loginSpec)
 at VirtualInfrastructure.LoginMain.Process(BackgroundWorker worker, DoWorkEventArgs e)
 System.Net.WebException: The command has timed out as the remote server is taking too long to respond.

 --- End of inner exception stack trace ---

Known bug with upgrading vCSA via VAMI

So there’s a known bug where upgrading vCSA via the VAMI freezes at 70%…. I was doing a mass upgrade of all my vCSAs in the demo environment at work, and all of them got stuck at 70%.

vcsa

After reading the Release Notes for 6.0U1b, it turns out it’s a known issue: http://pubs.vmware.com/Release_Notes/en/vsphere/60/vsphere-vcenter-server-60u1b-release-notes.html

New In the vCenter Server Appliance Management Interface, the vCenter Server Appliance update status might be stuck at 70%
In the vCenter Server Appliance Management Interface, the vCenter Server Appliance update status might be stuck at 70%, although the update is successful in the back end. You can check the update status in the /var/log/vmware/applmgmt/software-packages.log file. After a successful update, a message similar to the following is seen in the log file:
Packages upgraded successfully, Reboot is required to complete the installation

Workaround: None.

Anyways, after checking the software-packages.log, I could see the packages upgraded successfully entry so just rebooted the vCSA. All up and working again!

vcsa2

If you want steps on how to upgrade your vCSA, then have a look at my previous blog entry: Upgrading vCenter Server Appliance to 6.0 update 1

vCenter Server Appliance & WinSCP

The other day I had to pull off the SSL certs for the vCSA and I was struggling to connect to the appliance even after enabling SSH and Bash shell access from within the VAMI.

Turns out a bit more configuration is required before you can connect to the vCSA via SCP and this is mainly due to the vCSA having 2 shells – Appliance shell and Bash shell.

What you need to do is change the default shell in the vCSA to Bash… have a look at the following KB for the solution steps: http://kb.vmware.com/kb/2107727

BTW, in case you didn’t know where the SSL cert for the vCSA resides, you’ll find it here:
/etc/vmware-vpx/ssl/rui.crt

Unable to connect to VAMI after upgrading the vCSA

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:

vami

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:
http://kb.vmware.com/kb/2132965

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)

To workaround this issue set the server.use-ipv6 parameter to disable in the /etc/applmgmt/appliance/lighttpd.conf.
  1. Connect to the vCenter Appliance or Platform Service Controller Appliance through SSH or console.
  2. Run this command to enable access the Bash shell:
    shell.set –enabled true
  3. Type shell and press Enter.
  4. Open the lighttpd.conf file using a text editor:
    vi/etc/applmgmt/appliance/lighttpd.conf
    vami1
  5. Search for the entry server.use-ipv6=”enable”
  6. Change enable to disable.
    server.use-ipv6=”disable”
    vami2
  7. Start the VAMI service by running this command:
    service vami-lighttp start
  8. You should now be able to access the VAMI from a browser (https://vCSA_IP_address:5480 or https://vCSA_FQDN:5480).

Upgrading vCenter Server Appliance to 6.0 update 1

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:

  1. In-place update – If it was a minor update or patch (so staying within a major release, eg. 5.5 -> 5.5a), then this could be deployed via the VAMI under the upgrade tab.
  2. Migration update – If it was a major update (so moving from one major release to another, eg. 5.1 -> 5.5), then you would deploy the new vCSA and migrate the data from your old one.

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!)

  1. If you have an external PSC, then the process is the same as upgrading the vCSA. However, upgrade your PSC first as that provides the authentication to your vCSA. Once the PSC has been upgraded, the vCSA can be next.
  2. Download the Upgrade ISO from the My VMware Portal. Select VC and 6.0.0 as the product. – the version of the ISO you want to download is the one labelled FP (Full Patch), rather than then one labelled TP (Third Party)
    vcsa1
  3. Mount the ISO to your vCSA using Web Client or vSphere Client (Don’t worry about the mounted ISO as during the installation process it will unmount the ISO after staging the install and before it shuts down the vCenter services).
  4. Log in to your vCSA either via SSH (using a program like Putty) or via the console from the client.
    Note: Be aware that if you log in via the client, you may lose connection when the installer stops the vCSA services (to continue re-log in via the client onto the host the vCSA resides on). You may have to enable SSH from within the vCSA DCUI:
    vcsa2
  5. Run the following command to stage and install the upgrade from the ISO:
    Software-packages install –iso –acceptEulas
    vcsa3
  6. Once the upgrade is completed, reboot the vCSA using the following command:
    Shutdown reboot –r “vCSA upgrade”
    (Note: In order to use the reboot command, a reason is required)
    vcsa4
  7. To check your vCSA has been upgraded, either open the console to the vCSA or access the new VAMI page using the root account:
    vcsa5 vcsa6

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). =)