One of the announcements at VMworld this week is the upcoming release of vSphere 6.0 Update 1 (GA sometime in Q3 2015) and in addition to bug fixes there are also several new enhancements that have been added. Here are some of the new capabilities specifically for the vCenter Server Appliance (VCSA).

  • New Deployment Targets - The VCSA now supports both vCenter Server (brownfield) as well as ESXi (greenfield) as a deployment targets.When using either the Guided UI or Scripted UI, you can now deploy to an existing vCenter Server which might serve as a management cluster for example. Previously, ESXi was the only supported deployment target.
  • Convert Embedded VCSA to External PSC - An Embedded VCSA deployment can now be re-configured or re-pointed to an External PSC using the new "reconfigure" and "repoint" option found in the /bin/cmsso-util utility. This allows customers to quickly get started using the simple Embedded VCSA deployment and as they get more comfortable and want to scale out to an External PSC for features like Enhanced Linked Mode, you can easily do so.

Screen Shot 2015-08-16 at 7.50.50 AM
Two of the most frequently asked questions that I have seen from customers since the release of the VCSA 6.0 is where did the VMware Appliance Management Interface (VAMI) and URL-based patching go? These were definitely two missed features that did not make it into VCSA 6.0 release and today I am pleased to announce that they have returned with some nice enhancements!

vcsa-60u1-whatsnew-8

  • VAMI UI - The VAMI UI can be accessed in the familiar 5480 port by visiting the following URL of the VCSA: https://[VCSA]:5480 and requires a local OS account to login like the root user account. The VAMI itself has been completely re-written both on the backend as well as the frontend which is now an HTML5 interface. All VAMI functionality can be accessed both from the UI as well as using the appliancesh command-line interface.

vcsa-60u1-whatsnew-4

  • URL-based patching - URL-based patching is also included in the new VAMI UI interface. By default it is configured to point back to VMware's online repository but you can also configure it to use an ISO or a custom repository as previous versions supported. All patching capabilities are also available using the appliancesh command-line interface.

vcsa-60u1-whatsnew-7

  • PSC UI - In addition to new VAMI UI, there also now a new Platform Services Controller (PSC) UI which is also written in HTML5. The new UI is located at the following URL: https://[VCSA]/psc and requires an SSO Administrator account to login. This new UI actually uses the same backend as the PSC configurations found within the vSphere Web Client. The idea behind this UI is to provide customers with a way to configure SSO and other related configurations within the PSC for either a greenfield setup or when the vSphere Web Client is unavailable. This can come in handy for troubleshooting purposes. Lastly, with the new PSC UI, you will now be able to replace certificates from a UI standpoint where as previously this was only available in the CLI.

vcsa-60u1-whatsnew-5

  • Build-2-Build upgrade support - In prior releases, both a "Major" and "U" (Update) release of the VCSA meant that you had to deploy the new VCSA to perform a migration based upgrade. In vSphere 6.0 Update 1, "U" releases (U1, U2, etc) can now be accomplished by an in-place upgrade or sometimes refer to as a build-2-build. There will be a VCSA 6.0 Update 1 ISO which can be mounted within your existing VCSA 6.0 appliance to perform the upgrade as seen in the screenshot below.

patching

  • appliancesh automation - The appliancesh interface in the VCSA 6.0 was primarily targeted for interactive usage and did not support any type of Automation. The feedback from customers was to provide a way to be able to call into the various appliancesh commands and in VCSA 6.0 Update 1, you can now execute a series of appliancesh commands within a file and re-directing that into an SSH session. VMware is also looking into providing a proper API for the appliancesh commands, if you have any feedback on this please leave a comment or reach out to Alan Renouf, who is the PM.

vcsa-60u1-whatsnew-6
Below is the contents of the vcsa-commands.txt file which contains the following appliancesh commands to configure and enable NTP for the VCSA:

Lastly, though this is not specific to the VCSA, I thought it was also worth mentioning that you can now access ALL capabilities of vSphere Update Manager (VUM) within the vSphere Web Client. VUM will still require a separate Windows system, but will fully inter-operate with both the Windows VC as well as the VCSA and you no longer need to rely on the vSphere C# Client to perform remediation or base-line creation and assignments.

