vSphere 5.5

Will I get Photon OS when I upgrade my VCSA 5.5/6.0 to VCSA 6.5?

11/04/2016 by William Lam 7 Comments

There seems to be a bit of confusion on how the upgrade from an existing vCenter Server Appliance (VCSA) 5.5/6.0 to the upcoming VCSA 6.5 release will work. I suspect part of the confusion is also due to the fact that the underlying OS in the VCSA in vSphere 6.5 is changing from SLES to VMware's very own Photon OS. Before going into the upgrade details, I do want to mention that with this change, VMware will now own the entire software stack within the VCSA (OS + Application). This will allow VMware to quickly respond and deliver OS and security updates to customers at a much quicker rate than it was possible before. In addition, Photon OS is also a very optimized Linux distribution which has allowed VMware to significantly improve the reboot and startup time of the vCenter Server application. To be clear, the vCenter Server application itself is NOT running as a Docker Container nor are there any other application or services within the VCSA that is running a Docker Container, I know this was something folks were also assuming because the OS changed to Photon OS.

Now going back to the upgrade question, how would an upgrade work if the underlying OS is changing? The answer is actually quite simple. VCSA upgrades are "Migration" based upgrades and has been since the very first release of the VCSA in vSphere 5.0.

So how does it work? Here is the high level workflow:

The new VCSA 6.5 is deployed using the standard VCSA UI or CLI installer using the "Upgrade" option. It does require a temporarily IP Address (DHCP or Static)
The VCSA 6.5 then connects to the existing VCSA 5.5/6.0 and starts copying (migrate) the data from the old VCS to the new VCSA
The existing VCSA 5.5/6.0 is then shutdown, the new VCSA 6.5 now takes over the personality of the original VCSA and you have now successfully upgraded

As you can see from this workflow, your existing VCSA is not actually being upgraded but rather its data is migrated over to the new VCSA. Once the upgrade has completed, you will now be on the new Photon OS based VCSA. Hopefully this clears up any confusion 🙂

Lastly, I should also mention that in vSphere 6.5, we have an updated version of the VCSA Migration Tool simliar to the one release with vSphere 6.0 Update 2m. It will now support migrating from a Windows-based vCenter Server running either vSphere 5.5 or vSphere 6.0 to VCSA 6.5.

vCenter Server Appliance (VCSA) Migration Tool officially GAs w/vSphere 6.0 Update 2m

09/15/2016 by William Lam 45 Comments

Today, I am very happy to announce that we have released the official Windows vCenter Server to vCenter Server Appliance (VCSA) Migration Tool which is part of the new VCSA vSphere 6.0 Update 2m release! I know many of you have been asking for an update since we released the VCS to VCSA Convert Appliance Fling a little over a year ago. The Fling was pretty limited in functionality and this was by design so that we could quickly get something out to our customers and get some early feedback. Although I could not say anything, the VMware Engineering team have been very hard at work incorporating all of the feedback in how they designed and built the official VCSA Migration Tool that you see today.

With that, I would like to extend a huge thanks to all of our customers who took part in the Fling and provided feedback both in the comments section as well as reaching out to me through the various channels. It was great to engage with literally hundreds of customers of all sizes and segments, all looking to move away from a Windows-based vCenter Server to the VCSA. Lastly, I want to thank our VMware Engineering team, both to the folks who lead the initial effort on the Fling prototype to those who then productized it! I was very fortunate to have been part of this amazing milestone at VMware.

The VCSA Migration Tool workflow is quite different from how the Fling had worked which hopefully customers will appreciate. The team worked really hard on trying to simplify the overall user experience as well as trying to minimize the overall amount of downtime for the migration. In addition, we have also added full support for additional configurations and deployment topologies which you can find more details in the resource link below which includes an FAQ which I *highly* recommend folks have a look at before starting or asking further questions.

Collection of all #migrate2vcsa Links / Resources: vmwa.re/migrate2vcsalinks

Here is a quick video that I had recorded earlier which demonstrates a migration from a Windows vSphere 5.5 environment to VCSA 6.0 Update 2m, hopefully this will give you a nice overview of the migration process.

