With the release of vSphere 5.5 now upon us, before jumping in and performing a fresh install or an upgrade I wanted to highlight the minor changes to the vCenter Server installer, specifically when to use the simple installer and when to use the individual custom install wizards.
With the new release, when you attach your ISO image you will be presented with the updated splash screen
Simple Install
Selecting this option which is now the default will give you an installation of the core components required for vCenter server with the default settings on too a single physical or virtual server. With vSphere 5.5 we have now added the vSphere Web Client into the mix to assist with setting up vCenter Single Sign-On if necessary. Simple Install will install the following core components in the required order specified.
Using the simple install, the components will be installed to the default C:Program FilesVMwareInfrastructure destination folder or upgrade the existing version in the installed location. If you have distributed components with vSphere 5.1, this will install all components locally when ran, installing any components anew if not present which may affect you permission and accessibility (ie new vCenter Single SIgn-On instance)
Use case:
You will use the Simple Install option if you are installing or upgrading a single vCenter server with all of its components local to each other (VMware recommendation).
NOTE: If you are intending to install or upgrade multiple vCenter servers (ie for Linked Mode) then you can use the Simple Install for the first vCenter server to setup the vCenter Single Sign-On security domain and then use the custom installation options for the additional vCenter servers.
Custom Installation
The custom install provides the individual installer for each vCenter component which allows for additional options during install or upgrade. Each installer must be ran in the correct order (shown above) and allows for the following use cases
- Distribute components across multiple servers
(although supported, customers have shared that this does add complexity with management and availability options of vCenter server) - Install into a specific destination folder
(eg D:VMware) - Install more than one vCenter server(s) in too the same vCenter Single Sign-On security domain
(ie for Linked Mode as multiple vCenter Single Sign-On security domains (eg: vsphere.local) is not recommended)
As always please reference the VMware vSphere 5.5 Documentation Center for up to date documentation as well as the VMware Compatibility Guide and VMware Product Interoperability Matrixes prior to commencing any install or upgrade procedure.
Dominik
In case of an upgrade from 5.1, when I choose simple install, what happens to the existing SSO Database?
Justin King
the database will be migrated into SSO itself during the upgrade and once you have confirmed everything is working as expected you can remove the original SSO database
Davoud Teimouri
Thank you for this post. Is there same recommandation about vSphere 5.1?
Justin King
if moving to vSphere 5.1, VMware also recommends the above
Bjørn-Tore
Hi – Should we use Simple Install also when upgrading from 5.1 to 5.5, when 5.1 components are on different servers?
Justin King
if distributed and you are going to start over with SSO then yes otherwise you will need to upgrade SSO first with custom installer, then deploy an additional SSO local to vCenter pointing it to the separate one and complete installs updating SSO URL from installers to use local instance
Nicholas Gerasimatos
If all vCenter components are located on the same server, but in different directories (example D: or E:) when performing the simple upgrade will it upgrade the components in their current directory (example D: or E:) or remove and install everything to C:
Justin King
it will detect the installed components and upgrade where they currently reside, it will only select the c: drive if installing a missing component
Nicholas Gerasimatos
It seems simple installer is not able to be used for upgrades. At least, in the installation I completed yesterday this was the case.
Justin King
Nicholas, what did you experience as unexpected? would like to take any feedback back to engineering
Frank
Hi,
we are using vCenter Heartbeat and i am reading how to upgrade to 5.5
In the heartbeat documentation i read the following on page 53
“Before attempting to upgrade from vCenter Server 5.0 or vCenter Server 5.1 to vCenter Server 5.5 you must install the VMware vSphere Single Sign-On (SSO) 5.5 component separately on a different machine (not on the Primary or Secondary node) and then protect SSO on the separate machine with vCenter Server Heartbeat.”
We are using a physical and a virtual machine for heartbeat. How to update the Version without buying new Hardware? Why is it not possible to do a inplace upgrade?
I do not wan´t to begin to install a fresh vCenter Heartbeat Server. With a new Installation, it is possible to install all of the components on one Server.
Thanks
Frank
Justin King
we are researching an issue with HB protecting local SSO during an upgrade and will have a fix soon. There is a KB referenced in the release notes which documents a workaround.
Brett Gotthelf
We used Simple Install to create a 5.1 instance and have migrated our Test/Dev clusters from our original 5.0 vCenter Server. The simple install did not give an option for node type – so I can’t now join the 2nd (new) instance to the new 5.1 Server. We likely will also be standing up a DR site with a vCenter instance very soon, so multi-site & linked mode will be important. Does it make sense to upgrade the current 5.1 instance to 5.5? Will that absorb the current 5.1 SSO db and go to multi-site?
Mike
How do you migrate hosts to a clean install when they are using a vDS?
Thomas
I read some blogs about that scenario (google for it).
But in simple words…
1. install the new vcenter server
2. disconnect the esxi hosts from the old one.
3. connect it to the new vcenter server
4. export from the old vcenter the vDS configuration and import it to the new one.
if you connect the hosts after importing vDS, then vcenter would generate new id’s for those vDS and they won’t match the ones configured on the hosts (you have then to migrate the “old” portgroups of the VMs to the new ones manually).
If you connect it before, during the import of the vDS the match should be made by vcenter server and everything should be fine.
not tested it yes, but I’m going to make the same soon and hopefully it will work 🙂
Site & Server Administration
Dear Friend,
Nice collation,Nice post specially for newbies and also post something new.Useful Information.Friends,I have shear some information’s about the Site & Server Administration.Hopeful you like it this information’s.
Bjørn-Tore
With 5.5, what are user cases for when to install all vCenter components on a single VM or when should we distribute SSO, Inventory, Uptate Manager etc to different VMs ?
Bjørn-Tore
Hi – In the VMworld vCenter upgrade session you mentioned that steps for migrage SSO back from a distributed model to a single server was to:
1. Upgrade current external SSO to 5.5
2.On the local VM with vCenter, web and Inventory, install a new SSO server and let it replicate data form the external.
Should we chose option 2 on the installer here: (vCenter Single Sign-On for an additional vCenter Server in an existing site) ?
3. Upgrade other components on local VM and when upgrading vCenter, point it to local SSO server.
Please advice.
Bob
What do you mean, exactly, by “multiple vCenter Single Sign-On security domains (eg: vsphere.local) is not recommended)”
I have two geographically dispersed sites. We are planning a new 5.5 installation. What are our options? Can we install two completely separate SSO authentication domains, one at each site and manage them completely serately or should we set it up in a multi site sso configuration where there is one SSO domain stretched across sites? The comment that “multiple vCenter Single Sign-On security domains (eg: vsphere.local) is not recommended)” leads me to believe that you shouldn’t do the two isolated installs, but am a bit confused.
Thanks,
Bob
rtb1982
Justin,
I have a similar question about separate security domains. My understanding is that if you have two separate sites in say US and One in Europe that you would pick one to be your first SSO server then the second one would be setup as a additional SSO node in a new site and not the option for an exiting site?
Then what about a sandbox environment where upgrades are tested in the US region. Wouldn’t you not want that to be a separate Security Domain? Or would that be better to setup as a separate SSO server at an existing site EG US Site?
I guess the question is what is the drawback of having multiple vsphere.local security domains?
Paresh
I am trying to find out what is the best way forward to install vCenter 5.5 with 200 hosts and 3000 Guests. Should I install SSO and Web Client Server on one VM Guest server, and Inventory Service, vCenter Server and Update Manager on another? I am also interested in the amount of RAM and Disk space to allocate to each server. I have already looked at the Best Practice document.
Eli
Marvelous perform! This is the form of information that you should distributed through the world-wide-web. Pity to the seek motor for not positioning this kind of post uppr! Come on above as well as consult the site. Thank you so much Equates to)
Imtiaz
We are currently running vCenter 5.1, we have separated web client (only) from the other vCenter components (except database). Also we are using 2 web client servers for the same vCenter which are load balanced. We are in the process of upgrading the vCenter to 5.5
Considering the above recommendation, should we plan to have all the vCenter components local to each other (in one single VM)? I am worried that I am moving the load of 2 web client servers and may affect performance. Any thoughts please.