Centralizing User Authentication Using vCenter Single Sign-On

Centralized user authentication is not listed as a core service of vCenter Server, but it is essential to how vCenter Server and many other VMware products operate. In Chapter 2, “Planning and Installing VMware ESXi,” we discussed a user's authentication to an ESXi host under the context of a user account created and stored locally on that host. Generally speaking, without vCenter Server, you would need a separate user account on each ESXi host for each administrator who needed access to the server. As the number of ESXi hosts and required administrators grows, the number of accounts to manage grows exponentially. There are workarounds for this overhead; one such workaround is integrating your ESXi hosts into Active Directory, a topic we'll discuss in more detail in Chapter 8, “Securing VMware vSphere.” In this chapter, we'll assume the use of local accounts, but be aware that using Active Directory integration with your ESXi hosts does change the picture somewhat. In general, though, the centralized user authentication that vCenter Server offers is easier to manage than other available methods.

In a virtualized infrastructure with only one or two ESXi hosts, administrative effort is not a major concern. Administering one or two servers would not incur incredible effort on the part of the administrator, and creating user accounts for administrators would not be too much of a burden.

In situations like this, you may not miss vCenter Server from a management perspective, but you may certainly miss its feature set. In addition to its management capabilities, vCenter Server can perform vMotion, configure vSphere Distributed Resource Scheduler (DRS), establish vSphere High Availability (HA), and use vSphere Fault Tolerance (FT). These features are not accessible using ESXi hosts without vCenter Server. You also lose key functionality such as vSphere Distributed Switches, host profiles, policy-driven storage, VM encryption, and vSphere Update Manager. vCenter Server is a requirement for any enterprise-level virtualization project.

But what happens when the environment grows? What happens when there are 10 ESXi hosts and 5 administrators? Now the administrative effort of maintaining all these local accounts on the ESXi hosts becomes a significant burden. If a new account is needed to manage the ESXi hosts, you must create the account on 10 different hosts. If an account password needs to change, you must change it on 10 different hosts. Then add into this equation other VMware components such as vRealize Automation or vRealize Orchestrator, with their own possible accounts and passwords.

The Platform Services Controller (PSC)—or more accurately, the medley of components that comprise the service of vCenter Single Sign-On (SSO), including the Secure Token Service (STS) and Identity Management Service (IDM)—addresses this problem. It is a prerequisite for installing vCenter Server—that is, vCenter Server cannot be installed without SSO being available first. We'll explain briefly how SSO works and what other software it interacts with (both VMware and non-VMware).

Prior to vSphere 5.1, when you logged onto vCenter your authentication request was forwarded to either the local security authority on vCenter Server's OS or Active Directory. In versions up through vSphere 6.7, with SSO the request can still end up going to Active Directory, but it can also go to a list of locally defined users within SSO itself or to another Security Assertion Markup Language (SAML) 2.0–based authority. Generally speaking, SSO is a more secure way of authenticating to VMware products. Notice we said products and not vSphere? That's because SSO has hooks into other VMware products, not just vCenter Server. vRealize Orchestrator, vRealize Operations Manager, and vCloud Director are just a few. Why is this important? It means that SSO can take a single user and provide them with access to everything they need through the virtual infrastructure with a single username and password, and it can do so securely.

The following steps outline what happens when a user logs on using the vSphere Web Client or any other VMware product that is integrated with SSO (see Figure 3.2):

1. The vSphere Web Client presents a secure web page to log into.
2. The username and password are issued to the SSO server (in the form of a SAML 2.0 token).
3. The SSO server sends a request to the relevant authentication mechanism (local, AD, or another SAML 2.0–based authority).
4. Once authentication succeeds, SSO passes a token to the vSphere Web Client.
5. This token can now be used to authenticate directly with vCenter, or any other SSO integrated VMware products.

As you can see, the authentication procedure can sound more complicated than other traditional methods; however, the process is seamless to the end administrators who get access as they always have.

Before we talk about some of the more visible components of vCenter Server, let's discuss some of the unseen aspects inside the Platform Services Controller of vCenter.

Understanding the Platform Services Controller

vSphere 6.0 introduced a new component called the Platform Services Controller (PSC). This component has remained in the vSphere architecture up through vSphere 6.5, and now vSphere 6.7. It is used to run common components for VMware products in a central or in distributed location(s). The PSC offers multiple services; let's step through them so you can understand why the PSC is vital to your vSphere environment:

• Single Sign-On (SSO)
• Licensing
• Certificate Authority
• Certificate Store
• Service Registry

As you read over the paragraph preceding this list, you may have noticed that we said “for VMware products.” The PSC is not solely for vCenter Server, or vSphere for that matter. These services can be located externally or internally to the vCenter Server and provide a common service across your entire VMware environment.

As we mentioned in the previous section, SSO is a service offered via the PSC for authentication brokering and secure token exchange, and can be shared to multiple vCenter instances or other VMware products.

The Licensing Service holds all licensing information for the vSphere environment and potentially other products, too, when they ship with PSC support. It removes the dependency where vCenter must be available for licensing operations to occur. This is especially important when you're installing multiple vCenter Servers in a geographically wide environment—older vCenter versions didn't replicate licensing information between them unless they were in a linked mode group.

The Certificate Authority and Store is the SSL certificate mint and wallet for your vSphere Environment. These services will allow you to create your own or store and assign third-party certificates for both vCenter and ESXi hosts. You'll find more details on how this service is used in Chapter 8.

The Service Registry works as the name suggests: it is a registration index of all VMware services available in this environment. This index will be particularly powerful when all VMware products also register their existence with the PSC, or more specifically, the Service Registry. No longer will you need to provide the details of each component to every other component; the Service Registry will do this automatically on your behalf.

During the installation of the PSC, which we'll detail later in this chapter, you see options for the installation type. Depending on the availability requirements of your vCenter Server installation, you may wish to make the PSC embedded on the vCenter Server; alternately, you may choose to make the PSC externally available from multiple sites, highly available in a single cluster, or even highly available across multiple sites. When you're installing a PSC for the first time, the first instance will always be a single node. Installing additional PSCs then allows you to join nodes to suit your environment. They can be external to the vCenter Server or embedded, as you can see in Figure 3.3. We'll discuss the pros and cons of the different PSC models in the section “Protecting the Platform Services Controller,” later in this chapter We will also go through configuring the more complex installation model, a vCenter Server using an external Platform Services Controller, later in this chapter. After you've wrapped your head around each configuration, the simpler, embedded Platform Services Controller model will be quite intuitive.

Using the vSphere Web Client for Administration

In the months that preceded and followed the release of vSphere 6.5, VMware made deprecation announcements to both their Flash-based vSphere Web Client and vSphere Client, the latter often referred to as C# Client or Thick Client, ushering in a new HTML5-based vSphere Client. The new HTML5 Client, like its Flash-based predecessor, is a server-side service for administering vSphere from a web browser. The following browsers are certified and supported with the vSphere Web Client and the HTML5 Client:

• Microsoft Internet Explorer—versions 10 and later (Windows only)
• Microsoft Edge—versions 39 and later (Windows only)
• Mozilla Firefox—versions 39 and later
• Google Chrome—versions 34 and later

Additionally, to use the vSphere Web Client, you must have Adobe Flash Player version 16 or later, up to and including version 23 installed.

As stated in Chapter 2, the HTML5-based vSphere Client is not as feature-rich as the Flash-based vSphere Web Client. As you read through the rest of this book, you can assume that unless we specify the HTML5 Client, the Flash-based vSphere Web Client is the default choice and the one you should be using.

Providing an Extensible Framework

Just as centralized authentication is not a core vCenter Server service, we don't include vCenter Server's extensible framework as a core service. Rather, this extensible framework provides the foundation for vCenter Server's core services and enables third-party developers to create applications built around vCenter Server. Figure 3.4 shows some of the components that revolve around the core services of vCenter Server.

A key aspect for successful virtualization is the ability to allow third-party companies to provide products that add value, ease, and functionality to existing products. By building vCenter Server in an extensible fashion and providing an application programming interface (API) to it, VMware has shown its interest in allowing third-party software developers to play an integral part in virtualization. The vCenter Server API allows companies to develop custom applications that can take advantage of the virtual infrastructure created in vCenter Server. For example, numerous companies have created backup utilities that work off the exact inventory created inside vCenter Server to allow for advanced backup options of VMs. Storage vendors use the vCenter API to create plug-ins that expose storage details, and other third-party applications use the vCenter Server APIs to provide management, monitoring, life-cycle management, or automation functionality.

You can find more information on vCenter Server functionality in Chapter 10, which provides a detailed look at templates along with VM deployment and management, and in Chapter 8, which goes deeper into vCenter Server's access controls. Chapter 11 discusses resource management, and Chapter 13 offers an in-depth look at ESXi host and VM monitoring as well as alarms.

You're almost ready to take a closer look at installing, configuring, and managing vCenter Server. First, however, we'll discuss how to choose which version of vCenter Server you should deploy in your environment.

Sizing Hardware for vCenter Server

The amount of hardware that vCenter Server requires is directly related to the number of hosts and VMs it will be managing. This planning and design consideration applies not only to the appliance–based version of vCenter Server but also the Windows Server–based version. Because it is a prepackaged virtual appliance, the virtual hardware of the vCenter Server virtual appliance is predefined and established before it is deployed.

As a starting point, the minimum hardware requirements for the Linux–based version of vCenter Server are as follows:

• Two vCPUs
• 10 GB of RAM
• 300 GB of disk space
• A network adapter (Gigabit Ethernet is strongly recommended)

Keep in mind these are minimum system requirements that an appliance can be deployed with, only allowing you to run up to approximately 10 hosts and 100 VMs. Large enterprise environments with many ESXi hosts and VMs must scale the vCenter Server system accordingly.

Unlike the prepackaged Linux-based vCenter Server virtual appliance, the minimum requirements for the Windows Server–based edition of vCenter Server do not account for running a database server, which vCenter Server requires. Although vCenter Server is the application that manages your ESXi hosts and VMs, vCenter Server uses a database for storing all of its configuration, permissions, statistics, and other data. Figure 3.5 shows the relationship between vCenter Server and the separate database server.