[UI Demo] - Migration of Windows vCenter Server 5.5 to vCenter Server Appliance 6.0 Update 2m from lamw on Vimeo.

One last thing I want to quickly mention is that this release is specifically targeted at customers looking to migrate from a Windows vCenter Server 5.5 to the VCSA 6.0 Update 2, hence the letter "m" denotation. If you are NOT looking to migrate your Windows vCenter Server to the VCSA, this release is NOT applicable to you as you will NOT be able to perform a new install and/or upgrade using this release. Instead, you should be looking at the vSphere 6.0 Update 2 release which is the exact same code base that vSphere 6.0 Update 2m is based off of. This will be even more apparent when you launch the VCSA Installer, as the "Migrate" button is the only option as shown in the screenshot below.

For those planning to attend VMworld this year, we do plan to have several sessions covering the new VCSA Migration Tool as well as some other surprises 🙂 I hope to see you there and if you have any comments or feedback, feel free to leave it here or use the #migrate2vcsa hashtag if you are on Twitter, especially if you are interested in some of the surprises at VMworld.

Quick Tip – How to disable the landing page for vCenter Server 5.x & 6.x?

07/25/2016 by William Lam 1 Comment

The question of wanting to disable the default landing page for the vCenter Server is one that comes up infrequently. In fact, I probably see this maybe once or twice a year. However, when it does come up, it usually revolves around two topics: some sort of security risk and limiting users from obtaining software provided through these landing pages. In both case, simply disabling these landing pages will not solve either of these perceived issues.

I generally find these landing pages quite useful as they provide links to software downloads such as our legacy vSphere C# Client, SDK documentation as well as links to other interfaces to vCenter Server like the vSphere Web Client login, the datastore browser or the vSphere MOB. All of this information can be obtained through other official channels, so simply disabling this page does not really prevent users from downloading this content or accessing these interfaces.

On the second topic around security (which by no means am I an expert in), some customers feel that simply removing these default landing pages would some how prevent a security risk because a version of the software is no longer listed on that page? This is what some folks would call security through obscurity which just does not work. There are many different ways of identifying a version of vCenter Server and some of its components as well checking if the service is running. Simply removing these pages does little to nothing from stopping someone from retrieving this information using other methods. Instead, users should really be focusing how they are implementing security both in the software as well as the policies and processes they have in place which hopefully are inline with modern security practices.

In fact, by disabling some of these pages, you might even be hurting your overall customer experience depending on their familiarity with vCenter Server.

In any case, for those that are still inclined to disable these pages, below are the instructions on how to disable the various landing pages as I have not really seen this documented anywhere. The solution is actually quite simple which is to just rename the index files to something else which will prevent them from being loaded by the webserver.

Landing page for vCenter Server 5.x

Windows VC: C:\ProgramData\VMware\VMware VirtualCenter\docRoot\index.html
VCSA: /etc/vmware-vpx/docRoot/index.html

Tomcat landing page for vCenter Server 5.x

Windows VC: C:\Program Files\VMware\Infrastructure\tomcat\webapps\ROOT\index.jsp
VCSA: /usr/lib/vmware-vpx/tomcat/webapps/tomcat/webapps/ROOT/index.jsp

Landing page for vCenter Server 6.x

Windows VC: C:\ProgramData\VMware\VMware VirtualCenter\docRoot\index.html
VCSA: /etc/vmware-vpx/docRoot/index.html

Landing page for Platform Services Controll (vSphere 6.x)

Windows VC: C:\ProgramData\VMware\vCenterServer\runtime\VMwareSTSService\webapps\websso\WEB-INF\views\index.jsp
VCSA: /usr/lib/vmware-sso/vmware-sts/webapps/websso/WEB-INF/views/index.jsp

Configuring VCSA 6.0 as vSphere Web Client Server for vSphere 5.5

04/22/2015 by William Lam 11 Comments

