Save to My DOJO
In this final part of the series, I’ll show you how to install and configure vCenter Server for Windows 6.0 as part of a nested vSphere 6 environment. I’ll be installing vCenter on a Windows Server 2012 64-bit virtual machine. Note that Windows Server 2008 SP2 64-bit is the minimum supported OS version.
When creating the VM, make sure to assign at least 8GB of RAM, 2 vCPUS and roughly 60-80GB of disk space to compensate for both the Windows OS and vCenter Server disk space requirements. In this post, I skipped the part where you install and configure the Windows Server OS.
The Platform Services Controller
Before we jump in and start installing vCenter Server, let’s have a look at the Platform Services Controller (PSC) component. Prior to vSphere 6, one had to install a number of individual components alongside vCenter Server namely the SSO, Web Client, Inventory and vCenter Server in this specific order. This decoupling of components presented users with the option of installing each individual component on its own dedicated VM or physical server which ultimately resulted in a more complex and difficult to manage the environment.
With vSphere 6 .x, VMware has grouped these components under one ceiling, the Platform Services Controller as you probably guessed. This makes for an easier installation of vCenter Server 6.0 given there’s only one installer to run and reduces the chances of a botched installation.
As you’ll learn, you are presented with two deployment models when installing vCenter Server. These are the Embedded Platform Services Controller and the External Platform Services Controller. The choice is primarily governed by the size of your environment or growth thereof. For small-scale environments, the embedded model will suffice where vCenter Server and its components are installed on the same server in one take. For more demanding environments or perhaps where you have multiple vCenter Server which you can link, the external model is the recommended way forward.
Installing vCenter Server 6.0
In the previous post, I reiterated the importance of creating DNS records in advance. In this section, I’ll show you just how to do this using a DNS server running on Windows. For a complete list of vCenter Server for Windows 6.0 requirements, make sure to read this.
UPDATE: Read my post on how to install the latest release of vCenter Server for Windows 6.5.
Setting up DNS
Step 1a – Choose an FQDN for vCenter Server. I’ll be using vcenter60.lab for this tutorial. Proceed to create A and PTR records on the Windows DNS server as shown next.
Step 1b – This step is optional. If you do not have access to a DNS server, run a text editor like notepad in an administrative command prompt and open c:\windows\system32\drivers\etc\hosts. Type in the vCenter Server’s IP address and FQDN as shown next. Save and close the hosts file.
Step 2 – Make sure that the vCenter Server FQDN is correctly resolved. This is a crucial step since the vCenter installation will fail if otherwise. Use the nslookup tool as shown to verify correct functionality.
Step 3 – Power on the Windows Server 2012 VM where vCenter Server will be installed. Once it’s running, mount the vCenter ISO image (see Part 1) using the method described in Part 2 where we mounted the ESXi image.
Installing vCenter Server
Note: You can either carry out the following steps while consoled to the VM using the vSphere client or RDP to the Windows VM, which is what I did. The latter is easier to work with. Also, make sure to install VMware Tools on the Windows VM first.
Step 4 – Using File Explorer, right-click on the VMware VIM DVD drive as shown next and select Install or run program from your media.
Step 5 – Click on the Install button on the VMware vCenter Installer dialog box.
Step 6 – Accept the EULA by agreeing to the terms and clicking Next.
Step 7 – On this screen, you must choose between an Embedded or External deployment mode. Let’s go with Embedded Deployment. Tick the option under Embedded Deployment and click Next.
Step 8 – Type in the vCenter Server’s hostname. This must match the DNS A record (FQDN) created earlier. In theory, you can use the IP address instead of the hostname but this is something I do not recommend since you will eventually run into SSL certificate issues. Click Next.
Step 9 – Under Create a new vCenter Single Sign-On domain, type in a value for the domain name and the Site name. You must also set a password for the administrator@<domain name> account. Click Next when finished.
Step 10 – This screen gives you control over the user context under which vCenter Server services are run in Windows. Select Use Windows Local System Account and click Next. Note: This is acceptable for testing environments. For production environments, it is advisable to user Active Directory user accounts where deployed. This improves user account management and security.
Step 11 – Next, we need to select a database model for vCenter. We will Use an embedded database as it will do just fine for smaller environments. For larger environments, go for an external DBMS solution for better performance and scalability. Press Next.
Step 12 – The network ports required by vCenter Server are best left to their default setting. If for any reason, you need to change ports, make sure that no other service or application conflicts with or uses the same ports. Click Next.
Step 13 – Click Next to accept the default destination folders. Again, you can choose to have vCenter Server installed on a separate disk or partition for easier backups and troubleshooting.
Step 14 – Review the settings. If need be, you can go back and make amends. Click Install to install vCenter.
Step 15 – Once the installation completes, launch the traditional (or Web) vSphere Client to activate vCenter Server. Assuming all the above steps have been followed, you should now have a fully functional vCenter Server. The first thing we need to do is create a datacenter. This is a mandatory object which will contain the nested ESXi hosts created in parts 1 and 2.
Step 16 – Ignore any certificate errors that come up. Press OK to accept the start the 60-day evaluation period.
Step 17 – Right-click on the vCenter Server name and choose New Datacenter. Type in a name for the DC and press Enter or click anywhere on the screen to save the change.
Adding ESXi hosts to vCenter
One of the great things about vCenter Server is that you can manage multiple ESXi hosts using a single interface as opposed to logging in on each individual host. The other advantages, of course, are clustering and the features unlocked which include high availability, load balancing, fault tolerance and power management.
UPDATE: Read my post comparing vCenter Server for Windows to vCenter Server Appliance (vCSA). With vSphere 6.5 released, the recommended way forward is vCSA 6.5.
Step 1 – Right-click on the datacenter and select Add Host while in Hosts and Clusters view.
Step 2 – In the Host field, type in the ESXi FQDN (or IP address), followed by the root account and password. Click Next.
Step 3 – Press YES to acknowledge the certificate security alert.
Step 4 – On the summary screen, press Next.
Step 5 – If you have purchased a license, you can assign it now. If not, press Next and keep using ESXi in evaluation mode until the 60-day trial period expires.
Step 6 – Leave the Enable Lockdown Mode unchecked. You may wish to enable this setting in production environments. Just make sure you don’t end up locking yourself out.
Step 7 – Select the datacenter under which the ESXi hosts will reside and press Next.
Step 7 – Click Finish to complete the addition process.
Note: The above steps, outlined in this section, must be repeated for the remaining two ESXi hosts.
Conclusion
If you have made it this far, congratulations. You now have a nested vSphere 6.0 environment comprising a vCenter Server 6.0 managing three nested ESXi hosts. You can use it as a test bed for all sorts of scenarios as well as to test vSphere features ranging from clustering to vSAN.
[the_ad id=”4738″][the_ad id=”4796″]
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!
10 thoughts on "How to set up a nested vSphere 6 environment – Part 3"
Hi,
Thanks for this guide, I’m setting up a similar nested environment to test some vCloud Director. I’m having some problems with the nested networking though. I’ve stripped the configuration back to a basic minimum, and have identified that although the nested ESXi server can communicate with the “real world” via its default vswitch/port group, a VM running on the nested ESXi server cannot. Is this expected, or is there some configuration I need to update to enable the guests to communicate with the outside world?
Hi,
Thank you for your question first of all.
It’s been a while since I’ve used vDirector but I recall that questions on how to allow outbound traffic from virtual machines to the outside world were quite common. The short answer is that you need to set up and configure an edge gateway.
This link (especially part 2) imho, provides a thorough explanation on how to grant internet access to your vms.
Hope this helps.
Jason
Awesome 3 part series. Thanks for the hard work.
Comment highly appreciated.
Thanks
Jason
Great series! I’m studying for my VCP6-DCV, and while my physical host is quite robuts, I have only the one at my disposal so I knew all along that nesting was my only viable path to having a full lab topology to learn with. One question: Is it expected (and moreover, is it mandatory or at least highly helpful) to have two distinct vCSA appliances, one which manages the physical host (and, for now at least, ONLY that single node) and an additional one which manages only the nested ESXi instances? I can see that this approach would abstract away the base topology once the lab is fully built and not seeing anything but the nested environment would cut down on potential for confusion. But is it essential to do two vCenters in this way? I ask mainly because my EVAL Experience gives me licensing for just one (AFAIK), but I could always blow away the nested lab and re-create it after 60-days (and probably will…many times). Thank you again for your great reference!
Hi Scott,
Thanks for the comment first of all. Glad you found the series interesting.
Re. your question I’m sorry but I didn’t quite grasp in what context would you need two separate VCSAs. Is it a requirement towards preparing for the exam?
What I can tell you is that in general, my test environment consists of at max. 2 VCSAs, a PSC and 3 ESXi hosts all of which are nested. The need for 2 VCSAs came about when writing about enhanced linked mode. The whole environment resides on a physical ESXi host which is in turn managed by a virtualized vCenter Server Windows. The test env resides on a network reserved for testing but even so, it still has visibility to the physical ESXi host and vCenter Server for Windows. As long as you have good naming and addressing standards (DNS IP), you should not run into any conflicts. As for the licensing, I hear you. I too have to tear down and rebuild come day 60 since I’m using eval. Again, it’s a small environment which I only use for testing stuff before committing to writing so it’s no biggie really.
Hope this helps and good luck with your certifications.
Jason
Thank you Jason. I think I understand what you’ve done, and I’ll try to clarify what I’ve done as well. Where you have a virtualized vCenter Windows as the management plane for your physical ESXi, my management of the physical ESXi server is a VM running under what I’m calling the physical server’s “Base Hypervisor”. So in other words, nothing is managing the physical ESXi until it first boots itself up and then boots up the VM’s for Network Services (mainly DNS right now, but LDAP etc. eventually) and the vCSA. I can point the C# client directly at it if I have to, of course. I also have a NexentaStor storage appliance and have finished setting up iSCSI on one nested ESXi VM (which I’ll prep and templatize for cloning once I think it’s at “gold image” quality for my purposes).
I’m just not quite sure whether it’s possible to have that base-layer VM vCSA also manage the nested hypervisors. It naturally sees them as VM’s running under the base hypervisor that it does already manage; I just don’t know whether it’ll wreak havoc to have the same appliance try to manage those VM’s as hosts as well and add them to its inventory, or if it’s preferable to manage the nested ESXi instances from a completely separate vCenter setup. FWIW, I do plan to *also* build along your lines in the latter scenario for more latitude in experimenting with both versions of vCenter (SLES appliance & Windows) and external SQL database as opposed to the embedded vPostgress. So like you that’ll mean 1 new PSC with its own all-new SSO domain and 2 vCenter’s subordinate to that, 1 of each flavor. That should give me hands on knowledge of the Windows variant and external db’s that I so far lack.
Hi Scott, apologies for the late reply. If you only have one physical ESXi host, than I don’t see the need to have a vCenter Server managing it. However you could still manage it and any other nested ESXi host you choose to set up without any conflicts assuming your network setup is not overly complicated. To be on the safe side you could place say the nested ESXi host under one datacenter and/or cluster and the physical host in another. I imagine that this is a testing environment so ideally testing whatever comes to mind is the way to go in my opinion.
NexentaStor, that is something I haven’t used in a while. Nice GUI interface and easy to set up but suffered many a headache when used in production.
At this stage I suggest you focus on vCSA 6.5 if you can. vCenter for Windows will soon be history even though many will probably still keep using it before VMware drop support for it.
Hope this helped.
regards
Jason
Indeed very helpful and awesome stuff. Just got one question, can I use the same vcenter (that is managing physical ESXI host) to manage nested ESXI hosts as well?