Although you can run vCenter Server and its dependencies on the same machine, it's usually not recommended, because it creates a single point of failure for key aspects of your virtual infrastructure. However, sometimes you don't have a choice, especially in smaller environments where capacity is at a premium. Keep in mind that VMware recommends 10 GB of RAM if vCenter Server is installed with an embedded Platform Services Controller, but only for environments with up to 10 ESXi hosts or 100 VMs. This would be the case if you use the Embedded option when installing vCenter Server.

VMware suggests vCenter hardware requirements depending on the size of the environment that vCenter will be managing. Table 3.1 shows these recommendations.

Should you choose to run the separate database server on the same physical or virtual computer as vCenter Server, if you're opting for a Windows-based deployment, you'll need to consult the documentation for your chosen database server. Without a doubt, the database server requires additional CPU capacity, RAM, and disk storage just like other co-located services, so you will need to plan accordingly. With the vCenter Server virtual appliance, this has been taken care of for you with the embedded Postgres database and the removal of external databases available in previous versions, so you just need to account for inventory size and other integrating components that you plan on deploying to the environment. That brings us to the next topic: planning for availability.

Planning for vCenter Server Availability

Planning for a vCenter Server deployment is more than just accounting for CPU and memory resources. You must also create a plan for business continuity and disaster recovery. Remember, features such as vSphere vMotion, vSphere Storage vMotion, vSphere DRS, and, to a certain extent, vSphere HA stop functioning or are significantly impacted when vCenter Server is unavailable. While vCenter Server or any component it depends on is down, you won't be able to clone VMs or deploy new VMs from templates. You also lose centralized authentication and role-based administration of the ESXi hosts. Clearly, there are reasons why you might want vCenter Server to be highly available.

Keep in mind, too, that the heart of the vCenter Server and its components are stored in backend databases. Although the Linux-based vCenter Server virtual appliance obfuscates this from you with the use of an embedded database, with a Windows-based deployment, this needs to be high on the list of considerations. Any good disaster-recovery or business-continuity plan must also include instructions on how to handle data loss or corruption, especially so in the backend databases, and if you're running external backend databases on separate physical computers or VMs, they must be designed and deployed to be resilient and highly available. This is especially true in larger or mission-critical environments.

There are a few different ways to approach this concern. First, we'll discuss how to protect the vCenter Server components, then the vCenter Server itself, and finally, we'll talk about protecting the separate database server.

PROTECTING THE VCENTER DATABASE

For high availability of the database server supporting the Windows-based vCenter Server, you can configure the backend database on a cluster. Figure 3.6 illustrates using a SQL Server cluster for the backend database. This figure also shows a standby vCenter Server system. Methods used to provide high availability for the database server are in addition to whatever steps you might take to protect vCenter Server itself. Other options might include using SQL log shipping or database mirroring to create a database replica on a separate system. If clustering or log shipping/database replication is not available or is not within fiscal reach, you should strengthen your database backup strategy to support easy recovery in the event of data loss or corruption. Using the native SQL Server tools, you can create a backup strategy that combines full, differential, and transaction log backups. This strategy allows you to restore data up to the minute when the loss or corruption occurred.

The suggestion of using a VM as a standby system for a physical computer running vCenter Server naturally brings us to the last topic surrounding architecture: Should you run vCenter Server in a VM? That's quite a question, and it's what we'll answer next.

Running vCenter Server and Its Components as VMs

As touched on earlier, you certainly have the option of skipping a physical server entirely and running vCenter Server and its components as a VM or even multiple VMs. This is actually the VMware recommendation. Running vCenter on a VM gives you several advantages, including snapshots, clones, vMotion, vSphere HA, Fault Tolerance, and vSphere DRS.

Running vCenter Server and the PSC as VMs on an HA-enabled cluster makes perfect sense. In fact, even with regular backups, clones, or snapshots, running vCenter Server on an HA-enabled cluster should be your default platform. Remember, the VMs running on your ESXi hosts, the storage, and the networking all continue to operate normally even with vCenter down. There are no dependencies on vCenter for these VMs to keep running. If the ESXi host that's running these VMs becomes unavailable, HA will kick in and restart the vCenter VM(s) on another available host. You might not even know it's happened unless your monitoring systems tell you!

Another feature that's available with vSphere 6 is Fault Tolerance (FT). Previously FT could only support one vCPU on a protected Virtual Machine. This meant that vCenter was not a possible candidate as it requires a minimum of two vCPUs to operate. As of vSphere 6.7 and later, FT supports eight vCPUs, vCenter and the PSC can be protected to avoid downtime altogether if an individual host goes down. You can read more about both HA and FT in Chapter 7, “Ensuring High Availability and Business Continuity.”

Snapshots are a feature we'll discuss in detail in Chapter 9. At a high level, snapshot functionality lets you return to a specific point in time for your VM—in this case, your vCenter Server VM. vMotion gives you the portability to move the server from host to host without experiencing server downtime. But what happens when a snapshot is corrupted or the VM is damaged to the point it will not run? With vCenter Server as your VM, you can make regular copies of the virtual disk file and keep a “clone” of the server ready to go in the event of server failure. The clone will have the same system configuration used the last time the virtual disks were copied. Given that the bulk of the data processing by vCenter Server ends up in a backend database running on a different server, this should not be very different. Additionally, if you are using the vCenter Server virtual appliance with the embedded database, you could run into issues with snapshots and reverting to snapshots. This might or might not be an issue, but be sure to plan accordingly. Figure 3.7 illustrates the setup of a manual cloning of a vCenter Server VM.

Some organizations may have a “virtualize first” or a “100 percent virtual” policy; although this may give all the advantages of virtualization, you need to consider other issues in the design of the infrastructure. Having a separate management cluster to host all the vCenter Server components, along with any dependencies such as database servers and Active Directory, is fast becoming commonplace. This separate management cluster will ensure that a production workload incident would not negatively impact the manageability of the environment.

Delving into design best practices is outside the scope of this book, just as with physical infrastructure design, but there are certain things you must consider to ensure that your virtual infrastructure is designed to meet business requirements. Like any “best practice,” it's a recommendation when there are no requirements that would point you in a different direction. For more information on vSphere design, we recommend you read VMware vSphere Design (Sybex, 2013).

By now, you have a good understanding of the importance of vCenter Server in a large enterprise environment and some of the considerations that go into planning for a vCenter Server deployment. You also have a good idea of the components, features, functions, and role of vCenter Server. With this information in mind, let's deploy vCenter Server. The next section mainly focuses on the installation of the vCenter Server and Platform Services Controller virtual appliances; for information on the Windows-based vCenter Server, refer to older versions of this book.

INSTALLING THE VCENTER SERVER COMPONENTS

The vCenter Server virtual appliance is a Photon OS–based VM that comes prepackaged and preinstalled with vCenter Server. It is commonly referred to as the vCSA, vCVA, or sometimes just the vCenter appliance. Rather than creating a new VM, installing a guest OS, and then installing vCenter Server, you only need to deploy the virtual appliance using a special deployment application. We discussed the vCenter Server virtual appliance earlier in this chapter in the section “Choosing the Version of vCenter Server.”

The vCenter Server virtual appliance comes as a packaged VM that requires its own deployment tool, both of which are packed together on the installation media. We'll discuss OVF templates in great detail in Chapter 10, but for now we'll simply explain them as an easy way to distribute “prepackaged VMs.”

The vCenter Server virtual appliance deployment and configuration takes only a few minutes and is not too administratively intensive, assuming you've completed all the pre-installation tasks. Once mounted, you can start the vCenter Server installation by double-clicking the OS-specific installer inside the vCenter Server installation directory.

The vCenter Server Appliance Installer, shown in Figure 3.8, is the central point for freshly deploying, upgrading, migrating, and even restoring your vSphere environment. But before we get too carried away, let's focus on getting your first environment deployed and take you through what the Install option provides. Once the Install tile is clicked, this option enables you to deploy the following:

• vCenter Server with an embedded Platform Services Controller
• vCenter Server that uses an External Platform Services Controller
• External Platform Services Controller

Unlike the a la carte style of installation that came with vSphere 5.x, with vSphere 6.0 and later, nearly all of the auxiliary components shipped with vCenter Server are now bundled together, and you will have full access to them once the system has been setup. These auxiliary components include the following:

• vCenter Authentication Proxy
• vSphere Web Clients (Flash-based and HTML5-based)
• vSphere Update Manager
• vSphere Auto Deploy
• vSphere Syslog Collector
• vSphere ESXi Dump Collector

In addition, the ISO that packages the vCenter Server Appliance Installer contains the binaries necessary to set up Update Manager Download Service (UMD). Chapter 4, “vSphere Update Manager and the vCenter Support Tools,” provides more detail on vSphere Update Manager. For now, we'll focus just on vCenter Server and its components.

INSTALLING A PLATFORM SERVICES CONTROLLER

Earlier in this chapter, we explained that vCenter Single Sign-On (SSO) is a prerequisite for vCenter and is part of the Platform Services Controller. Not only must it be installed for vCenter to run, it must also be running before the vCenter Server itself is installed.

We'll assume that you've already downloaded the files for the vCenter Server virtual appliance from VMware's website at my.vmware.com. You'll need these files before you can proceed with deploying either the Platform Services Controller virtual appliance or vCenter Server virtual appliance.

Use the following steps to install a PSC running SSO:

1. Mount the ISO (or burn it to a CD).
2. Once mounted, launch the vCenter Server Appliance Installer. To begin, navigate to x :vcsa-ui-installer, where x is the drive or mount point, depending on your operating system. There will be three directories available to you, allowing you to run installer on Mac OS X (/mac/installer.app), Microsoft Windows (win32installer.exe), or Linux (/lin64/installer).
3. The vCenter Server Appliance Installer should appear. Click Install, review the Introduction screen, which explains the two-stage appliance deployment operation, and then click Next.
4. On the End User License Agreement (EULA) page, select the check box to accept and click Next.
5. On the Select Deployment Type page, as shown in Figure 3.9, we'll choose the second option, Platform Services Controller, and click Next.

   

   The list of options available allow you to craft your environment's architecture given the set of requirements we covered previously.

   • The first option, vCenter Server With An Embedded Platform Services Controller, allows you to install a combined vCenter Server installation with a PSC on the same system.
   • The second option, which we've used for this walkthrough, installs a stand-alone/external PSC. The Platform Services Controller option installs only the components required for the PSC and will not install vCenter Server itself. This is a precursor to PSC HA, if needed.
   • Finally, the third option, vCenter Server (Requires External Platform Services Controller), will install just vCenter Server and, as the option details, not the PSC components. This option should only be used if you already have a stand-alone, external PSC installed that you wish to join a new vCenter installation to.