The vSphere 6.0 Web Client has been greatly improved with the release of vSphere 6.0 which includes a number of performance and UX enhancements. If you are interested in some of the details, be sure to check out this blog post by Dennis Lu, Product Manager of the vSphere Web Client. To really get the best possible user experience and to take advantage of all the new performance enhancements, it is recommend that you upgrade your entire vSphere environment which includes vCenter Server to vSphere 6.0. Having said that, I know this may not be possible for everyone immediately and it will take some time depending on your organizations software upgrade cycles and procedures, qualifications, burn in time, comfort left, etc. with vSphere 6.0 before completely moving over.

Over the last couple of weeks, I have seen quite a few requests from customers who have expressed interest in being able to just use the new vSphere 6.0 Web Client with their existing vSphere 5.5 environment as they make their transition over to vSphere 6.0. I can definitely understand where these customers are coming from and honestly, the vSphere Web Client should just be that, a UI Client. We should be able to decouple it from vCenter Server and be able to iterate on it based on feedback from our customers and partners. I did some investigation and I actually discovered that we in fact support something called Mixed-Version Transitional Environment in vCenter Server for Windows Upgrade. This is a bit of a mouth full but basically you can have a hybrid vCenter Server environment that consists of both vSphere 5.5 and 6.0 as you upgrade to full a full vSphere 6.0 environment.

I spent a couple of days researching this topic a bit more to see if I can come up with a solution that would ideally reduce number of changes introduced to a customers existing vSphere 5.5 environment while being able to leverage the new vSphere 6.0 Web Client. After many discussions, prototyping, snapshot reverts and with the help of one of my good GSS buddy G. Blair Fritz, we have come up with a very cool solution using the VCSA 6.0 as a "thin" vSphere 6.0 Web Client Server. The overall goal is to provide a period of time in which customers can use the new vSphere 6.0 Web Client with their existing vSphere 5.5 environment and when the time comes for a complete vSphere 6.0 upgrade, this "thin" vSphere 6.0 Web Client can be decommissioned and removed.

Disclaimer: Though this hybrid configuration is supported, using the VCSA as a "thin" vSphere Web Client Server is not officially supported. Please use at your own risk. It is still recommended that you upgrade your existing vSphere 5.5 environment to vSphere 6.0 as soon as possible to get the full benefits of the enhancements made to the vSphere 6.0 Web Client.

Requirements:

vSphere 5.5 running Windows using an External SSO Server
At least one vCenter Server 5.5 pointing to the External SSO Server

Here is the high level workflow as well as a diagram to help you visualize the process:

Step 1 - Upgrade your external SSO from vSphere 5.5 to new PSC 6.0
Step 2 - Deploy VCSA 6.0 and configure it to point the newly upgraded PSC 6.0
Step 3 - Running a configuration script within the VCSA 6.0 to optimize it as a "thin" vSphere Web Client Server

In my test environment, I have deployed a vCenter Server 5.5 which points to an external SSO (also running vSphere 5.5).

Step 1 - The first step is to upgrade the SSO server to the new PSC 6.0, you will follow the existing procedure by mounting the ISO and going through the guided installation. At this point, you can continue logging into the existing vSphere 5.5 Web Client and access your vCenter Server and its hosts and VMs.

Step 2 - Next, you will need to deploy a new Embedded VCSA 6.0 using either the Guided or Scripted Installation. You will need to make sure that it is joining to an existing SSO Domain by specifying the upgraded Windows PSC that you performed in step one. The SSO Domain Name should be vsphere.local as this was not a configurable option in earlier vSphere releases. At this point, you can now login to the VCSA 6.0 which provides the vSphere 6.0 Web Client but you will notice that you only see an empty inventory of the new vCenter Server 6.0 as well as an error message stating "Login failed due to invalid credentials for one or more vCenter Server systems"

The reason for this is that you need to restart the vpxd service on your vCenter Server 5.5 for it to be visible in the new vSphere 6.0 Web Client.

Note: It is important that if your external PSC is joined to an Active Directory Domain that you ensure the NTP Server specified in the VCSA 6.0 deployment also points to the same AD Server for the time source to be synchronized else you will run into problems later.