vcsa-60u1-whatsnew-1
As you can see, there are a ton of enhancements in the latest vSphere 6.0 Update 1 release and if you have not taken vSphere 6.0 for a spin yet, I definitely recommend starting with this release.

31 thoughts on “What's New in vSphere 6.0 Update 1 for VCSA?

  1. With the ability to convert from embedded PSC to external PSC, does this mean we can migrate a 5.5 VCSA with embedded SSO to 6.0 VCSA embedded PSC and then move to external? Right now the process to do that is pretty convoluted.

    • Hi Matt,

      That’s correct. Once you’ve upgraded to from VCSA 5.5 to 6.0 U1 (Embedded), you’ll then be able to use the new cmsso-util option to go from Embedded to External deployment.

    • Will we be able to move a Vcenter once installed now to a different sso on another psc to be able to do enhanced link mode after the fact?

  2. Great news about v6U1 – hopefully the Embedded PSC to External PSC conversion also applies to a Windows VC with Embedded PSC installation, and not just VCSA?

    Also, with the upgrade of our environment from vCenter Server 5.5 U1 to v6, we hit a terrible known issue by VMware (KB2110943) with a truely horrendous workaround, which forced us to rollback the upgrade, causing further issue. Anyway, I hope this bug can be resolved in next release of vCenter Server

    Thanks

    • Hi Darren, can I ask you more details about the issue you hit during the upgrade? Why did you have to roll it back? How did you roll it back (revert snapshots?) ? Thanks.

      • Hi Matteo.

        During the upgrade of vCenter Server 6 (Build 2800571) (on a Windows Server running vCenter 5.5U1 with SSO, and remote DB), when prompted for the SSO credentials, there is an error about SSL certificates not being compatible between VC and SSO.

        We do not use any custom certificates in our environment.

        The error is exactly as per VMware KB2110943, but the workaround of uninstalling the entire vCenter Server 5.5 solution, then reinstalling it again, then Disconnecting and Reconnecting every ESXi host in the vCenter in order to refresh the certificates is not feasible.

        We had taken snapshots of VC server and DB server immediately before upgrade, so tried the workaround, but since vCloud Director creates hundreds of Resource Pools and hundreds of VM folders for our vApps, when trying to reconnect hosts, it asks to remove all existing resource pools, and dump all VMs into root of host, also not feasible.

        At this point we decided to rollback to our snapshots. Even getting environment back after the revert was challenging, and required a VMware Support Request at 4am. In the end, after 20 hours, we only managed to upgrade VC to 5.5 U2, but are still very keen to get onto v6.

        We tested this entire upgrade on a cloned Lab environment without issue.

        *sigh*

        Any input to help us get to v6 would be appreciated

        Thanks
        Darren

        • Many thanks for your feedback Darren, this is quite worrying to me!! I’m planning to upgrade to vCenter 6 (from 5.5 U2) soon but the process is still quite problematic!

          Also in my case, a complete re-installation and re-connection of all the hosts is not feasible because I’m using distributed switches. I’m wondering if I can predict this somehow, but your experience does not encourage me 🙁

          Hope to have some news about that KB soon.

          Matteo

          • You can safely test if you will be affected by this KB, by running the VC 6 installer. As soon as you enter the SSO administrator@vsphere.local credentials, it runs a precheck, if you get that error then you have same problem as we did. If the installer moves onto the next screen about list of Port numbers, then your SSL certs are compatible.

            We did this on our other smaller vCenter site also running VC 5.5 U1, and it ran through the prechecker fine, but we still stopped the upgrade anyway, as we wanted to upgrade both sites to v6. It was just our Primary VC that failed.

          • So, how did you run into the “rollback” scenario if there is a pre-check to avoid this?

          • When we got the error on screen during the VC6 install, and found the VMware KB with the suggested workaround, we started the workaround process of uninstalling VC 5.5 and reinstalling 5.5, but then when started reconnecting our first host (of many), and saw that it wanted to just drop all guest VMs into root of host (~100VMs per host x 40 hosts), and not into original VM folders and Resource Pools, we decided to rollback, and restore snapshot pre-v6 installation.

            In hindsight, knowing what we know now following our VMware Support Request that 4am, and further testing in our Lab and our other vCenter Server site – it appears that AS LONG AS USING EXISTING VC DB – reconnecting hosts back in the VC in fact does NOT place all VMs in root of hosts, but DOES retain VM folder and Resource Pool location. JUST DO NOT REMOVE ANY HOST FROM VC, only Disconnect/Reconnect.

            I suggest you test in a Lab environment first

            Hope that helps – good luck

          • I too am still confused why you had to rollback. You said you got the error on the precheck but started the work around process? Why not just cancel the upgrade at that point and regroup?

          • we found out these things the hard way unfortunately, ie. we proceeded with the workaround, ie, uninstall/reinstall of VC 5.5, then checked vCenter at that point, before we proceeded to v6, but all hosts greyed out. Started reconnection, but saw the statement about putting all VMs into root resource pool, so tried remove host, but that broke things further. So at this point we reverted (around 2am) – having already done the complete reinstall of VC, plus had broken hosts, and were no closer to v6 than before we started, so thought rollback to snapshot would be straight forward. Having said that, the re-installation of VC generated new thumbprints on all the hosts, so we were stuck even after the revert, where all hosts were grey. We tried reconnecting one. Seemed ok. But the one we removed was messy. But this is when we called VMware support for assistance (around 4am). In the end a simple disconnect/reconnect WAS the way to get them back into VC safely.

            So knowing what we know now, we are more confident to to give it another go, and disconnect/reconnect hosts without losing resource pools etc once we can schedule another maint window – having said that, I still think the fact that this is a known issue by VMware, and the suggested workaround is really not a pretty one with all this reinstallation malarky, I hope this can rather be prevented/avoided some other way/patch/hotfix….

  3. Great news about Update Manager being fully manageable within Web Client, but it’s still forbidden in my environment until the MSXML 4 dependency has been removed (KB 2113837).

  4. Update 1 (get it?): I posted after reading this post and before watching your keynote. I’m ok as to the requirement; but was it too hard to connect to a host (that’s part of a vC) and deploy VCSA on it?

    • In vSphere 6.0, to deploy the VCSA, you would use either the new Guided UI or Scripted CLI method which does consume the OVA. Instead of having to go down the OVA route, users would be provided with an abstraction to make deployment easier.

      In the first release, the only “official” deployment target was directly to an ESXi host and this was a challenge for some customers, especially for those who may not have direct ESXi access due to security concerns. Another more common scenario is that many customers also run multiple versions of vSphere, so being able to deploy to an existing VC environment or one with a management cluster had always been possible prior. This was something that we definitely wanted to get in and now we have both options and no longer does a customer have to manually mess around with the OVA. Hope that clears things up

  5. Any idea how to get that port 5480 enabled ??
    I just upgraded to VCSA 6.0 U1 but that mentioned port I do not have that at all.
    i’m interested in the VCSA auto update

  6. Hi There. I am installed VCSA 6.0.0, build 3018523. I am having diffculties finding the latest version to patch to. Does anyone konw what is the latest version and how to obtain the patch as I downloaded VMware-VCSA-all-6.0.0-3040890 but when I mount it as an ISO, the staging fails as it complains that not an ISO patch.

  7. Another nice article, thanks William!
    I’m wondering if I will ever see VUM integrated in the VCSA or at list as a separate Linux appliance, it is one of those feature that VMware continue to postpone… do you have any news about it?

  8. Are there any enhancements in the update for the Mac environment? I wonder if you might have an answer to this issue; when we extend our storage size from say 25G to 30G Disk Utility does not allow the extended expansion; the only way so far is to perform a full backup migrate to another disk of 30G and then delete the 25G…

  9. I have two vCenters, both 6.0.0 build 3634794. One was updated probably from 6 or 6u1, the other is a fresh 6u2. The first does not have a VAMI UI at :5480, even after a reboot, the second has it working. Any ideas? Any shell command to force it to run/enable?

Thanks for the comment!