6. You'll need a running ESXi host to deploy the vCSA to. At a minimum, the host needs to be running version 6.0 to work for this installation. Provide the ESXi hostname or IP address, a username (in this case, root), and the appropriate password. Click Next.
7. A pop-up box will prompt you with an SSL certificate warning, which will be the certificate thumbprint of the ESXi host. Click Yes to proceed to the next screen.
8. Supply a VM (or display) name for the Platform Services Controller virtual appliance. You will also need to provide a password for the root account of this VM. Click Next to continue.
9. Select the datastore that you want the Platform Services Controller to reside on, and then click Next.

   Chapter 6 and Chapter 9 provide more details on the different disk provisioning types. In all likelihood, you'll want to use Thin Provision to help you conserve disk space.

10. The final steps of Stage 1 are to provide the network information for the VM deployment. Working from top to bottom of the screen, first you must choose a network. On the ESXi host, this could also be called a port group, which you can read more about in Chapter 5, “Creating and Configuring a vSphere Network.”
11. Second, select between IPv4 or IPv6 as the protocol. You'll most likely want to use a static IP address for Platform Services Controller—so on the third field, IP Address, select Static. However, if DHCP is available on the selected network, you can use that option. You'll need to provide a hostname, the associated IP address, a subnet mask, a gateway, and at least one DNS server. The hostname established in this step will be used to sign the SSL certificate generated upon deployment.
12. Finally, new in vSphere 6.7 for appliance deployments, you have the option to provide unique ports that the Platform Services ontroller will use. Leave these as default, and click Next.

    Unless there is a conflict in your environment, we recommend not changing the default port numbers. It can make configuration and troubleshooting more difficult later on.

13. On the last page of Stage 1, review all the configuration details, as shown in Figure 3.10, to make sure there are no errors. Click Finish to deploy the virtual appliance.

    

    A progress window like the one shown in Figure 3.11 will appear while the Platform Services Controller virtual appliance is being deployed to the ESXi host.

    

14. After the appliance has been successfully deployed, you'll begin Stage 2 to finalize the Platform Services Controller's configuration. Review the Introduction page, which explains the two-stage appliance deployment operation, and then click Next.
15. In the Appliance Configuration section, provide an NTP source. Unless necessary, due to a lack of NTP server availability in your environment, avoid using the VMware time sync tool because a time-drift can occur unless it's set up in a specific way.

    For troubleshooting purposes, enable SSH access, and then click Next.

16. On the following screen, shown in Figure 3.12, you're asked if you would like to configure a new Single Sign-On instance or join an existing one. Again, choose to configure a new SSO instance. You'll need to create a domain name, an SSO administrator password, and a site name. Click Next to continue.

    

    It is worth noting that these domain and site names have nothing to do with Active Directory domain or site names. In fact, we suggest that you use different names to avoid namespace conflicts in the future.

17. The PSC installer will now ask you to join the Customer Experience Improvement Program that enabled VMware to collect telemetry data from your environment. Depending on your security requirements, either check the box to join or uncheck it to opt-out. Then click Next.
18. Finally, review all configuration details for errors, as shown in Figure 3.13. Click Finish to proceed with configuring the Platform Services Controller virtual appliance. You'll receive one last warning that you will be unable to pause the installation after you proceed—essentially, there is no turning back from this point—so double-check those final configuration details, and then click OK.

    

19. When installation is complete, click Close to close the installer.