Step 3 - Login to your vCenter Server 5.5 and restart the vCenter Server service using the Services utility.

Step 4 - Once the vCenter Server service has restarted, you can now open a browser to the Hostname/IP Address of the VCSA 6.0 and you will see both vCenter Servers. You can now manage your vSphere 5.5 environment using the vSphere 6.0 Web Client.

I was pretty happy when I got this solution working but I was still not content. The smallest deployment size for an Embedded VCSA requires 8GB of memory, which is still a considerable amount of resources in my opinion. I wanted to optimize it further by turning off unnecessary services, modify the memory requirements for the unused services as well as un-registering the vCenter Server 6.0 endpoint so that you only see your vSphere 5.5 vCenter Servers only. Surprisingly, this took up the bulk of our research to figure out what could be turned off, how to properly turn it off and then un-registering the VC endpoint.

I have created the following shell script called setup_vcsa_as_webclient_client.sh which needs to be uploaded to the VCSA (need to enable Bash shell on the VCSA). The following three variables must be updated prior to running:

PSC_SERVER - The Hostname/IP Address of your external PSC
SSO_USERNAME - The SSO Administrator account
SSO_PASSWORD - The SSO Administrator password

Once everything completes successfully, you should turn off your VCSA and modify the memory from 8GB to 3GB. From my limited amount of testing, the overall memory utilization was sitting around ~2-2.5GB of memory, so I think configuring it to 3GB should be plenty and you can always adjust accordingly. Since we have disabled all the unnecessary services, the VCSA boot time should be pretty quick and now when you login to the vSphere Web Client, you should only see your vSphere 5.5 vCenter Servers and nothing else.

When the time comes and you are ready to fully upgrade your vSphere 5.5 environment to vSphere 6.0, you can decommission and remove this "thin" vSphere Web Client Server by following the procedure outlined in this VMware KB 2106736. I think it would be really nice to be able to update the vSphere Web Client outside of updating vCenter Server and truly providing a "client" that is decoupled. What do you think?

Quick Tip – vCenter Server advanced settings for vSphere 5.5 & 6.0

04/01/2015 by William Lam 2 Comments

This was a question that was recently asked in an internal thread regarding the list of available advanced settings in vCenter Server. You can find these settings under the "Advanced Settings" section of all places 😉 and this is available both in the vSphere Web/C# Client.

I wrote a script awhile back that allows you to modify these advanced settings and with a slight modification to the existing script, I was able to produce the complete list of available settings (available via the vSphere API) that are user configurable, as not all settings are configurable. Below, is a table of all vCenter Server 5.5 advanced settings and I also have a table for newly added advanced settings for vCenter Server 6.0.

Disclaimer: Most of these settings should be left at their default and if you do need to make a change, make it is through a recommendation by either VMware's documentation or from GSS Support as modifying some of these changes can negatively impact your environment.

vCenter Server 5.5

