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 6.5 Product Interoperability – brain fade moment!

So it’s probably worth reminding everyone that there are still VMware products that are not yet supported on vSphere 6.5!

I unfortunately found out the hard way when I broke my work’s demo environment (or at least half of it).

Now even though I’ve blogged about compatibility issues previously eating too many mince pies and drinking too much bucks fizz over the Christmas and New Year festivities has obviously taken its toll on my grey matter, and coming back to work in the new year I decided it would be a nice idea to upgrade a part of my works demo environment to vSphere 6.5 so that we can use it to demo to customers!

The problem was I upgraded the part of the lab running NSX and when I got to the point of trying to push the NSX VIBs onto the ESXi hosts (when preparing the hosts to join the NSX cluster), it was having none of it and failing! After several unsuccessful attempts, it slowly dawned on me that NSX was one of those ‘unsupported’ products that doesn’t work with vSphere 6.5…..

Damn…..

Fortunately I didn’t destroy my old vCenter Server 6.0u2 appliance so was able to roll back by re-installing the ESXi hosts with 6.0.

 

Anyways, the products still not supported are:

  • VMware NSX
  • VMware Integrated OpenStack
  • vCloud Director for Service Providers
  • vRealize Infrastructure Navigator
  • Horizon Air Hybrid-Mode
  • vCloud Networking and Security
  • vRealize Hyperic
  • vRealize Networking Insight

 

Definitely worth keeping an eye on this VMware KB: Important information before upgrading to vSphere 6.5 (2147548)

And if you do end up upgrading to vSphere 6.5, then make sure you follow the recommended upgrade sequence in this VMware KB: Update sequence for vSphere 6.5 and its compatible VMware products (2147289)

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

Modifying VMware Site Recovery Manager – Windows 2012 UAC error

I first came across this issue when helping a customer uninstall Site Recovery Manager last year and wanted to blog about it but because I was pretty busy it totally slipped my mind….. until today!! I’ve been cleaning up the Solution Centre at MTI and tried to uninstall SRM for a new build…. and came across the same Windows User Access Control error. =)

srm02

Turns out that in Windows 2012. even when you go into User Accounts to turn off the UAC, it doesn’t disable it.

srm01

There’s a Microsoft Technet article which explains how to edit the Windows Registry in order deactivate UAC.

  1. Go to Start > Run, type regedit and click OK. The Registry Editor window opens.
  2. Navigate to HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > Windows > CurrentVersion > policies > system.
  3. Right-click EnableLUA and select Modify.
  4. In the Edit DWORD window, change the Value data from 1 to 0.
  5. Restart the Windows machine and re-run the SRM uninstall program.

srm03

VMware NSX 6.2.4 released

So after the huge cock-up with 6.2.3, VMware have turned around a new version of NSX in a matter of weeks to fix all the bugs!

http://blogs.vmware.com/kb/2016/08/vmware-nsx-vsphere-6-2-4-now-available.html

Of major concern was the whole HA issue that meant DLR nodes got stuck in a ‘split-brain’ mode after 24 days of operations – and every 24 days after that! It also didn’t help that the previous version was causing VMs to lose network connectivity if the pMAC of the DLR was the MAC address in the default gateway.

Anyways, hopefully all the bugs have been ironed out and the new release is more stable!

Release Notes can be found here.

For some of my customers, the release of 6.2.4 brings back the vShield Endpoint management support which is great given vCNS and vShield Manager is going end of general support on the 19th Sept!

For more info about this, read my previous blog entry: NSX 6.2.3 Released – support for vShield Endpoint Management

Installing vShield Endpoint (vCNS Mgr 5.5.4-3)

Very quick blog entry as I’m busy tying up loose ends before jetting off on my summer hols….

It’s pretty easy to install vShield Endpoint as it’s a wizard-based OVA deployment. I’m not going to step through the process as it’s very simple (plus the install guide explains it very well). Once that’s done log into the console and run ‘setup’ to configure the IP address and DNS information.

After that, it’s a case of logging into vShield Manager and connecting to vCenter Server.

Once connected to the vCenter, you should see your datacenter and hosts in a hierarchical tree on the left menu. Select each host and installed vShield Endpoint.

vShield Installation guide: http://www.vmware.com/pdf/vshield_55_install.pdf

However, I did encounter a few issues (due to prior deployments which hadn’t been cleaned up properly).

Error 1: VMKernel Portgroup present on incorrect vSwitchvcns1
This occurred because the hosts had a previous vSwitch labelled vmservice-vswitch, but the VMkernel port vmservice-vmknic-pg resided on a different vSwitch (previous deployment). To correct this I had to delete the old VMkernel port and recreate it on the correct vmservice-vswitch.

Error 2: VirtualMachine Portgroup present on incorrect vSwitch

vcns2Again this was due to a mis-configuration on a previous deployment! What should happen is once you’ve setup the vmservice-vswitch and created the vmservice-vmknic-pg portgroup and VMkernel port, the installer will create a new portgroup on that vSwitch called vmservice-vshield-pg. Like before, this was residing on the wrong vSwitch.

In the end I just deleted the wrong vSwitch and started again by creating the vmservice-vswitch and the vmservice-vmknic-pg. After that the installation of vShield Endpoint went swimmingly!

vcns3

Which goes to show that cleaning up an old deployment within your demo environment can sometimes be very handy! =)