After you complete the installation of Platform Services Controller, a link to the Platform Services Controller Getting Started page is displayed (https://<server name>:443 or https://<server ip address>:443). Unlike the previous version of vSphere, the administrator no longer has access to the Platform Services Controller UI, where the Login Banners, Smart Card Authentication, and certificate management were handled. All of these items have been relocated into vCenter Server HTML5-based Web Client.

INSTALLING VCENTER SERVER

After you've completed deploying the Platform Services Controller, you are now in a position to install the vCenter Server virtual appliance. If you have installed vCenter any number of times with a previous release, be it on Windows or using the appliance, this process should feel very familiar. Further, due to the nature of the two-stage operation for deploying the appliances, Stage 1 is largely a repeat of the same process you followed to deploy the Platform Services Controller.

Perform the following steps to install vCenter Server virtual appliance:

1. Mount the ISO (or burn it to a CD).
2. Once mounted, launch the vCenter Server Appliance Installer. To begin, navigate to x :vcsa-ui-installer, where x is the drive or mount point, depending on your operating system. There will be three directories available for you, allowing you to run installer on Mac OS X (/mac/installer.app), Microsoft Windows (win32installer.exe), or Linux (/lin64/installer).
3. The vCenter Server Appliance Installer should appear. Click Install, review the Introduction screen, which explains the two-stage appliance deployment operation, and then click Next.
4. On the End User License Agreement (EULA) page, select the check box to accept and click Next.
5. For Select Deployment Type, you have the same options outlined in the previous section. Since we showed you how to do a stand-alone/external Platform Services Controller, we'll now step you through a stand-alone vCenter Server and join them together. The result will functionally be the same as the Embedded Platform Services Controller option, but you'll have seen both sides of the installation process. This is important because if you want to add new vCenter Servers (or PSCs) in the future, the chances are you'll separate them. Select the third option, vCenter Server (Requires External Platform Services Controller), and click Next.
6. Identical to the Platform Services Controller process, you'll need a running ESXi host to deploy the vCSA to. At a minimum, the host needs to be running version 6.0 to work for this installation. Provide the ESXi hostname or IP address, a username (in this case, root), and the appropriate password. Click Next.
7. A pop-up box will prompt you with an SSL certificate warning, which will be the certificate thumbprint of the ESXi host. Click Yes to proceed to the next screen.
8. Supply a VM (or display) name for the vCenter Server virtual appliance. You will also need to provide a password for the root account of this VM. Click Next to continue.
9. Select the datastore that you want the vCenter Server to reside on, and then click Next.
10. The following screen, shown in Figure 3.14, is where we see the first big divergence from the Platform Services Controller installation: you'll be asked to define the appliance's size. Select Tiny vCenter Server from the Deployment Size drop-down and Default from the Storage Size drop-down, and then click Next to continue.

    

    Though we selected Tiny, the drop-down menus for Deployment Size and Storage Size allow you to configure the number of vCPUs and Memory along with Storage Space, respectively. The former drop-down defines the number of hosts and virtual machines the appliance can handle, while the latter drop-down defines the retention time of non-persistent items stored on disk, such as logs. These choices will dictate what the appliance will receive upon deployment.

11. The final steps of Stage 1 are to provide the network information for the VM deployment. Working from top to bottom of the page, first you must choose a network. On the ESXi host, this could also be called a port group. Since you've already performed this activity for your PSC deployment, select the port group you previously used.
12. Second, select between IPv4 or IPv6 as the protocol. You'll most likely want to use a static IP address for vCenter Server so in the third field, IP Address, select Static; however, you have the option to use DHCP if it is available on the selected Network. You'll need to provide a hostname, the associated IP address, a subnet mask, a gateway, and at least one DNS server. The hostname established in this step will be used to sign the SSL certificate generated upon deployment.
13. Finally, new in vSphere 6.7 for appliance deployments, you have the option to provide unique ports that the vCenter Server will use. Leave these as default values. Click Next.

    Unless there is a conflict in your environment, we recommend not changing the default port numbers. It can make configuration and troubleshooting more difficult later on.

14. On the last page of Stage 1, review all the configuration details to make sure there are no errors. Click Finish to deploy the virtual appliance.

    A progress window like the one shown earlier in Figure 3.11 will appear while the vCenter Server virtual appliance is being deployed to the ESXi host.

    You can use the VM console from the Host Client to watch the virtual appliance boot up. Eventually, it will display a virtual appliance management screen, as shown in Figure 3.15. The vCenter Virtual Appliance console looks very similar to an ESXi host console. You can perform some limited configuration and troubleshooting from here, but the vast majority of vCenter configuration will be performed using the vSphere Web Client. The next section will show you what that looks like.

    

15. When the appliance has been successfully deployed, you'll be greeted with a Success screen. This screen displays a web address you can use in the event that you need to continue the installation of this vCenter at a later time. That is, from the web address, you can continue the Stage 2 operation. For the sake of continuity, let's keep using the Installer; click Continue to move to Stage 2.
16. Begin Stage 2 of the deployment that finalized the vCenter Server's configuration by reviewing the Introduction page, which again explains the two-stage appliance deployment operation, and then click Next.
17. In the Appliance Configuration section, you'll also need to provide an NTP source. Like with the PSC install, unless necessary, such as a lack of NTP server in your environment, avoid using the VMware time sync tool because it can cause time-drift unless it's set up in a specific way.

    For troubleshooting purposes, enable SSH access, and then click Next

18. The following screen, shown in Figure 3.16, is where we see the second noticeable divergence from the Platform Services Controller installation. Enter the Platform Services Controller name you previously installed, along with the SSO domain name and the password to the Administrator account. Note that there is no mention of the Site as that is defined at the Platform Services Controller level; the vCenter Server simply inherits the site that is associated with the Platform Services Controller you join it to. Click Next to continue.

    

19. On the last page of Stage 2, review the configuration details for errors, as shown in Figure 3.17. Click Finish to proceed with configuring the vCenter Server virtual appliance. You'll receive one last warning that you will be unable to pause the installation once you proceed, so double-check those final configuration details, and then click Finish.

    

20. When the installation is complete, click Close to close the installer.

After you complete the installation of vCenter Server, a link to the vCenter Server Getting Started page is displayed (https://<vcenter.domain.name>: 443 or https://<vcenter ip address>:443). Unlike the Platform Services Controller, on the Getting Started for vCenter Server, you'll have the option to launch either the HTML5-based Web Client (https://<vcenter.domain.name>/ui) or the Flash-based Web Client (https://<vcenter.domain.name>/vsphere-client). If you click the latter link, your default web browser will launch to this page. Before we dive into this area, we want to cover a few details regarding user interfaces and services.

The Flash-based vSphere Web Client connected to vCenter Server should be the primary management tool for managing vCenter. However, in the event that vCenter Server becomes unavailable, the HTML5-based Host Client will allow you to connect to each of the managed ESXi hosts, and give you visibility into their respective VMs. As we've mentioned, the Host Client can connect directly to ESXi hosts only under the context of a local user account defined on each ESXi host. That's not to say you cannot log in with an Active Directory account, but ESXi does not have any integration with the Platform Services Controller, so while you can authenticate to each host independently, once the vCenter Server services have been restored, your token won't allow you to seamlessly log in.

After you install vCenter Server, a number of new services will be installed to facilitate the operation of vCenter Server. Depending on whether you have installed both the PSC and vCenter on the same server, the services you may see will differ. Here are some of the most important ones:

• VMware vCenter Server, the core of vCenter Server that provides centralized management of ESX/ESXi hosts and VMs
• VMware Services Lifecycle Manager API, the interface to the VMware Lifecycle Manager (vMon) that provides the watchdog service to the Platform Services Controllers and vCenter Server, ensuring each node has healthy services and proper start order
• VMware Postgres, the embedded database on vCenter Server where configuration and historical data from the environment is preserved
• VMware vSphere Web Client, the web server that runs the user interface

As a vSphere administrator, you should be familiar with the default states of these services. In times of troubleshooting, check the status of the services to see whether they've changed. Later in this chapter, we'll show you where to monitor the services within the VMware Appliance Management Interface, but that's only useful if your vCenter is working enough to see that user interface. Keep in mind the dependencies that exist between vCenter Server and other services on the network. For example, if the vCenter Server service is failing to start, be sure to check that the system has access to the Platform Services Controller. If vCenter Server cannot access the PSC because of a lack of connectivity or the PSC services are not running, it will not start.

As additional features and extensions are installed, additional services will also be installed to support those features. For example, installing vSphere Update Manager will install an additional service called VMware Update Manager Service. You'll learn more about vSphere Update Manager in Chapter 4.

In Chapter 2, you learned that there are two clients that can be used to administer a vCenter Server installation: the old vSphere Desktop Client and the newer vSphere Web Client. We guided you through installing the older client. In previous versions of vSphere, the Web Client required a separate install, but with vSphere 6, the vSphere Web Client is installed with every vCenter Server installation.

Now that you've successfully installed vCenter Server, you'll probably want to log in and get started. Unless you also wish to know how to deploy for enhanced linked mode, feel free to skip to the section “Exploring vCenter Server.”

The vSphere Web Client Home Screen

So far, you've seen only the Hosts And Clusters inventory view within the traditional vSphere Client, but it's very similar in the Web Client. The Hosts And Clusters view is where you manage ESXi hosts, clusters, and VMs. You already understand hosts and VMs; and we'll discuss clusters in the section “Creating and Managing a vCenter Server Inventory,” later in this chapter. To see the rest of what vCenter Server has to offer, click the house icon on the top of the browser next to the VMware vSphere Web Client name.

As shown in Figure 3.19, the interface is divided into five main areas and a search bar appears in the upper-right corner.

• Navigator (1) The leftmost column is used for showing inventory and for navigation. It is the primary item selection tool.
• Content Area (2) Once an item is selected, the larger middle column shows the content or configuration options for that item.
• Alarms and Work In Progress (3) On the right is a column that brings potential problems to your attention and also shows any current wizards that are in progress but put to the side for completion at a later time.
• Recent Tasks (4) The Recent Tasks bar shows anything that is currently or has recently occurred within vCenter. Recent Tasks can be swapped between My Tasks and All Users.
• Recent Objects (5) The Recent Objects bar shows the last 10 objects that you have recently viewed or created within vCenter. The Recent Viewed Objects can be swapped with Recent Created Objects by clicking on the opposite tab.

The home screen lists all the various features that the vSphere Web Client has to offer within the content area in managing ESXi hosts and VMs:

• Under Inventories, the Web Client offers several views, including Hosts And Clusters, VMs And Templates, Storage, Networking, Content Library, and Global Inventory Lists.
• Under Operations And Policies, the Web Client has screens for viewing tasks, events, host profiles, storage service classes, and customization specifications.
• Under Administration are areas for managing roles, configuring the system, and licensing.
• Under Plug-ins For Installation, the Web Client has screens to access Hybrid Cloud and vRealize Orchestrator.

Many of these features are explored in other areas of the book. For example, networking is discussed in Chapter 5, and storage is discussed in Chapter 6. Chapter 10 discusses templates and customization specifications, and Chapter 8 discusses roles and permissions. Under Administration, you'll also see a link to vCenter Operations Manager, which is outlined in Chapter 13. A large portion of the rest of this chapter is spent just on vCenter Server's inventory views.

From the home screen, you can click any of the icons to navigate to the corresponding area. There may or may not be additional icons here, depending on the plug-ins you have installed. The vSphere Web Client also has another way to navigate quickly and easily, and that's called the navigator.

Using the Navigator

The left-hand column of the vSphere Web Client is the navigator. As stated on the Getting Started tab, the navigator is an “aggregated view of all objects in the inventory.” The top of the navigator shows you exactly where you are in the various screens that vCenter Server provides and also displays a chronological history so you can jump back to a prior screen.

If you click any item in the navigation bar with an arrow next to it, the menu changes and displays just the subitems of the selected item. When you click an item without the arrow, the Navigator menu doesn't change, but it does change the content area. A key point about the vSphere Web Client and vCenter Server is that many of the menu options and tabs that appear within the application are context sensitive, meaning they change depending on what object is selected or active. You'll learn more about this topic throughout the chapter.

Now that you understand how to navigate using the vSphere Web Client, you're ready to start creating and managing the vCenter Server inventory.

Understanding Inventory Views and Objects

Every vCenter Server has one or more root objects; these are datacenter objects, which serve as a container for all other objects. Prior to adding an object to the vCenter Server inventory, you must create at least one datacenter object (you can have multiple datacenter objects in a single vCenter Server instance). The objects found within the datacenter object depend on which inventory view is active. The navigator provides a quick and easy reminder of which inventory view is currently active by displaying the four main inventory trees as tabs at the top. In the Hosts And Clusters view, you'll work with ESXi hosts, clusters, resource pools, and VMs. In the VMs And Templates view, you'll work with folders, VMs, and templates. In the Storage view, you'll work with datastores and datastore clusters; in the Networking view, you'll work with vSphere Standard Switches and vSphere Distributed Switches.

You organize the vCenter Server inventory differently in different views. The Hosts And Clusters view is primarily used to determine or control where a VM is executing or how resources are allocated to a VM or group of VMs. You would not, typically, create your logical administrative structure in the Hosts And Clusters inventory view. This would be a good place, though, to provide structure for resource allocation or to group hosts into clusters according to business rules or other guidelines.

In VMs And Templates view, though, you can place VMs and templates within folders irrespective of the specific host on which that VM is running. Thus you can create a logical structure for VM administration that remains, for the most part, independent of the physical infrastructure on which those VMs are running. There is one very important tie between the VMs And Templates view and the Hosts And Clusters view: datacenter objects are shared between them. Datacenter objects span both the Hosts And Clusters view and the VMs And Templates view.

The naming strategy you provide for the objects in vCenter Server should complement existing datacenter design and management. For example, if you have qualified IT staff at each of your three datacenters across the country, you would most likely create a hierarchical inventory that mirrors that management style. If your IT management was set by the various departments in your company, the datacenter objects might be named after each respective department. In most enterprise environments, the vCenter Server inventory will be a hybrid that involves management by geography, department, server type, and even project title.

The vCenter Server inventory can be structured as needed to support a company's IT management needs. Folders can be created above and below the datacenter object to provide higher or more granular levels of control that can propagate to lower-level child objects. In Chapter 8, we'll discuss the details of vCenter Server permissions and how you can use them in a vCenter Server hierarchy. Figure 3.20 shows a Hosts And Clusters view of a vCenter Server inventory that is based on a geographical management style.

If a company uses more of a departmental approach to IT resource management, the vCenter Server inventory can be shifted to match that management style. Figure 3.21 reflects a Hosts And Clusters inventory view based on a departmental management style.

In most enterprise environments, the vCenter Server inventory will be a hybrid of the different topologies. Perhaps one topology might be a geographical top level, followed by departmental management, followed by project-based resource configuration.

Folders can be used to organize all different object types within vCenter Server. Figure 3.22 shows how you can create folders designated for the various objects, such as hosts and clusters or VMs and templates.

These inventory views are mostly separate and independent, although as we pointed out earlier, they do share datacenter objects. For example, the Hosts And Clusters view may reflect a physical or geographical focus, whereas the VMs And Templates view may reflect a departmental or functional focus. Because permissions are granted based on these structures, organizations can build inventory structures that properly support their administrative structures. Chapter 8 will describe the security model of vCenter Server that will work hand in hand with the management-driven inventory design.

With that basic understanding of vCenter Server inventory views and the hierarchy of inventory objects behind you, it's time for you to build your inventory structure and start creating and adding objects in vCenter Server.

Creating and Adding Inventory Objects

Before you can build your inventory—in either Hosts And Clusters view or VMs And Templates view—you must get your ESXi hosts into vCenter Server. And before you can get your ESXi hosts into vCenter Server, you need to have a datacenter object.

Understanding Basic Host Management

A great deal of the day-to-day management tasks for ESXi hosts in vCenter Server occur in the Hosts And Clusters view. From this area, the context (right-click) menu for an ESXi host shows some of the options available. This menu has changed from the previous versions of the vSphere Web Client; it is now more closely aligned to the menus that exist within the deprecated vSphere Desktop Client and Host Client, as shown in Figure 3.24.

The majority of these options are described in later chapters. Chapter 9 describes creating VMs, and Chapter 11 discusses resource pools. Chapter 8 covers permissions, and Chapter 13 discusses alarms and reports. The remaining actions—shutting down, rebooting, powering on, standing by, disconnecting, and removing from vCenter Server—are self-explanatory.

Additional commands may appear on this context menu as extensions or are installed into vCenter Server depending on the ESXi host's configuration. For example, after you install vSphere Update Manager, several new commands appear on the context menu for an ESXi host. ESXi hosts in a cluster enabled for vSphere HA would have additional options. You'll learn more about vSphere HA in Chapter 7.

In addition to the context menu, the tabs across the middle content area of the vSphere Web Client also provide some host-management features. Figure 3.25 shows some of the tabs.

Within each of these tabs are subsections that further divide the settings into appropriate areas. For the most part, these tabs correspond closely to the commands on the context menu. Here are the tabs and subsections that are displayed when a host is selected in the inventory view, along with a brief description of what each does:

• Summary The Summary tab gathers and displays information about the underlying physical hardware, the storage devices that are configured and accessible, the networks that are configured and accessible, and the status of certain features such as vMotion, vSphere FT, and Host Profiles. The content within this tab is somewhat configurable. You can drag the different boxes around, change their size, and expand categories to reveal more information. There are no subsections of the Summary tab, but it does provide links to commonly performed host- management tasks.
• Monitor The Monitor tab displays all the monitoring information available about the selected host and breaks it down into a number of subsections.
  • Issues The Issues subsection lists any current configuration problems with the selected host; this could be any number of things, from a cluster configuration to a network issue. The triggered alarms area relates to alarms on this host that have not been acknowledged or reset.
  • Performance The Performance subsection displays performance information for the host, such as overall CPU utilization, memory utilization, disk I/O, and network throughput. We'll discuss this area in more detail in Chapter 13.
  • Tasks All tasks related to the selected host are displayed here. The Tasks subsection shows all tasks, the target object, which account initiated the task, which vCenter Server was involved, and the result of the task.
  • Events Similar to the Tasks subsection, the Events subsection lists all events related to the selected host, such as a triggered alarm. If a host is using almost its entire RAM or if a host's CPU utilization is very high, you may see some triggered alarms.
  • Scheduled Tasks The scheduled tasks subsection lists any pending tasks that you may have scheduled, while also letting you set up a scheduled job of creating a new virtual machine.
  • Hardware Status The Hardware Status subsection displays sensor information on hardware components such as fans, CPU temperature, power supplies, network interface cards (NICs) and NIC firmware, and more.
• Configure The Configure tab is where you will make configuration changes to the host. Tasks such as configuring storage, configuring the network, changing security settings, configuring hardware, and so forth are all performed here.
• Permissions The Permissions tab displays all of the permissions that may have been established above the ESXi host—at the cluster, datacenter, or vCenter level—and allows you to add permissions directly on the ESXi host. Keep in mind that any permissions added to the ESXi from vCenter Server do not propagate to the ESXi host's local permissions store.
• VMs The VMs tab displays all of the virtual machines and templates that currently reside on the ESXi host, giving you quick insight into the specifications of the virtual machines such as their power state, their resource allocation, and their vSphere HA status. You can add additional columns that can provide more details across the VMs and templates.
• Datastores The Datastores tab displays all the mounted datastores available on the selected host and information about each, such as the type—NFS, VMFS 5, VMFS 6, Virtual SAN (vSAN), or Virtual Volume (VVOL)—overall capacity, free space, and whether or not the datastore is in a datastore cluster. As with other sections, you can add columns that provide more details across the different datastores.
• Networks The Networks tab displays all the networking information available about the selected host and breaks it down into two subsections: Networks and Distributed Switches. The Networks subsection lists all of the port groups associated with the selected host, displaying information such as the port group types, how many virtual machines reside on which port group, and how many hosts have access to the port group. The other subsection, Distributed Switches, gives you a cursory look at any Distributed Virtual Switches that are associated with the selected host; this will give you information such as the DVS's version, the version of Net IO Control, and what vCenter Server owns the DVS.
• Update Manager The Update Manager tab, often referred to as the Update Manager Compliance view, is where you will coordinate updates and patches to the selected host, which includes managing the baselines, managing the compliance against said baselines along with staging patches, and scheduling remediation operations. We'll discuss this area in more detail in Chapter 4.

Before showing you some of vCenter Server's other management features, we want to walk you through the Manage tab in detail. This is where you'll perform almost all of the ESXi host-configuration tasks and where you're likely to spend a fair amount of time, at least in the beginning.

Examining Basic Host Configuration

You've already seen the Configuration tab of an ESXi host, when in Chapter 2 you learned how to configure Network Time Protocol (NTP) time synchronization. We'll spend a bit more time on it; however, in the Web Client, the System subsection is under the Configure tab, along with others. You'll be visiting this area quite often throughout this book. In Chapter 5, you'll use the Configure tab for networking configuration, and in Chapter 6, you'll use the Configure tab for storage configuration.

CONFIGURE TAB

Figure 3.26 shows the commands available on the Configure tab for an ESXi host that has just been added to vCenter Server.

There are a lot of options here, so let's quickly run through them and provide a brief explanation of each. Let's start by going from top to bottom.

• Storage Subsection The following areas are available in the Storage subsection of the Configure tab:
  • Storage Adapters This area provides information on the various storage adapters installed in the ESXi host as well as information on storage resources connected to those adapters.
  • Storage Devices The Storage Devices area shows storage LUN and device mapping along with their relative paths to the host. Devices in here generally have a datastore on top of them that can be viewed in the Storage view. This is more of a logical view of storage, whereas the Storage Adapters area described earlier is more physical in nature.
  • Host Cache Configuration The Host Cache Configuration area displays how the host's Flash-based datastores are configured. You are able to see what space is reserved for Host Cache and how much space is available on a per-host level.
  • Protocol Endpoints The Protocol Endpoints area directly relates to the endpoints that this host can see with the Virtual Volume (VVOL) storage configuration. VVOLs are explained in detail in Chapter 6.
  • I/O Filters The I/O Filters area directly relates to the storage filters that this host has been configured with. By default, you should see spm and vmwarevmcrypt, which are for VMware's default Storage Policies and VM Encryption, respectively. We'll talk more about VM Encryption in Chapter 8, and talk about Storage Policies and I/O Filters are explained in detail in Chapter 6.
• Networking Subsection The following areas are available in the Networking subsection of the Configure tab:
  • Virtual Switches In Chapter 5, we'll explore the functionality found in this area. You'll configure network connectivity to both standard and distributed virtual switches here and in the Network view.
  • Virtual Adapters The Virtual Adapters area is where you can configure different VMkernel network interfaces to the ESXi host to use for Management, vMotion, and Fault Tolerance, for example.
  • Physical Adapters The Network Adapters area provides read-only information on the network adapters that are installed in the selected ESXi host. It also allows you to add networking to the ESXi host along with changing the network speed of any network adapter. We'll talk more about the Physical Adapters section in Chapter 5.
  • TCP/IP Configuration In this area, you can view and change the DNS and routing configuration for the selected ESXi host.
  • Advanced In this area, you can view advanced options such as IPv6 configuration.
• Virtual Machines Subsection The following areas are available in the Virtual Machines subsection of the Configure tab:
  • VM Startup/Shutdown If you want VMs to start up or shut down automatically with the ESXi host, you configure those settings in this area. You can also define the startup order of VMs that are set to power on with the host.
  • Agent VM Settings Agent VMs add specific supporting functionality to the virtual environment. Although they are VMs, they are considered part of the infrastructure and should be started before all others. For example, NSX Edge Gateway uses agent VMs to help supply its functionality.
  • Swap File Location This area is where you'll configure the location of the swap files for running VMs on the host. By default, the swap file is stored in the same directory as the VM itself. When an ESXi host is in a cluster, the cluster setting overrides the per-host configuration.
  • Default VM Compatibility When a VM is created, it is created with a specific VM hardware version. Each VM hardware version has a certain level of features available to it based on the version of the vSphere host, and with each new revision of vSphere, new VM hardware versions are introduced and new features are added. This may cause backward-compatibility issues when you want to migrate VMs with newer VM hardware versions from a newer environment to an older one. You'll learn more about VM compatibility in Chapter 9; for now, just know that this is the area where you can set the default level when a VM is created.
• System Subsection The following areas are available in the System subsection of the Configure tab:
  • Licensing This area allows you to view the currently licensed features as well as assign or change the license for the selected ESXi host.
  • Time Configuration From here, you can configure time synchronization via NTP for the selected ESXi host. You saw this area within the vSphere Client in Chapter 2.
  • Authentication Services This area allows you to configure how ESXi hosts authenticate users; we'll discuss it in more detail in Chapter 8.
  • Certificate SSL certificates are managed by the PSC but can be updated on a per-host basis from this area. More details about the PSC Certificate Authority can be found in Chapter 8.
  • Power Management If you want to use Distributed Power Management (DPM), you'll need to configure the ESXi hosts appropriately. This area is where that configuration occurs.
  • Advanced System Settings The Advanced System Settings area provides direct access to detailed configuration settings on the selected ESXi host. In the majority of instances, this is not an area you'll visit on a regular basis, but it is helpful to know where it is in the event you need to change a setting.
  • System Resource Allocation The System Resource Allocation area allows you to fine-tune the resource allocation for the selected ESXi host.
  • Security Profile This area allows you to configure which daemons (services) should run on the host.
  • System Swap In this area, you can disable or specify which datastore should be used for host swap files. We'll explain host swapping and how it differs from VM swapping in Chapter 11.
  • Host Profile Although there is a Host Profiles area accessible from the home screen, this area lets you attach a host profile as well. See the section “Working with Host Profiles,” later in this chapter.
• Hardware and Virtual Flash Subsections The following areas are available in the Hardware and Virtual Flash subsections of the Configure tab:
  • Processors In this area, vCenter Server provides details about the processors in the selected ESXi host as well as the ability to enable or disable hyperthreading on that ESXi host.
  • Memory This area shows you the amount of memory installed in an ESXi. It only provides information about the memory in the host, how much is allocated to the system (ESXi), and how much is allocated to VMs—there are no options to configure.
  • Graphics Within the Graphics area, you can see what type of GPU is in the system and how much memory it has. In Chapter 9, you'll read about use cases for sharing the GPU of an ESXi host to the guest VMs in certain circumstances.
  • PCI Devices The PCI Devices area allows you to mark available devices on the ESXi host that can then be allocated to one of the virtual machines in the host's inventory. This allows for the virtual machines to directly access the physical device on the host.
  • Power Management The Power Management area in the Hardware subsection differs from the area under the System subsection above it. This area allows you to set various power-management policies on the selected ESXi host.
  • Virtual Flash Resource Management Solid State Drive (SSD)–backed datastores can be allocated to the flash resource type in this area. You can then further allocate this resource in the Cache Configuration described next.
  • Virtual Flash Host Swap Cache Configuration This area allows you to specify or view the amount of space on Solid State Drive (SSD)–backed datastores (or flash) that can be used for swapping. Swapping to SSD as opposed to traditional disks is much faster, and this area allows you to control which SSD-backed datastores may be used for swapping.

As you can see, vCenter Server provides all the tools that most administrators will need to manage ESXi hosts. Although these host-management tools are visible in the Hosts And Clusters view, several of vCenter Server's other management features are found in the multiple views.

Using Scheduled Tasks

Earlier in this chapter, you learned how the vSphere Web Client often displayed the UI depending on the context of the item selected. Scheduled Tasks is a feature that's available from many areas, including vCenter.

From the Navigator, select Manage Scheduled Tasks to display the Scheduled Tasks area of vCenter Server.

Here, you can create jobs to run based on a defined logic. You can schedule the following list of tasks:

• Change the power state of a VM.
• Clone a VM.
• Deploy a VM from a template.
• Move a VM with vMotion.
• Move a VM's virtual disks with Storage vMotion.
• Create a VM.
• Make a snapshot of a VM.
• Add a host.
• Change the power settings for a cluster.
• Change resource settings for a resource pool or VM.
• Check compliance for a profile.

As you can see, vCenter Server supports quite a list of tasks you can schedule to run automatically. Because the information required for each scheduled task varies, the wizards are different for each of the tasks. Let's take a look at one task that you might find quite useful to schedule: adding a host.

Why might you want to schedule a task to add a host? Perhaps you know that you'll be adding a host to vCenter Server but you want to add it after hours. You can schedule a task to add the host to vCenter Server at a later time, although keep in mind that the host must be reachable and responding when the task is created.

Follow these steps to create a scheduled task to add a host to vCenter Server:

1. Launch the vSphere Web Client, if it is not already running, and connect to a vCenter Server instance.
2. After you connect to vCenter Server, navigate to the Scheduled Tasks area of the Hosts And Clusters view by selecting a cluster and then choosing Manage Scheduled Tasks. This example will also work by selecting a datacenter instead of a cluster.
3. Select Schedule A New Task from within the content area.
4. From the list of tasks to schedule, select Add Host.

   The Add Host Wizard starts.

5. Supply the hostname, username, and password to connect to the host, just as if you were adding the host manually.
6. When prompted to accept the host's SHA1 fingerprint, click Yes.
7. The next four steps in the wizard are the same as adding the host manually. Click Next after each step until you come to the point of scheduling the task.
8. Supply a task name and task description, and click the Change button. The Configure Scheduler pop-up is fairly self-explanatory, but you can run the task now, after startup, or at a later time of your choosing. There's also an option for setting a recurring schedule, but for adding a host, the recurring option doesn't make sense. Click OK once your scheduler is configured.
9. Specify that you want to receive email notification of the scheduled task when it completes by supplying an email address. Note that vCenter Server must be configured with the name of an SMTP server it can use.

Scheduling the addition of an ESXi host is of fairly limited value. However, the ability to schedule tasks such as powering off a group of VMs, moving their virtual disks to a new datastore, and then powering them back on again is quite useful.

Using the Events and Events Consoles in vCenter Server

The consoles for Tasks and Events in vCenter Server bring together all the events and tasks that have been logged by vCenter Server. Figure 3.27 shows the Events console with an event selected.

You can view the details of an event by simply clicking it in the list. Any text highlighted in blue is a link; clicking that text will take you to that object in vCenter Server. You can search through the events using the search box in the upper-right corner of the vSphere Web Client content window. Right below the event list is a button that you can click to export the events to a text file. Figure 3.28 shows the dialog box for exporting events.

Working with Host Profiles

Host profiles are a powerful feature of vCenter Server. As you'll see in upcoming chapters, a bit of configuration is involved in setting up an ESXi host. Although vCenter Server and the vSphere Web Client make it easy to perform these configuration tasks, it's easy to overlook something. Additionally, making all these changes manually for multiple hosts can be time consuming and even more error prone. That's where host profiles can help.

A host profile is essentially a collection of all the various configuration settings for an ESXi host. This includes settings such as NIC assignments, virtual switches, storage configuration, date and time, and more. By attaching a host profile to an ESXi host, you can compare the compliance of that host with the settings outlined in the host profile. If the host is compliant, you know its settings are the same as the settings in the host profile. If the host is not compliant, you can enforce the settings in the host profile to make it compliant. This provides you with a way not only to verify consistent settings across ESXi hosts but also to quickly and easily apply settings to new ESXi hosts.

To work with host profiles, click the Home button and then click Host Profiles. Figure 3.29 shows the Host Profiles view in vCenter Server, where a host profile has been created but not yet attached to any hosts.

As you can see in Figure 3.29, the toolbar contains a number of buttons. These buttons allow you to perform the following tasks:

• Extract a profile from a host.
• Import a host profile.
• Duplicate a host profile.
• Copy settings from a host.
• Check the host profile compliance.
• Attach/detach host profiles from hosts or clusters.
• Remediate a host based on its host profile.

To create a new profile, you must either create one from an existing host or import a profile that was already created somewhere else. Creating a new profile from an existing host requires only that you select the reference host for the new profile. vCenter Server will then compile the host profile based on that host's configuration.

After you create a profile, you can edit the profile to fine-tune the settings contained in it. For example, you might need to change the IP addresses of the DNS servers found in the profile because they've changed since the profile was created.

Follow these steps to edit the DNS server settings in a host profile:

1. If the vSphere Web Client isn't already running, launch it and connect to a vCenter Server instance.
2. On the home screen, select Host Profiles.
3. Right-click the host profile to be edited, and select Edit Settings.
4. Click Next to move past the Name And Description page onto Edit Host Profile.
5. From the tree menu on the left side of the Edit Host Profile window, navigate to Networking Configuration ⇒ Netstack Instance ⇒ defaultTcpipStack ⇒ DNS Configuration.

   Figure 3.30 shows this area.

   

6. Change the values shown in the host profile.
7. Click Next and then click Finish to save the changes to the host profile.

Although this procedure describes only how to change DNS settings, the steps for changing other settings within a host profile are similar. This allows you to quickly create a host profile based on a reference host and then customize the host profile until it represents the correct “golden configuration” for your hosts.

Host profiles don't do anything until they are attached to ESXi hosts. Click the Attach/Detach A Host Profile To Hosts And Clusters button just below the Objects tab in the vSphere Web Client to open a dialog box that allows you to select one or more ESXi hosts to which the host profile should be attached.

After a host profile has been attached to an ESXi host, checking for compliance is as easy as right-clicking that host on the Hosts And Clusters tab and selecting Host Profile Check Compliance from the context menu.

If an ESXi host is found noncompliant with the settings in a host profile, you can then place the host in Maintenance mode and apply the host profile. When you apply the host profile, the settings found in the host profile are enforced on that ESXi host to bring it into compliance. Note that some settings require a reboot to take effect.

To truly understand the power of host profiles, consider a group of ESXi hosts in a cluster. We haven't discussed clusters yet, but as you'll see elsewhere in the book—especially in Chapter 5 and Chapter 6—ESXi hosts in a cluster need to have consistent settings. Without a host profile, you would have to manually review and configure these settings on each host in the cluster. With a host profile that captures the settings, adding a new host to the cluster is a simple two-step process:

1. Add the host to vCenter Server and to the cluster.
2. Attach the host profile and apply it.

That's it. The host profile will enforce all the settings on this new host that are required to bring it into compliance with the settings on the rest of the servers in the cluster. This approach is a great timesaver for larger organizations that need to quickly deploy new ESXi hosts.

Host profiles are also hugely important when you're using vSphere Auto Deploy to create a stateless environment. In stateless environments using Auto Deploy, configuration settings aren't persistent between reboots. To keep your stateless ESXi hosts properly configured, you'll want to use host profiles to apply the proper settings so that the host retains a consistent configuration over time, even when it's rebooted.

As explained previously, host profiles start to become beneficial when your environment has a large number of ESXi hosts to keep things consistent and manageable. However, host profiles are not the only feature included with vSphere that assists with management; tags are a relatively recent addition to help with these tasks.

Tags and Custom Attributes

Nearly every item within a vCenter inventory can have a label and metadata added to it by way of tags or custom attributes. Tags let you group related items together using categories, and they help sort and manage your vCenter objects. Tags can be both exclusive and inclusive, which gives you great flexibility when you design your metadata structure. They also can extend outside the confines of a single vCenter Server; if multiple vCenter Servers are configured in enhanced linked mode the tags and categories you create will be accessible and searchable across all of their inventories. We'll explain how this might be useful with an example. Say that you want to know which VMs belong to the engineering team, as well as which VMs are production, test, or development. In the section “Understanding Inventory Views and Objects,” earlier in this chapter, you saw how to use folders to organize objects for management and security. The problem with folders is that a VM can reside in only one folder, and a folder can only exist within a single vCenter Server; taking this example, you cannot put a VM in both the Engineering folder and the Production folder. With tags, this problem is solved. Although you can specify that only a single tag can be applied to a certain object at any one time, you can also specify multiple tags against a single object.

Using tags to build metadata around your ESXi hosts, VMs, and other objects is quite powerful, and the integration with the vSphere Web Client's search functionality makes large inventories much more manageable. As your environment grows, and your engineering team begins deploying more virtual machines across multiple vCenter Servers, object tracking can quickly become a tedious task. With the potential of VMs, Templates, hosts of varying hardware, and a myriad of other items spread across multiple clusters and multiple vCenter Servers, leveraging the shared tags and categories quickly enables you to search out logical relationships, allowing you to quantify and locate specific objects.

Custom Attributes provide a similar role within your vCenter inventory.

We'll now show you how to create some tags and how they can be used. Each tag must belong to a category (and only a single category), and because of this requirement, you must create a category before or at the same time you create any tags. Here are the steps:

1. If the vSphere Web Client isn't already running, launch it and connect to a vCenter Server instance.
2. From the home screen within the navigator, select Tags & Custom Attributes.
3. From the Tags tab, click the New Tag icon to open the New Tag dialog box.
4. Enter the name of the tag and a description.
5. Change the category to New Category, and the window will expand to show more fields.
6. Give the Category a name and a description.
7. Decide whether this category should allow a single tag or multiple tags per object, and then select what object type(s) are associated with this category, as shown in Figure 3.31.

   

8. Click OK to save the new tag and category.

Tags let you define custom identification or information options for nearly every object type within vCenter, including the following:

• Clusters
• Datacenters
• Datastores
• Distributed switches
• Folders
• Hosts
• Networks
• Resource pools
• vApps
• Virtual machines

After you create this tag, you can attach the tag to an object. After the tag is added, it appears in the Tags section of the content area Summary tab. You can use the Assign Tag option in the right-click menu to add tags to various objects, as shown in Figure 3.32.

With the tags clearly defined for various objects, you can then search based on that data. Figure 3.33 shows a custom search for all objects whose tag contains the text Production, Engineering, and Windows.

At this point, you have installed vCenter Server, added at least one ESXi host, and explored some of vCenter Server's features for managing settings on ESXi hosts. Now we'll cover how to manage some of the settings for vCenter Server itself.

General vCenter Server Settings

The General vCenter Server Settings area contains 10 vCenter Server settings:

• Statistics
• Database
• Runtime Settings
• User Directory
• Mail
• SNMP Receivers
• Ports
• Timeout Settings
• Logging Settings
• SSL Settings

When you have vCenter Server instances running in a linked mode group, be sure to select the correct vCenter Server instance within the navigator.

Each of these settings controls a specific area of interaction or operation for vCenter Server, which we briefly discuss next:

• Statistics On the Statistics page, shown in Figure 3.34, you can configure the collection intervals and the system resources for accumulating statistical performance data in vCenter Server. In addition, it provides a database-sizing calculator that can estimate the size of a vCenter Server database based on the configuration of statistics intervals. By default, the following four collection intervals are available.

  

  • Past day: 5 minutes per sample at statistics level 1
  • Past week: 30 minutes per sample at statistics level 1
  • Past month: 2 hours per sample at statistics level 1
  • Past year: 1 day per sample at statistics level 1

  By selecting an interval and clicking the drop-down list, you can customize the interval configuration. You can set the interval, how long to keep the sample, and what statistics level (level 1 through level 4) vCenter Server will use.

  Four Statistics Collection levels are defined in the user interface:

  • Level 1 Has the basic metrics for average usage of CPU, memory, disk, and network. It also includes data about system uptime, system heartbeat, and DRS metrics. Statistics for devices are not included.
  • Level 2 Includes all the average, summation, and rollup metrics for CPU, memory, disk, and network. It also includes system uptime, system heartbeat, and DRS metrics. Maximum and minimum rollup types as well as statistics for devices are not included.
  • Level 3 Includes all metrics for all counter groups, including devices, except for minimum and maximum rollups.
  • Level 4 Includes all metrics that vCenter Server supports.

• Runtime Settings The Runtime Settings area lets you configure the vCenter Server unique ID, the IP address used by vCenter Server, and the server name of the computer running vCenter Server. The unique ID will be populated by default, and changing it requires a restart of the vCenter Server service. These settings would normally require changing only when running multiple vCenter Server instances in the same environment.
• Database The Database page lets you configure the maximum number of connections to the backend database. To limit the growth of the vCenter Server database, you can configure a retention policy. vCenter Server offers options for limiting the length of time that both tasks and events are retained in the backend database.
• User Directory On this page you can set the user directory (usually Active Directory) time-out value, a limit for the number of users and groups returned in a query against the user directory database, and the validation period (in minutes) for synchronizing users and groups used by vCenter Server.
• Mail The Mail page might be the most commonly customized page because its configuration is crucial to the sending of alarm results, as you'll see in Chapter 13. The mail SMTP server name or IP address and the sender account will determine the server and the account from which alarm results will be sent.
• SNMP Receivers The SNMP Receivers configuration page is where you would configure vCenter Server for integration with a Systems Network Management Protocol (SNMP) management system. The receiver URL should be the name or IP address of the server with the appropriate SNMP trap receiver. The SNMP port, if not configured away from the default, should be set at 162, and the community string should be configured appropriately (Public is the default). vCenter Server supports up to four receiver URLs.
• Ports The Ports page is used to configure the HTTP and HTTPS ports used by vCenter Server.
• Timeout Settings This area, the Timeout Settings area, is where you configure client connection time-outs. The settings by default allow for a 30-second time-out for normal operations or 120 seconds for long operations.
• Logging Settings

  The Logging Settings area customizes the level of detail accumulated in vCenter Server logs. The logging options include the following:

  • None (Disable Logging)
  • Errors (Errors Only)
  • Warning (Errors And Warnings)
  • Information (Normal Logging)
  • Verbose (Verbose)
  • Trivia (Trivia)

  By default, the Windows-based vCenter Server stores its logs at C:ProgramDataVMwareVMware VirtualCenterLogs (on Windows Server 2008 R2, Windows Server 2012 and later) while the Linux-based vCenter Server virtual appliance stores its logs at /var/log/vmware.

• SSL Settings On this page, you can configure a certificate validity check between vCenter Server and the vSphere Client. If enabled, both systems will check the trust of the SSL certificate presented by the remote host when performing tasks such as adding a host to inventory or establishing a remote console to a VM. You'll learn more about SSL certificates in Chapter 8.

Licensing

The Licensing configuration area of the vCenter Server Settings dialog box, shown in Figure 3.35, provides the parameters for how this specific vCenter Server instance is licensed. The options include using an evaluation mode or assigning a license key to this instance of vCenter Server.

When an evaluation of vSphere and vCenter Server is no longer required and the appropriate licenses have been purchased, you must deselect the evaluation option and add a license key. Evaluation licenses are only valid for 60 days after installation.

Message of the Day

As the name suggests, you can edit the message of the day (MOTD) from this area. The MOTD is displayed to users each time they log into vCenter Server. This provides an excellent means of distributing information regarding maintenance schedules or other important information.

Advanced Settings

The Advanced Settings area provides for an extensible configuration interface. These settings should be changed only under specific circumstances, usually at VMware's direction.

Auto Deploy

We'll take you through Auto Deploy as another method of rapidly deploying and configuring ESXi hosts in Chapter 4, but for now, just know that this area provides access to some of the underlying components necessary for configuring this service, including iPXE boot loader, a keystone to the image streaming process.

vCenter HA

Touched on earlier in the chapter, the vCenter HA configuration area is where you'll setup and maintain a highly available configuration of your Linux-based vCenter Server virtual appliance. In its out-of-the-box form, you'll simply see a splash page, but we'll take you through vCenter HA more in-depth in Chapter 7.

Key Management Servers

We'll touch on this more in in Chapter 8, but for now, just know that the Key Management Servers area allows you to establish a trust between the vCenter Server and the local key management server (KMS). This is a prerequisite if you ever plan on enabling encryption in your virtual infrastructure in order to provide an extra level of security within the environment.

Storage Providers

The Storage Providers area provides insight into the existing storage entities and their capabilities within your environment, including external physical storage and abstracted storage, such as VMware Virtual SAN (vSAN) or Virtual Volumes (VVols), leveraging the vSphere APIs for Storage Awareness (VASA). This can be a powerful component within your environment, allowing vCenter Server and its ESXi hosts to obtain information about your storage configuration, its status, and storage data services offered, which enables you to make more informed decisions about workload placement.

We'll talk more about Storage Providers and Storage Policy-Based Management (SPBM) in Chapter 6.

Roles

The Roles option from the Administration menu is available only when the view is set to Administration and the Roles tab is selected. This menu works like a context menu where you can add, edit, rename, or remove roles based on what object is selected. Although you set up the roles and accounts within this area, you apply those roles for permissions against vCenter objects within the various inventory views. Chapter 8 describes vCenter Server's roles in detail.

Licensing

In the previous section, you saw how to go about setting a license for a specific vCenter Server through the inventories vCenter view. There are also licensing options when you select individual hosts in the Hosts And Clusters view. However, the Licensing area of the vSphere Web Client home screen gives you a broad view of all your licenses within the environment and indicates to which component those licenses are allocated.

Within Licensing, you can also report on your license usage over time and export this data. Depending on how complex your environment and license agreement is with VMware, you will seldom use this area, or only dedicated licensing staff will look at this section. Standard (Perpetual) licenses or VMware Service Provider Program (VSPP) licensing agreements are all managed through the overall licensing area.

vCenter Solutions Manager

As extensions—such as vSphere Update Manager or vSphere Auto Deploy—are added to vCenter Server, additional icons, tabs, and features may appear throughout the vSphere Web Client. The extensions themselves that enable these new features are managed through this vCenter Solutions Manager area.

Chapter 4 discusses one such extension to vCenter Server: vSphere Update Manager.

System Configuration

The System Configuration feature falls under the Administration banner on the vSphere Web Client home screen, and just like the Licensing section, this feature gives you an aerial view of all vCenter Servers and Platform Services Controller within your environment. In the earlier sections “Understanding Basic Host Management” and “Understanding Inventory Views and Objects,” you learned to interact with and address the different objects' services and settings within the management domain of vCenter Server, such as ESXi hosts, clusters, or data centers; however, although we touched upon some of the Advanced Settings you can configure on vCenter, you may have noticed we are missing actual visibility into the vCenter Server's and Platform Services Controller's services, health, and domain. While there is some overlap with what is available in the VMware Appliance Management Interface (VAMI), System Configuration allows for you to see all vCenter Servers and Platform Services Controllers deployed in the same vSphere domain in one place. This area allows you to do the following:

• View and browse all nodes in a vSphere domain, quickly observing their aggregate health at either the Node or Services level.
• Monitor the networking, storage, and performance (memory and CPU usages) of each node.
• Manage settings such as SSH or DCUI access, change networking settings, and add Firewall rules.
• Check the health of individual services that belong to a specific node.
• Manage the startup type as well as the start, stop, and restart of individual services.
• Manage service-specific settings of individual services, such as Content Library, vSphere Authentication Proxy, or vSphere Update Manager.
• Export the logs from vCenter Server or Platform Services Controller.

When you select System Configuration from the Administration section on the home screen, you can observe the overall health for all nodes and services within your vSphere domain, as shown in Figure 3.36.

Perform the following tasks to export system logs out of vCenter Server and Platform Services Controller:

1. With the vSphere Web Client running and connected to a vCenter Server instance, on the home screen, select System Configuration.
2. In the Navigator pane, select Nodes, and let the pane load your Platform Services Controller and vCenter Server.
3. Right-click on your Platform Services Controller, and select Export Support Bundles.
4. Select the log(s) you want to export. By default, neither of the bundles is selected, so go ahead and select both. Use the drop-down menu to select a specific, desired log if needed.
5. Click the Export Support Bundle button.
6. A new browser window will appear where you can specify a local path in which to save the logs. Allow for the export to finish.

In the location you selected, the Platform Services Controller will download VMware-vCenter-Support-<Date>@<Time>.zip, which contains another compressed file: <Hostname>-supportbundle<date>@<time>.tgz. If you decompress both files, you'll find the system logs for the Platform Services Controller system. Figure 3.37 shows some log files exported from the Platform Services Controller.

We'll continue to explore vCenter Server's functionality in the coming chapters. Chapter 4 explores the functionality added to vCenter Server by the vSphere Update Manager extension.

Summary

The Summary screen is the first part of the VAMI you'll see. It contains two main areas for the vCenter Server with External Platform Services Controller, and three main areas for vCenter Servers with Embedded Platform Services Controllers and External Platform Services Controllers.

For a vCenter Server with External Platform Services Controllers, the two main areas are

• An upper section detailing the Host OS's Hostname, Type (in Figure 3.38, ‘it's vCenter Server with an external Platform Services Controller), the Version, and the Build Number of the system.
• A lower section that provides a high-level overview of the health status of the Host OS's virtual hardware, which includes CPU, Memory, Database (only available on your vCenter Server with an external or embedded Platform Services Controller), Storage, and Swap, which all bubble up into Overall Health.

For a vCenter Server with Embedded Platform Services Controllers or External Platform Services Controllers, you'll see a new section that covers the Single Sign-On Status for the node, giving you the domain name and whether the SSO-related services discussed earlier in this chapter are running. The other two sections, as shown in Figure 3.39, are nearly identical with the following exceptions in the upper section:

• The Node Type will reflect whether it's an External Platform Services Controller or a vCenter Server with an Embedded Platform Services Controller.
• The bottom health section lacks a Database monitor for External PSCs as they do not come with a database.

We'll discuss accessing more of the health monitoring details in the next couple of sections.

Monitor

In the previous section, you were given a high-level view of the vCenter Server virtual appliance's Host OS health, but with the Monitor area, you can drill down into these individual components' health. In the middle pane, you'll see four distinct items: CPU & Memory, Disks, Network, and Database. Again, the Database monitor is only available on a vCenter Server with an external or embedded Platform Services Controller.

• CPU & Memory The CPU & Memory page allows you to report on your CPU and Memory usage over time. The drop-down menus include the following options for increasing windows of time:
  • Last Hour
  • Last Day
  • Last Week
  • Last Month
  • Last Quarter
  • Last Year

  As with other performance charts available within the different vSphere UIs, due to the use of rollup jobs, you lose granularity with the metrics displayed as you go further back in time. For example, the Last Hour option gives you extreme granularity into the CPU and memory activities of the appliance—you can look at the statistics in 5-minute increments. By contrast, the Last Year option provides the least amount of granularity and can only report on the aggregated statistics of the appliance by the day.

• Disks On the Disks page, you can look at the usage across all 13 disks within the appliance. Hovering over the bar graphs under the Utilization column will give you more details on the Used Space and Available Space that aren't readily perceivable from the graph itself.
• Network In the Network area, you can review the inbound and outbound traffic utilization on the appliance over time. In the bottom section, you can choose from a medley of options on the virtual NIC (vNIC) interfaces, which will dictate what's shown in the graph. The options include the following generalized vNIC statistics:
  • Receive Bytes
  • Received Packets
  • Received Errors Detected
  • Received Packets Dropped
  • Transmitted Bytes
  • Transmitted Packets
  • Transmitted Errors Detected
  • Transmitted Packets Dropped

  As previously mentioned, the time period drop-down menu enables you to select a time increment, from last hour up to the last year, with decreased granularity as you increase your time period being monitored.

• Database And finally, on the Monitor page, you are provided visibility into the capacity of the database, split into two graphs:
  • One graph depicts the SEAT (Stats, Events, Alarms, and Tasks) data generated from activities from your virtual infrastructure, which is often referred to as historical data.
  • One graph depicts the overall space of the database, with individual lines for SEAT, Database Logging. and Core statistics.

  As with the CPU & Memory and Network areas, these statistics are graphed over time, and you have the ability to use the drop-down menu to select a time interval between the last hour up to the last year, with decreased granularity as you increase your time period.

Access

In the unlikely event that you need to log into the Appliance—either to view something or when working with your support group to perform troubleshooting—the Access area allows you to manipulate the different methods to logging in. This includes enabling or disabling SSH, the Direct Console User Interface (DCUI), the Console CLI, and Bash Shell.

We'll discuss these different access methods in more detail in Chapter 4.

Networking

On this page, you can set and view the DNS server settings (usually defined during install), the virtual NIC settings (such as MAC address, IP address, subnet mast, default gateway, and whether the NIC is enabled), and Proxy settings used by vCenter Server.

Time

The Time area, as the name implies, allows you to manipulate the time configuration of the appliance. The top section in this area allows you to change the Time Zone on the appliance from its default Coordinated Universal Time (UTC), though we recommend against changing this unless your company policy requires you to do so. The bottom section allows you to update the Time settings, including setting the appliance's time mode to either use NTP or rely on the underlying host's time, as well as managing the Time Servers. The current Time Server will be identical to what was used during the appliance's deployment (covered earlier in this chapter).

Services

The services area is your one-stop shop for reviewing service health as well as which services are started or stopped within your appliances, with the caveat that the service has been integrated with VMware Service Lifecycle Manager—referred to as vMon. vMon serves as the watchdog engine for both the vCenter Server and Platform Services Controller, and monitors the services under its domain. If the service is found to be in a defunct state, vMon will attempt to cycle the service and bring it back into a health state. The Services section plugs directly into vMon, and therefore gives you visibility into the state of these services. What this means is that while all of the vCenter Server's services have been integrated, and thus you can monitor and cycle them within the VAMI, some of the services from the Platform Services Controller—such as the VMware Identity Management Service, Security Token Service, and VMware Directory Service—are not integrated and must be cycled from command line.

You'll notice that most of the services have been configured with the Startup Type of automatic, while some have been set to Manual or Disabled. This indicates the behavior of the services under the domain of vMon:

• Automatic This enables the service to start up on successful boot of the OS, following vMon's instantiation. If the service has been configured with a startup dependency—such as the vCenter Server Service (VPXD) starting after vPostgres or the vSphere Update Manager service (VUM) starting after VPXD—this will be orchestrated by vMon.
• Manual This marks the service as eligible for manual startup from the UI or CLI, but it does not start after boot of the OS and vMon.
• Disabled This marks the service as ineligible for manual startup from the UI and CLI, or after the bootup of the OS or vMon.

It's best not to toggle any of these settings unless explicitly told to do so by product documentation or support as incorrectly modifying one of the services in a chain of dependencies could result in multiple services not starting—often referred to as a catastrophic event. If a service is configured for Disabled or Manual, all dependent items will not automatically start. Oftentimes, the services marked as Manual or Disabled are auxiliary to the core management components of vCenter Server—such as Image Builder or vCenter High Availability—which will be toggled on and off when enabled elsewhere, such as in the vSphere Web Client.

Update

As patches and updates are released for vCenter Server, and, due to their conjoined nature, the Platform Services Controller, the Update page is the area in which you'll stage and install the bundles into the appliance. You are providing two means of updating your appliances:

• Manually downloading the upgrade ISO from MyVMware's Product Patches microsite and mounting them to the individual appliances as a virtual CD-ROM.
• Via a repository that's hosted either by VMware or your own internal web server. By default, the Upgrade framework is set to query the VMware's public repository.

In environments where vCenter Server does not have direct access to the Internet, you'll need to configure the system to either use a proxy or set up an Internet web server to host the upgrade bundles. In an environment where bandwidth is limited, such as a remote or branch office, downloading the upgrade ISO manually and attaching it to each of the components may prove to be the most reliable form of transport.

Administration

The Administration area allows you to change the password for your Root account on the appliance, or any other local account that may have been created. It also lets you set the password requirements for the local account as well as an expiry period.

Remember, the VAMI, like the HTML5 Host Client, does not hook into SSO, so the password policies configured within the vSphere Web Client do not propagate to the VAMI or to the local accounts.

Syslog

Having visibility into the state of your environment both immediately and over time is key, but it just may not be possible based on the number of vCenter Servers and Platform Services Controllers that have been deployed. Further, if you are in an industry where auditing is required for compliance purposes, streaming logs from your environment is key. In the Syslog area, you have the ability to configure log streaming to a remote syslog server to preserve logs as well as vCenter Server events that the environment has generated. While this feature was available in previous versions, with vSphere 6.7, you can now configure up to three forwarders to remote syslog servers. This may prove to be extremely useful if you have discreet syslog servers in your environment that provide different functions, such as a long-term auditing archive for auditors, a security response system monitoring for questionable activity, or a site reliability system keeping a watchful eye on service health. As with the previous version of vSphere, you can configure the log-forwarding protocol using UDP, TCP, TLS (encrypted over TCP), or RELP—depending on what your syslog server can support.

Chapter 8 discusses the use of Syslog in more depth and under the context of Security.

Backup

As touched upon in the “Planning for vCenter Server Availability” section, having solid backups for your vCenter Server and Platform Services Controllers is key to an enterprise ready environment. In the Backup area, you can configure the vCenter Server or Platform Services Controller to create file-based backups to an external location, using FTP, FTPS, HTTP, HTTPS, or SCP. While this functionality is not new in vSphere 6.7, the ability to schedule is! Gone are the days of using customized scripts to manually run a backup of the vCenter Server or PSC., You can now pick the schedule and retention of file-based backups of your systems.

Chapter 7 discusses how to configure and use the file-based backup functionality to preserve your environment in the event of a corruption or disaster.