Setting	Description
ads.checkInterval	User validation interval
ads.checkIntervalEnabled	Enable user validation
ads.maxFetch	Maximum users to retrieve
ads.maxFetchEnabled	Enable user retrieve limits
ads.timeout	User retrieve timeout
AgentUpgrade.autoUpgradeAgents	vCenter Agent Upgrade
AgentUpgrade.checkPeriodSeconds	Host upgrade check frequency
alarms.upgraded	Default alarms have been created
alarms.version	Default alarm upgrade version
client.timeout.long	Long operation client timeout
client.timeout.normal	Client timeout
DBProc.Log.Buffer	DB procedures log buffer
DBProc.Log.Level.Stats.Purge1	Log level for daily stats purge
DBProc.Log.Level.Stats.Purge2	Log level for weekly stats purge
DBProc.Log.Level.Stats.Purge3	Log level for monthly and yearly stats purge
DBProc.Log.Level.Stats.Rollup1	Log level for daily stats rollup
DBProc.Log.Level.Stats.Rollup2	Log level for weekly stats rollup
DBProc.Log.Level.Stats.Rollup3	Log level for monthly stats rollup
DBProc.Log.Level.Topn.Calc1	Log level for topn rank of daily stats
DBProc.Log.Level.Topn.Calc2	Log level for topn rank of weekly stats
DBProc.Log.Level.Topn.Calc3	Log level for topn rank of monthly stats
DBProc.Log.Level.Topn.Calc4	Log level for topn rank of yearly stats
DBProc.Log.Level.Topn.Purge1	Log level for purge of daily topns
DBProc.Log.Level.Topn.Purge2	Log level for purge of weekly topns
DBProc.Log.Level.Topn.Purge3	Log level for purge of monthly topns
DBProc.Log.Level.Topn.Purge4	Log level for purge of yearly topns
event.maxAge	Maximum event age
event.maxAgeEnabled	Enable event cleanup
instance.id	Instance ID
LicenseServer.matchHostToVirtualCenter	Match host license server to vCenter
log.level	Logging level
mail.sender	Mail sender
mail.smtp.port	SMTP server port
mail.smtp.server	SMTP server
Perf.Stats.MaxCollectionThreads	Maximum statistics collection threads
snmp.receiver.1.community	First SNMP receiver community
snmp.receiver.1.enabled	Enable first SNMP receiver
snmp.receiver.1.name	First SNMP receiver name
snmp.receiver.1.port	First SNMP receiver port
snmp.receiver.2.community	Second SNMP receiver community
snmp.receiver.2.enabled	Enable second SNMP receiver
snmp.receiver.2.name	Second SNMP receiver name
snmp.receiver.2.port	Second SNMP receiver port
snmp.receiver.3.community	Third SNMP receiver community
snmp.receiver.3.enabled	Enable third SNMP receiver
snmp.receiver.3.name	Third SNMP receiver name
snmp.receiver.3.port	Third SNMP receiver port
snmp.receiver.4.community	Fourth SNMP receiver community
snmp.receiver.4.enabled	Enable fourth SNMP receiver
snmp.receiver.4.name	Fourth SNMP receiver name
snmp.receiver.4.port	Fourth SNMP receiver port
SSL.Version	SSL version
task.maxAge	Maximum task age
task.maxAgeEnabled	Enable event cleanup
TOPN_LOGING_MODE	TopN calculations log level
TOPN_LOG_BUFFER	TopN calculations max log rows
TOPN_STATS_DELAY_MINS_1	TopN calculations daily delay
TOPN_STATS_DELAY_MINS_2	TopN calculations weekly delay
TOPN_STATS_DELAY_MINS_3	TopN calculations monthly delay
TOPN_STATS_DELAY_MINS_4	TopN calculations yearly delay
VirtualCenter.CacheSize	Cache size
VirtualCenter.DataCollector.Enabled	Enable customer experience improvement program data collection
VirtualCenter.DataCollector.Schedule	Customer experience improvement program data collection schedule
VirtualCenter.DBPassword	Database password
VirtualCenter.FQDN	vCenter FQDN
VirtualCenter.InstanceName	Instance name
VirtualCenter.LDAPAdminPrincipal	LDAP administrator principal
VirtualCenter.ManagedIP	vCenter management IP address
VirtualCenter.MaxDBConnection	Maximum database connections
VirtualCenter.VimApiUrl	VIM API URL
VirtualCenter.VimPasswordExpirationInDays	Password expiration
VirtualCenter.VimWebServicesUrl	Web services URL
vpxd.httpClientIdleTimeout	Http Client Pool Idle Timeout
vpxd.license.ForceDownloadDLF	Force Download DLF
vpxd.locale	Server locale
vpxd.npivWwnGeneration.portWwnNumber	Generation port WWN number
vpxd.npivWwnGeneration.singleNodeWwn	Generation single node WWN
vpxd.usageStats.duration	Usage statistics duration
vpxd.usageStats.level	Usage statistics level
vpxd.usageStats.persist	Save usage statistics to the database
vpxd.vod.persist	Save usage statistics to a file
WebService.Ports.http	HTTP port number
WebService.Ports.https	HTTPS port number
wwn.instance.id	WWN instance

vCenter Server 6.0

Setting	Description
etc.issue	/etc/issue
etc.motd	/etc/motd
event.batchsize
mail.smtp.password
mail.smtp.username
task.batchsize
vpxd.cert.threshold	Certificate Management Threshold (in days)
vpxd.certmgmt.certs.cn.country	Country Name for the ESXi Host Certificates
vpxd.certmgmt.certs.cn.email	Email address for the ESXi Host Certificates
vpxd.certmgmt.certs.cn.localityName	Locality Name for ESXi Host Certificates
vpxd.certmgmt.certs.cn.organizationalUnitName	Organizational Unit Name for ESXi Host Certificates
vpxd.certmgmt.certs.cn.organizationName	Organization Name for ESXi Host Certificates
vpxd.certmgmt.certs.cn.state	State Name for ESXi Host Certificates
vpxd.certmgmt.certs.daysValid	ESXi Certificate Validity Period (in days)
vpxd.certmgmt.certs.hardThreshold	ESXi Certificate Management Hard Threshold (in days)
vpxd.certmgmt.certs.pollIntervalDays	ESXi Certificate Validity Check Interval (in days)
vpxd.certmgmt.certs.softThreshold	ESXi Certificate Management Soft Threshold (in days)
vpxd.certmgmt.mode	ESXi Certificate Management Mode

Long awaited Fling, Windows vCenter Server to VCSA Converter Appliance is finally here!

03/02/2015 by William Lam

Back in VMworld 2013, the Office of CTO held its annual Fling Contest where customers can submit their ideas for cool new Flings that they would like to see. If selected, not only would the individual get a free pass to VMworld but VMware Engineers would also build and release the Fling, how cool is that!? There were over 200+ submissions that year and I was very fortunate to have been on the panel to help select the winner. The winning Fling for that year was the Windows vCenter Server (VCS) to VCSA Converter Appliance by Stephen Athanas.

UPDATE 09/15/16 - The officially supported VCSA Migration Tool has has GA'ed with the release of vSphere 6.0 Update 2m. Please see this blog post here for more details.

The idea of a VCS to VCSA Converter really resonated with me as well as with many of our customers. In fact, everyone that I had spoken with who has used the VCSA just love the simplicity, ease of deployment and management it provides compared to its Windows counterpart. However, one of the biggest adoption barrier that I have seen from talking to customers is that is no simple way of migrating from a Windows based vCenter Server to the VCSA. You literally have to start fresh and this is pretty a show stopper for the majority of our customers and I do not disagree with them.

Customers want a migration path to be able to preserve all their vCenter Server configurations such as Folder structures, Permissions, Alarms, Tags, VM Storage Policies, etc. This is the idea behind the VCS to VCSA Converter Appliance which helps migrate a Windows vCenter Server running on an external Microsoft SQL Server Database to an embedded VCSA running a vPostgres Database. Today, I am very proud to announce the release of the VCS to VCSA Converter Appliance Fling.

The Converter Appliance migrates the vCenter database, Roles, Permissions, Privileges, Certificates, Alarms and Inventory Service which contains Tags and VM Storage Policies. At the end of the migration, you will end up with a fully functional VCSA with the original hostname/IP Address fully intact and ready to use. As you can imagine, this was no easy task and we had some of the smartest VMware Engineers working on this project. Todd Valentine from the OCTO managed the overall program with Ravi Soundararajan as the Chief Architect working closely with Mike Stunes, Jignesh Shah, Raju Angani. Being a huge advocate and supporter of the VCSA, I also had the unique opportunity to be involved in this project and working closely with some amazing engineers to help design, test and validate the migration appliance.

We hope you give the VCS to VCSA Converter Appliance a try in your lab (Please carefully read through the documentation along with the requirements and caveats before getting started). Let us know what you think by either leaving a comment here on my blog or on the Flings webpage. This is our first release and we already have some ideas of features and capabilities we would love to add to future releases but if there are things that you feel that are currently missing or enhancements you wold like to see, please let us know!

If you wish to provide private feedback about your environment or engage with us further, feel free to send an email to Todd Valentine at: tvalentine [at] vmware [dot] com