Chapter 3

Installing and Configuring vCenter Server

In the majority of today's information systems, the client-server architecture is king. This standing is because the client-server architecture can centralize resource management and give end users and client systems simplified access to those resources. Information systems used to exist in a flat, peer-to-peer model, when user accounts were required on every system where resource access was needed and when significant administrative overhead was needed simply to make things work. That is how managing a large infrastructure with many ESXi hosts feels without vCenter Server. vCenter Server brings the advantages of the client-server architecture to the ESXi host and to VM management.

In this chapter, you will learn to

• Understand the components and role of vCenter Server
• Plan a vCenter Server deployment
• Install and configure a vCenter Server database
• Install and configure the Single Sign-On service
• Install and configure the Inventory Service
• Install and configure vCenter Server
• Install and configure the Web Client service
• Use vCenter Server's management features

Introducing vCenter Server

As the size of a virtual infrastructure grows, managing the infrastructure from a central location becomes significantly more important. vCenter Server is an application that serves as a centralized management tool for ESXi hosts and their respective VMs. vCenter Server acts as a proxy that performs tasks on the individual ESXi hosts that have been added as members of a vCenter Server installation. As discussed in Chapter 1, “Introducing VMware vSphere 5.5,” VMware includes vCenter Server licensing in every kit and every edition of vSphere, underscoring the importance of vCenter Server. Although VMware does offer a few different editions of vCenter Server (vCenter Server Essentials, vCenter Server Foundation, and vCenter Server Standard), we'll focus only on vCenter Server Standard in this book.

While VMware has a number of other products, vCenter is generally the central integration point tying them all together. Software such as vCloud Director, vCloud Automation Center, Site Recovery Manager, and vCenter Operations Manager all depend on an instance of vCenter Server. Not only this, but as you will see, much of the advanced functionality that vSphere offers comes only when vCenter Server is present. Specifically, vCenter Server offers core services in the following areas:

• Resource management for ESXi hosts and VMs
• Template management
• VM deployment
• VM management
• Scheduled tasks
• Statistics and logging
• Alarms and event management
• ESXi host management

Figure 3.1 outlines the core services available through vCenter Server.

FIGURE 3.1 vCenter Server provides a full spectrum of virtualization management functions.

vCenter Server can be installed in one of two different ways: The more traditional approach is an application installed on a Windows server; the newer format is as a Linux-based virtual appliance. You'll learn more about virtual appliances in Chapter 10, “Using Templates and vApps,” but for now, suffice it to say that the vCenter Server virtual appliance (which you may see referred to as VCVA or VCSA) offers an option to quickly and easily deploy a full installation of vCenter Server on SuSE Linux.

Because of the breadth of features included in vCenter Server, most of these core services are discussed in later chapters. For example, Chapter 9, “Creating and Managing Virtual Machines,” discusses VM deployment, VM management, and template management. Chapter 11, “Managing Resource Allocation,” and Chapter 12, “Balancing Resource Utilization,” deal with resource management for ESXi hosts and VMs, and Chapter 13, “Monitoring VMware vSphere Performance,” discusses alarms. In this chapter, we'll focus primarily on ESXi host management, but we'll also discuss scheduled tasks, statistics and logging, and event management.

There are other key items about vCenter Server that you can't really consider core services. Instead, these underlying features support the core services provided by vCenter Server. In order to help you more fully understand the value of vCenter Server in a vSphere deployment, we need to provide a closer look at the following:

• Centralized user authentication
• Web-based client server
• Inventory system
• Extensible framework

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 operates and to reducing the management overhead that vCenter Server brings to a vSphere implementation. 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 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, vCenter Server might not be missed from a management perspective, but it will certainly be missed from a feature set viewpoint. 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. Without vCenter Server, you also lose key functionality such as vSphere Distributed Switches, host profiles, policy-driven storage, 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 vCloud Director or vCenter Orchestrator, with their own possible accounts and passwords.

vCenter—well, more accurately vCenter Single Sign-On (SSO)—addresses this problem. It is a prerequisite for installing vCenter Server; that is, vCenter Server cannot be installed without installing SSO 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. 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 OpenLDAP. 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 vCenter, vCenter Orchestrator (vCO), vCloud Director (vCD), and vCloud Networking and Security (vCNS). 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 list outlines the steps taken when a user logs on using the vSphere Web Client (see Figure 3.2).

1. The vSphere Web Client presents a secure web page to log into.
2. The username and password is issued to the SSO server (in the form of a SAML 2.0 token).
3. The SSO server then sends a request to the relevant authentication mechanism (local, AD, or OpenLDAP)
4. Once authentication succeeds, SSO then passes a token to the vSphere Web Client.
5. This token can now be used to authenticate directly with vCenter, vCO, vCNS, or vCD.

As you can see, the authentication procedure can sound more complicated than some more traditional methods; however, all of this ends up being seamless to the end administrator who gets access as they did before.

During the installation of SSO, which we'll detail later in this chapter, you are given three options for the installation type. Depending on the availability requirements of your vCenter Server installation, you may wish to make SSO available from multiple sites or highly available in a cluster. When installing SSO for the first time, the first instance will always be the Primary Node. The SSO installer then allows you to install additional SSO server nodes in the mode that suits your environment.

FIGURE 3.2 The steps taken to issue an authenticated session with the new SSO component.

Using the vSphere Web Client for Administration

With the release of vSphere 5.1, VMware started shipping two different clients to use with vCenter Server. The older, more traditional client is a .NET Windows-only application, while the newer is a server-side installation for administering vSphere from a web browser. While not all browsers are supported, the following browsers are certified and supported with the vSphere Web Client:

• Microsoft Internet Explorer, 7, 8, and 9
• Mozilla Firefox 3.6 and later
• Google Chrome 14 and later

Additionally, to use the vSphere Web Client, you must have Adobe Flash Player version 11.1 or later installed.

As stated in Chapter 2, previously the vSphere Web Client was not as feature rich as the traditional vSphere Client, but with the release of vSphere 5.5, this has changed. From vSphere 5.1 onward, VMware stated that it was no longer adding features to the .NET vSphere Client: Only the vSphere Web Client would gain new feature capabilities, so it's definitely the one to use.

As you read through the rest of this book, you can assume that unless we specify the vSphere Client, the vSphere Web Client is the default choice and the one you should be using.

Understanding the vCenter Inventory Service

The Inventory Service is tightly integrated with the vSphere Web Client, and in fact, the Inventory Service exists to ensure that the vSphere Web Client performs well. One way to think of the Inventory Service is that it's like a proxy server; it sits between the source (the vCenter Server itself) and the requester (the vSphere Web Client). The Inventory Service reduces traffic to and from the vCenter Server by caching information in its own database.

Not only does the vCenter Inventory Service cache queries and results for the vSphere Web Client, it can also be installed on a separate server to ensure an appropriate level of resources. The reasoning behind this is again solely for performance and scalability benefits.

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.3 shows some of the components that revolve around the core services of vCenter Server.

A key aspect for the success of virtualization is the ability to allow third-party companies to provide additional 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 Chapter 8, which goes deeper into vCenter Server's access controls. Chapter 11 discusses resource management, while 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.

FIGURE 3.3 Other applications can extend vCenter Server's core services to provide additional management functionality.

Choosing the Version of vCenter Server

As mentioned in the previous section, vSphere 5.5 vCenter Server comes not only as a Windows-based application but also as a SuSE Linux–based virtual appliance. As a result, one of the primary decisions that you must make as you prepare to deploy vCenter Server is which version you will use. Will you use the Windows Server–based version or the virtual appliance?

There are some advantages and disadvantages to each approach:

• If your experience is primarily with Windows Server, you may not be familiar with the Linux underpinnings of the vCenter virtual appliance. This introduces a learning curve that you should consider.
• If you need support for Microsoft SQL Server, the Linux-based vCenter virtual appliance won't work; you'll need to deploy the Windows Server–based version of vCenter Server. However, if you are using Oracle, or if you are a small installation without a separate database server, the vCenter Server virtual appliance will work just fine (it has its own embedded database if you don't have or don't need a separate database server).
• If you want to use vCenter Heartbeat to protect vCenter Server from downtime, you'll need to use the Windows Server–based version of vCenter Server.
• If you need to use linked mode, you must deploy the Windows Server–based version of vCenter Server. The vCenter Server virtual appliance does not support linked mode.
• Conversely, if your experience is primarily with Linux, then deploying a Windows Server–based application will require some learning and acclimation for you and/or your staff.
• The Linux-based virtual appliance comes preloaded with additional services like Auto Deploy (covered in Chapter 2), Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer Protocol (TFTP), and syslog. If you need these services on your network, you can provide them with a single deployment of the vCenter virtual appliance. With the Windows Server–based version, these services are separate installations or possibly even separate VMs (or, worse yet, separate physical servers!).
• Because the vCenter Server virtual appliance naturally runs only as a VM, you are constrained to that particular design decision. If you want or need to run vCenter Server on a physical system, you cannot use the vCenter Server virtual appliance.

As you can see, there are a number of considerations that will affect your decision to deploy vCenter Server as a Windows Server–based installation or as a Linux-based virtual appliance.

In the next section, we'll discuss some of the planning and design considerations that have to be addressed if you plan to deploy the Windows Server–based version of vCenter Server. Most of these issues apply to the Windows Server–based version of vCenter Server, but some may also apply to the virtual appliance; we'll point those out where applicable.

Planning and Designing a vCenter Server Deployment

vCenter Server is a critical application for managing your virtual infrastructure. Its implementation should be carefully designed and executed to ensure availability and data protection. When discussing the deployment of vCenter Server and its components, the following questions are among the most common questions to ask:

• How much hardware do I need to power vCenter Server?
• Which database server should I use with vCenter Server?
• How do I prepare vCenter Server for disaster recovery?
• Should I run vCenter Server in a VM?

A lot of the answers to these questions are dependent on each other, but we have to start somewhere, so we'll start with the first topic: figuring out how much hardware you need for vCenter Server.

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 only to the Windows Server–based version of vCenter Server; 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 Windows Server–based version of vCenter Server are as follows:

• Two 64-bit CPUs or a single dual-core 64-bit CPU.
• 2 GHz processor or faster.
• 4 GB of RAM or more.
• 4 GB of free disk space.
• A network adapter (Gigabit Ethernet strongly recommended).
• A supported version of Windows (Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, or Windows Server 2008 R2); vCenter Server 5 requires a 64-bit version of Windows.

Keep in mind these are minimum system requirements. Large enterprise environments with many ESXi hosts and VMs must scale the vCenter Server system accordingly.

In addition, the 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 performs the management of your ESXi hosts and VMs, vCenter Server uses a database for storing all of its configuration, permissions, statistics, and other data. Figure 3.4 shows the relationship between vCenter Server and the separate database server.

When answering the question of how much hardware vCenter Server requires, you have to address the computer running vCenter Server and the one running the components it depends on, which include the following components:

• Database server
• Single Sign-On server
• Inventory server
• Any other services you wish to co-locate

FIGURE 3.4 vCenter Server acts as a proxy for managing ESXi hosts, but all of the data for vCenter Server is stored in a database.

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 when capacity is at a premium. Keep in mind that VMware recommends 10 GB of RAM if vCenter Server, vCenter Single Sign-On, and vCenter Inventory Service are installed on the same machine. This would be the case if you use the Simple Install option when installing vCenter Server.

Throughout this chapter, we'll use the term separate database server to refer to a database server application that is separately installed and managed. Although it might reside on the same computer, it is still considered a separate database server because it is managed independently of vCenter Server. You'll also see the term backend database, which refers to the actual database that vCenter Server uses on the separate database server.

Without considering the separate database or SSO servers for vCenter Server, VMware suggests a system configured with two CPU cores and 4 GB of RAM to support up to 50 ESXi hosts and 500 powered-on VMs. For environments consisting of up to 300 ESXi hosts and up to 3,000 powered-on VMs, VMware recommends four CPU cores and 8 GB of RAM. Finally, for environments scaling all the way up to 1,000 ESXi hosts and up to 10,000 powered-on VMs, vCenter Server should have 8 CPU cores and 16 GB of RAM.

Should you choose to run the separate database server on the same physical computer as vCenter Server, 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 SSO and the Inventory Service, so you will need to plan accordingly. That brings us to the next topic: choosing which database server to use.

Choosing a Database Server for vCenter Server

In light of the sensitive and critical nature of the data in the vCenter Server databases, VMware supports vCenter Server issues only with backend databases on enterprise-level database servers. Both the Windows Server–based version and the virtual appliance version of vCenter Server use a backend database, so you'll need to decide which one to use either way. vCenter Server officially supports the following database servers:

• Microsoft SQL Server 2008 R2 Express (bundled with vCenter Server)
• Microsoft SQL Server 2005 (32-bit or 64-bit; SP3 is required, and SP4 is recommended)
• Microsoft SQL Server 2008 (32-bit or 64-bit; SP1 is required, and SP2 is recommended)
• Microsoft SQL Server 2008 R2
• Oracle 10g R2 (10.2.0.4 required)
• Oracle 11g R1 (11.1.0.7 required)
• Oracle 11g R2 (11.2.0.1 with patch 5 required)

Note that although a database might be supported for use with vCenter Server, that same database might not be supported for other components of vSphere such as vSphere Update Manager or other plug-ins that require database support. For up-to-date compatibility information, refer to the vSphere Compatibility Matrixes available from VMware's website (www.vmware.com). In addition, note that Microsoft SQL Server is supported for use by a Windows Server–based installation of vCenter Server, but it is not supported by the vCenter Server virtual appliance.

For smaller environments, users have the option of using Microsoft SQL Server 2008 Express Edition or, if using the virtual appliance, an embedded database. As of this writing, VMware had not yet published any sizing recommendations regarding the use of the embedded database. As stated in the sidebar “Author Nick Marshall's View on the vCenter Virtual Appliance,” the use of the vCenter virtual appliance specifically with the embedded database is probably best suited for smaller environments.

Users should use SQL Server 2008 Express Edition only when their vSphere deployment will be limited in size; otherwise, users should plan on using a separate database server. If you are starting out with a small environment that will work with SQL Server 2008 Express Edition, note that you can upgrade to a full-featured version of SQL Server at a later date. While it is not necessarily an automated or supported migration path, more information on upgrading SQL Server 2008 Express is available on the Microsoft website (www.microsoft.com). Depending on your situation, it might be better to build a new SQL server and then follow the VMware migration plan for relocating vCenter databases.

Because the separate database server is independently installed and managed, some additional configuration is required. Later in this chapter, the section “Installing vCenter Server” provides detailed information about working with separate database servers and the specific configuration that is required for each.

So, how does an organization go about choosing which separate database server to use? The process of selection typically reflects what an organization already uses or is licensed to use. Organizations with Oracle may decide to continue to use Oracle for vCenter Server; organizations that are predominantly based on Microsoft SQL Server will likely choose to use SQL Server to support vCenter Server. The choice of which version of vCenter Server—Windows Server–based or virtual appliance—will also affect this decision because the supported databases are different for each version. You should choose the database engine with which you are most familiar and that will support both the current and projected size of the virtual infrastructure.

With regard to the hardware requirements for the database server, the underlying database server will largely determine those requirements. VMware provides some general guidelines around Microsoft SQL Server in the white paper “VirtualCenter Database Performance for Microsoft SQL Server 2005,” available on VMware's website at

www.vmware.com/files/pdf/vc_database_performance.pdf

Although written with VirtualCenter 2.5 in mind, this information applies to newer versions of vCenter Server as well. In a typical configuration with standard logging levels, an SQL Server instance with two CPU cores and 4 GB of RAM allocated to the database application should support all but the very largest or most demanding environments.

If you plan to run the database server and vCenter Server components on the same hardware, you should adjust the hardware requirements accordingly.

Appropriately sizing hardware for vCenter Server and the separate database server is good and necessary. Given the central role that vCenter Server plays in a vSphere environment, though, you must also account 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. Any good disaster-recovery or business-continuity plan must also include instructions on how to handle data loss or corruption in the backend databases, and the separate database server(s)—if running on a separate physical computer or in a separate VM—should be designed and deployed in a resilient and highly available fashion. This is especially true in larger 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 SINGLE SIGN-ON

Single Sign-On is an integral part of vCenter Server. Without it there is no ability to log in and administer vCenter. Therefore, it is imperative that your protection strategy for the whole of vCenter Server (and it's components) covers vCenter Single Sign-On. There are three methods for ensuring you have an SSO instance available to you with little or no downtime: deploying in a High Availability cluster, deploying to multiple sites, and having a solid backup plan.

During the SSO installation, you have the ability to join an existing deployment and configure a High Availability (HA) cluster. With this configuration, all SSO instances must sit behind a load balancer. Deploying SSO in this way protects you from an outage of the SSO application or server.

The other installation option for SSO is called Multisite. This mode lets you install SSO with multiple physical locations. While this is usually deployed when you need to be able to sign in from multiple locations, it can also be used to facilitate a protection mechanism.

To save the time of redeploying and restoring a backup, if your SSO server is a VM, you can also regularly clone this VM to serve as a recovery point. This, however, is no substitute for a properly configured, company-wide backup solution that covers the SSO deployment.

PROTECTING THE INVENTORY SERVICE

VMware doesn't provide any type of built-in High Availability, but you can always run the Inventory Service on an HA-enabled vSphere cluster (see the section “Running vCenter Server and Its Components as VMs”). While HA is certainly an option for protecting the Inventory Service, unfortunately Fault Tolerance is not because the hardware requirements for this server state the need for two cores, as does SSO.

While the data that the Inventory Service stores is not as important as that in the SSO or vCenter itself, the Inventory Service still needs to be available for vCenter to function and therefore you must consider a plan on how to keep downtime to a minimum. Like SSO, the Inventory Service installs with a backup script within its installation directory. To use this feature, run the following command from the Inventory Service server:

vCenter_Server_installation_directoryInfrastructureInventory Servicescriptsackup.bat -
file backup_file_name

As stated earlier, the data that the Inventory Service holds locally is not as mission critical as the data SSO or vCenter holds. If you were in the position that your Inventory Service needed to be reinstalled and you had no backup to restore, you would only lose the tags metadata (tags are explained later in this chapter).

PROTECTING VCENTER SERVER

First, vCenter Server Heartbeat—a product available from VMware since VirtualCenter/vCenter Server 2.5 to provide high availability with little or no downtime—will be available with support for vCenter Server 5.5 upon release or shortly after the release of vSphere 5.5 (vCenter Server 5.5). Using vCenter Server Heartbeat will automate both the process of keeping the active and passive vCenter Server instances synchronized and the process of failing over from one to another (and back again). The website at www.vmware.com/products/vcenter-server-heartbeat has more information on vCenter Server Heartbeat.

If the vCenter Server computer is a physical server, one way to provide availability is to create a standby vCenter Server system that you can turn on in the event of a failure of the online vCenter Server computer. After failure, you bring the standby server online and attach it to the existing SQL Server database, and then the hosts can be added to the new vCenter Server computer. In this approach, you'll need to find mechanisms to keep the primary and secondary/standby vCenter Server systems synchronized with regard to file system content and configuration settings. The use of the Linux-based virtual appliance might make this approach easier because it is a VM; it therefore can be cloned (a process you'll see in more detail in Chapter 10).

A variation on that approach is to keep the standby vCenter Server system as a VM. You can use physical-to-virtual (P2V) conversion tools to regularly “back up” the physical vCenter Server instance to a standby VM. This method reduces the amount of physical hardware required and leverages the P2V process as a way of keeping the two vCenter Servers synchronized. Obviously, this sort of approach is viable for a Windows Server–based installation on a physical system but not applicable to the virtual appliance version of vCenter Server.

As a last resort for recovering vCenter Server, it's possible to just reinstall the software, point to the existing database, and connect the host systems. Of course, this assumes that the database is housed on a separate system from vCenter Server itself. The installation of vCenter Server is not a time-consuming process. Ultimately, the most important part of the vCenter Server recovery plan is to ensure that the database server is redundant and protected.

PROTECTING THE VCENTER DATABASE

For high availability of the database server supporting vCenter Server, you can configure the backend database on a cluster. Figure 3.5 illustrates using an 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 to create a database replica on a separate system. If using 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.

FIGURE 3.5 A good disaster recovery plan for vCenter Server should include a quick means of regaining the user interface as well as ensuring that the data is highly available and protected against damage.

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

Running vCenter Server and Its Components as VMs

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 gives you several advantages, including snapshots, clones, vMotion, vSphere HA, and vSphere DRS.

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. However, remember that the Windows Server–based version of vCenter Server uses an ADAM database to store roles and permissions, so roles and permissions on the clone will “roll back” to the point in time at which the clone was created. 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.6 illustrates the setup of a manual cloning of a vCenter Server VM.

FIGURE 3.6 If vCenter Server is a VM, its virtual disk file can be copied regularly and used as the hard drive for a new VM, effectively providing a point-in-time restore in the event of complete server failure or loss.

Some organizations may have a “virtualize first” or a “100% virtual” policy; while 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 of 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.

While delving into design best practices is outside the scope of this book, just as with physical infrastructure design, there are certain things that need to be considered to ensure that your virtual infrastructure is designed to meet business requirements. But 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 install vCenter Server. The next section mainly focuses on the installation of the Windows Server–based version of vCenter Server; for information on the vCenter Server virtual appliance, refer to the section “Deploying the vCenter Server Virtual Appliance.”

Installing vCenter Server and Its Components

Depending on the size of the environment to be managed, installing vCenter Server can be simple. In small environments, the vCenter Server Installer can install and configure all the necessary components. For larger environments, installing vCenter Server in a scalable and resilient fashion is a bit more involved and requires a few different steps. For example, supporting more than 1,000 ESXi hosts or more than 10,000 VMs requires installing multiple vCenter Server instances in a linked mode group, a scenario that we'll discuss later in this chapter in the section “Installing vCenter Server in a Linked Mode Group.” You also know that the majority of vCenter Server deployments needs a separate database server installed and configured to support vCenter Server. The exception would be the very small deployments in which SQL Server 2008 Express Edition is sufficient.

The majority of this discussion is applicable only to installing vCenter Server and its components on a Windows Server–based computer (physical or virtual). However, some tasks—such as the tasks required for preparing separate database servers—are applicable to the use of the vCenter Server virtual appliance as well.

www.update.microsoft.com/microsoftupdate/v6/default.aspx

Depending on the database engine you will use, different configuration steps are required to prepare the database server for vCenter Server, and these steps must be completed before you can actually install vCenter Server. If you are planning on using SQL Server 2008 Express Edition—and you're aware of the limitations of using this edition, as described earlier in the sidebar “Using SQL Server 2008 Express Edition”—you can skip ahead to the section “Installing the vCenter Server Components.” Otherwise, let's take a closer look at working with a separate database server and what is required.

Configuring the vCenter Server Backend Database Server

As noted previously, vCenter Server stores the majority of its information in a backend database, usually using a separate database server. It's important to realize that the backend database is a key component to this infrastructure. The backend database server should be designed and deployed accordingly. Without the backend database, you will find yourself rebuilding an entire infrastructure.

On the backend database server, vCenter Server require specific permissions on their databases. After the database is created and configured appropriately, connecting vCenter Server to it requires that an Open Database Connectivity (ODBC) data source name (DSN) be created on the vCenter Server system. The ODBC DSN should be created under the context of a database user who has full rights and permissions to the database that has been created specifically for storing vCenter Server data.

In the following sections, we'll take a closer look at working with the two possible database servers used in conjunction with vCenter Server: Oracle and Microsoft SQL Server.

WORKING WITH ORACLE DATABASES

Perhaps because Microsoft SQL Server was designed as a Windows-based application, like vCenter Server, working with Oracle as the backend database server involves a bit more effort than using Microsoft SQL Server.

To use Oracle 10g or 11g, you need to install Oracle and create a database for vCenter Server to use. Although it is supported to run Oracle on the same computer as vCenter Server, it is not a configuration we recommend. Still, in the event that you have valid business reasons for doing so, we'll walk you through the steps for configuring Oracle to support vCenter Server both locally (on the same computer as vCenter Server) and remotely (on a different computer than vCenter Server). If you are deploying the vCenter Server virtual appliance, then only the remote Oracle configuration applies. Both of these sets of instructions assume that you have already created the database you are going to use.

PREPARING AN ORACLE DATABASE FOR VCENTER

Perform the following steps to prepare Oracle for vCenter Server if your Oracle database resides on the same computer as vCenter Server:

1. Log into an SQL*Plus session with the system account to create a database user. Run the following SQL command to create a user with the correct permissions:

   CREATE USER "vpxadmin" PROFILE "DEFAULT" IDENTIFIED BY "vcdbpassword"
   DEFAULT TABLESPACE
   "VPX" ACCOUNT UNLOCK;
   grant connect to VPXADMIN;
   grant resource to VPXADMIN;
   grant create view to VPXADMIN;
   grant create sequence to VPXADMIN;
   grant create table to VPXADMIN;
   grant create materialized view to VPXADMIN;
   grant execute on dbms_lock to VPXADMIN;
   grant execute on dbms_job to VPXADMIN;
   grant unlimited tablespace to VPXADMIN;

   If the RESOURCE role doesn't have CREATE PROCEDURE, CREATE TABLE, and CREATE SEQUENCE privileges assigned, you'll need to grant them to the vCenter Server database user.

2. Run the following SQL command to create the vCenter Server database:

   CREATE SMALLFILE TABLESPACE "VPX" DATAFILE 'C:OracleORADATAVPXVPX.DBF' SIZE 1G AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED LOGGING EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

   Modify the path to the database as appropriate for your installation.

3. Now you need to assign a user permission to this newly created tablespace. While you are still connected to SQL*Plus, run the following SQL command:

   CREATE USER vpxAdmin IDENTIFIED BY vpxadmin DEFAULT TABLESPACE vpx;

4. Install the Oracle client and the ODBC driver.
5. Modify the tnsnames.ora file to reflect where your Oracle database is located:

   VC=
   (DESCRIPTION=
   (ADDRESS_LIST=
   (ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))
   )
   (CONNECT_DATA=
   (SERVICE_NAME=VPX)
   )
   )

   The HOST= value should be set to localhost if you are accessing the Oracle database locally or the name of the remote Oracle database server if you are accessing the database remotely. Specify the remote host as a fully qualified domain name (FQDN), such as esxi-05.lab.local.

6. Create the ODBC DSN. When you are creating the DSN, be sure to specify the service name as listed in TNSNAMES.ORA (in this example, VPX).
7. While logged into SQL*Plus with the system account, run the following SQL command to enable database monitoring via the vCenter Server user:

   grant select on v_$system_event to VPXADMIN;
   grant select on v_$sysmetric_history to VPXADMIN;
   grant select on v_$sysstat to VPXADMIN;
   grant select on dba_data_files to VPXADMIN;
   grant select on v_$loghist to VPXADMIN;

8. After you complete the vCenter Server installation, copy the Oracle JDBC driver (ojdbc13.jar) to the tomcatlib folder under the VMware vCenter Server installation folder.

After the Oracle database is created and configured appropriately and the ODBC DSN is established, you're ready to install vCenter Server.

WORKING WITH MICROSOFT SQL SERVER DATABASES

In light of the existing widespread deployment of Microsoft SQL Server 2005 and Microsoft SQL Server 2008, it is common to find SQL Server as the backend database for vCenter Server. This is not to say that Oracle does not perform as well or that there is any downside to using Oracle. Microsoft SQL Server just happens to be implemented more commonly than Oracle and therefore is a more common database server for vCenter Server.

If you are considering Microsoft SQL Server as the separate database server for the backend database, keep in mind that the vCenter Server virtual appliance does not support Microsoft SQL Server.

Connecting vCenter Server to a Microsoft SQL Server database, as with the Oracle implementation, requires a few specific configuration tasks, as follows:

• vCenter Server supports both Windows and mixed mode authentication. Be aware of which authentication type the SQL Server is using because this setting will affect other portions of the vCenter Server installation.
• You must create a new database for vCenter Server. Each vCenter Server—remember that there may be multiple instances of vCenter Server running in a linked mode group—will require its own SQL database.
• You must create an SQL login that has dbo (db_owner) access to the databases you created for vCenter Server. If the SQL Server is using Windows authentication, this login must be linked to a domain user account; for mixed mode authentication, the associated domain user account is not required.
• You must set the appropriate permissions for this SQL login by mapping the SQL login to the dbo user on the databases created for vCenter Server. In SQL Server 2005/2008, you do this by right-clicking the SQL login, selecting Properties, and then choosing User Mapping.
• Not only must the SQL login have dbo privileges on the database created for vCenter Server, it must also be set as the owner of the database. Figure 3.7 shows a new SQL database being created with the owner set to the vCenter Server SQL login.

  FIGURE 3.7 The SQL Server 2005/2008 database that vCenter Server uses must be owned by the account vCenter Server uses to connect to the database.

  

• Finally, the SQL login created for use by vCenter Server must also have dbo privileges on the MSDB database but only for the duration of the installation process. This permission can and should be removed after installation is complete to aid in maintaining integrity within the SQL database infrastructure and to adhere to the principle of least privilege security best practices.

If you have an existing SQL Server 2005/2008 database that needs to be used as the backend for vCenter Server, you can use the sp_changedbowner stored procedure command to change the database ownership accordingly. For example, the following command would change the database owner to an SQL login named vcdbuser:

EXEC sp_changedbowner @loginame='vcdbuser', @map='true'

You need to take these steps prior to creating the ODBC DSN to the SQL Server database.

CONFIGURING THE IDBC DSN

After your database is set up, you can create the ODBC DSN to be used with the vCenter Server installation wizard. SQL Server 2005 and SQL Server 2008 require the use of the SQL Native Client. Because vCenter Server requires SQL Server 2005 or 2008, you're required to use the SQL Native Client. If you do not find the SQL Native Client option while creating the ODBC DSN, you can download it from Microsoft's website or install it from the SQL Server installation media.

After the SQL Native Client has been installed—if it wasn't installed already—then you are ready to create the ODBC DSN that vCenter Server uses to connect to the SQL Server instance hosting its database. This ODBC DSN must be created on the computer where vCenter Server will be installed.

Perform the following steps to create an ODBC DSN to an SQL Server 2005/2008 database:

1. Log onto the computer where vCenter Server will be installed later.

   You need to log on with an account that has administrative permissions on that computer.

2. Open the Data Sources (ODBC) applet from the Administrative Tools menu.
3. Select the System DSN tab.
4. Click the Add button.
5. Select the SQL Native Client from the list of available drivers, and click the Finish button.

   If the SQL Native Client is not in the list, you can download it from Microsoft's website or install it from the SQL Server installation media.

   Go back and install the SQL Native Client; then restart this process.

6. The Create New Data Source To SQL Server dialog box opens. In the Name text box, type the name you want to use to reference the ODBC DSN.

   Make note of this name—this is the name you will give to vCenter Server during installation to establish the database connection.

7. In the Server drop-down list, select the SQL Server 2005/2008 computer where the database was created, or type the name of the computer running SQL Server 2005/2008 that has already been prepared for vCenter Server.

   Be sure that whatever name you enter here can be properly resolved; we generally recommend using the fully qualified domain name.

8. Click the Next button.
9. Choose the correct authentication type, depending upon the configuration of the SQL Server instance.

   If you are using SQL Server authentication, you also need to supply the SQL login and password created earlier for use by vCenter Server. Click Next.

10. If the default database is listed as Master, select the Change The Default Database To check box, and then select the name of the vCenter Server database as the default. Click Next.
11. None of the options on the next screen—including the options for changing the language of the SQL Server system messages, regional settings, and logging options—need to be changed. Click Finish to continue.
12. On the summary screen, click the Test Data Source button to test the ODBC DSN.

    If the tests do not complete successfully, double-check the SQL Server and SQL database configuration outlined previously.

13. Click OK to return to the ODBC Data Source Administrator, which will now have the new System DSN you just created listed.

At this point, you are ready to actually install vCenter Server.

Installing the vCenter Server Components

With the databases in place and configured, you can now install vCenter Server. After you've done that, you can add servers and continue configuring your virtual infrastructure, including adding vCenter Server instances in a linked mode group.

The vCenter Server installation itself takes only a few minutes and is not administratively intensive, assuming you've completed all of the preinstallation tasks. You can start the vCenter Server installation by double-clicking autorun.exe inside the vCenter Server installation directory.

The VMware vCenter Installer, shown in Figure 3.8, is the central point for a number of installations:

• vCenter Single Sign-On
• vCenter Inventory Service
• vCenter Server
• vSphere Client
• vSphere Web Client (Server)
• vSphere Update Manager

FIGURE 3.8 The VMware vCenter Installer offers options for installing several different components.

Chapter 4, “vSphere Update Manager and the vCenter Support Tools,” provides more detail on vSphere Update Manager and the vCenter Support Tools. You already installed the vSphere Client in Chapter 2. For now, we'll focus just on vCenter Server and its components.

If you will be using Windows authentication with a separate SQL Server database server, there's an important step here before you go any farther. For the vCenter Server services to be able to connect to the SQL database, these services need to run in the context of the domain user account that was granted permission to the database. Be sure that you know the username and password of the account that was granted permission to the backend database before proceeding. You'll also want to be sure that you've created an ODBC DSN with the correct information. You'll need the information for the ODBC DSN as well as the user account when you install vCenter Server. If you are using SQL authentication, you'll need to know the SQL login and password. We'll assume that you will use integrated Windows authentication.

INSTALLING SINGLE SIGN-ON

Earlier in this chapter we explained that vCenter Single Sign-On (SSO) is a prerequisite for vCenter. Not only must it be installed for vCenter to run, it must be running before the vCenter Inventory Service and vCenter Server itself are installed. Use the following steps to install Single Sign-On:

1. From the VMware vCenter Installer, select vCenter Single Sign-On and then click the Install button.
2. After the vCenter Single Sign-On installer has launched, click Next.
3. Select the tick box to accept the end-user license agreement and click Next.
4. Ensure that the prerequisites check is correct and click Next.
5. On the following screen you will be asked to select the deployment mode. The High Availability and Multisite options were explained in the section “Centralizing User Authentication Using vCenter Single Sign-On.” For this installation we'll just choose the Primary Node type and click Next.
6. Choose a password for the SSO administrator—the “master SSO password.” This account is not linked to any other directory, and is effectively the “root” or “administrator” for this SSO installation.

   THE MASTER SSO PASSWORD

   When installing SSO for the first time, be sure to remember the account password for the SSO Administrator. The username is always [email protected]. This account is needed when installing other VMware components that leverage Single Sign-On.

7. On the following screen, you can name the “site” of this installation. Choose an appropriate name, or use the default and click Next.
8. The vCenter Single Sign-On installer will now ask you to accept or change the default HTTPS port that SSO will use and then Click Next.

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

9. Change the directory for installation if desired and click Next.
10. Finally, review the installation options summary and click Install.
11. Once the installation is complete, click Finish to close the installer.

INSTALLING VCENTER INVENTORY SERVICE

The second prerequisite for vCenter Server installation is the vCenter Inventory Service:

1. From the VMware vCenter Installer, select VMware vCenter Inventory Service and then click the Install button.
2. From the vCenter Inventory Service installer welcome screen, click Next to continue.
3. Select the radio button to accept the end-user license agreement and click Next.
4. Change the directory for installation if desired and click Next.
5. The vCenter Inventory Service installer will now ask you for the FQDN or IP address with a name already in the field. Check or reenter this information and click Next.
6. You will now be asked to select three different ports that the Inventory Service will communicate on. It's best to leave these ports at their preconfigured defaults unless absolutely necessary. Click Next to continue.
7. The JVM Memory screen asks how big your vCenter inventory will be once it's fully configured. Knowing an estimated size is a good idea, but you can always edit this configuration at a later stage using the Tomcat service configuration tool from the Windows Start menu. For now, select Small and click Next to continue.
8. On the Single Sign-On Information screen, you will need to know both the password that you set during SSO installation, the master password, and also any changes made to the default port that SSO is running on. Enter the SSO password and click Next to continue. The installer will verify these details and prompt you to accept the SSO SSL certificate before continuing on to the next screen.
9. Because this is the first installation of vCenter and you have not configured other certificate services, the default security certificates need to be accepted. These can be changed from the default “self-signed” certificates at a later time (covered in Chapter 8). For now, click Install Certificates.
10. Finally, click Install to commence the installation and start the services.
11. Once the installation is complete, click Finish to close the installer.

INSTALLING VCENTER SERVER

After you've logged on as an administrative user to the computer that will run vCenter Server, start the vCenter Server installation process by clicking the link for vCenter Server in the VMware vCenter Installer, shown previously in Figure 3.8. If you have skipped to this section without reading the two prior sections, you will notice that there are a number of prerequisites listed above the Install button. These are mandatory, so make sure to install these first if you have not already done so. If you are running a version of Windows Server that uses User Account Control, you could be prompted to allow the installer to run; if so, select Yes. After you select a language for the installation, you arrive at the installation wizard for vCenter Server.

Perform the following steps to install vCenter Server:

• 1. From the VMware vCenter Installer, select vCenter Single Sign-On and then click the Install button.
• 2. Select the appropriate language and click OK.
• 3. From the installer welcome screen, click Next to continue.
• 5. Select the radio button to accept the end-user license agreement and click Next.
• 6. Enter your vCenter Server license key or leave it blank to start a 60-day trial, then click Next.
• 7. At this point you must select whether to use SQL Server 2008 Express Edition or a separate database server.

  If the environment will be small (a single vCenter Server with fewer than five hosts or fewer than 50 VMs), then using SQL Server 2008 Express is acceptable. For all other deployments, select Use An Existing Supported Database, and select your ODBC DSN from the drop-down list. If you forgot to create the ODBC DSN, you'll need to create it and restart the installation process in order to continue. For the rest of this procedure, we'll assume that you are using an existing supported database. Select the ODBC DSN you created earlier, and click Next.

  ODBC TO DB

  An ODBC DSN must be defined, and the name must match in order to move past the database configuration page of the installation wizard. Remember to set the appropriate authentication strategy and user permissions for an existing database server. If you receive an error at this point in the installation, revisit the database configuration steps. Remember to set the appropriate database ownership and database roles.

• 8. If you are using SQL authentication, then the next screen prompts for the SQL login and password that have permissions to the SQL database created for vCenter Server. Login information is not required if you are using Windows authentication, so you can just leave these fields blank. If the SQL Server Agent service is not running on the SQL Server computer, you'll receive an error at this step and won't be able to proceed. Make sure the SQL Server Agent service is running. Unless you have specifically configured the database server differently than the default settings, a dialog box pops up warning you about the Full recovery model and the possibility that transaction logs may grow to consume all available disk space.

  IMPLICATIONS OF THE SIMPLE RECOVERY MODEL

  If your SQL Server database is configured for the Full recovery model, the installer suggests reconfiguring the vCenter Server database into the Simple recovery model. What the warning does not tell you is that doing this means that you will lose the ability to back up transaction logs for the vCenter Server database. If you leave the database set to Full recovery, be sure to work with the database administrator on an automated process to routinely back up and truncate the transaction logs. By having transaction log backups from a database in Full recovery, you have the option to restore to an exact point in time should any type of data corruption occur. If you alter the recovery model as suggested, be sure you are making consistent full backups of the database, but understand that you will be able to recover only to the point of the last full backup because transaction logs will be unavailable.

• 9. The next screen prompts for account information for the vCenter Server services. If you are using Windows authentication with an SQL database, then you should populate the username and password fields with the correct user information. The “correct user” in this context is the domain user account granted permission on the SQL database. If you are using SQL authentication, then the account information is not as important, although you may want to run the vCenter Server services under an account other than the system account (this is a recommended practice for many Windows Server–based applications).
• 10. If this is the first vCenter Server installation in your environment, then select Create A Standalone VMware vCenter Server Instance. Click Next. We'll cover the other option in the section “Installing vCenter Server in a Linked Mode Group.”
• 11. The next screen provides the option for changing the default TCP and UDP ports on which vCenter Server operates. Unless you have a specific reason to change them, we recommend accepting the defaults. The following ports are listed on this screen:
  • TCP ports 80 and 443 (HTTP and HTTPS)
  • UDP port 902
  • TCP ports 8080 and 8443
  • TCP port 60099
  • TCP ports 389 and 636
• 12. Once the networking configuration is completed, as with the Inventory Service installer, the vCenter installer will ask about the Java Virtual Machine (JVM) Memory configuration. This is related to how much memory is allocated to JVM and therefore how large the environment is that you intend to support. This setting, as seen in Figure 3.9, can be changed at a later time if you outgrow the setting chosen here. For this installation, leave Small selected and click Next.

  FIGURE 3.9 The vCenter Server installation program will optimize the performance of vCenter Server and its components based on your selection on this screen.

  

• 13. On the Single Sign-On Information screen, you will need to know both the password that you set during SSO installation, the master password, and also any changes made to the default port that SSO is running on. Enter the SSO password and click Next to continue. The installer will verify these details and prompt you to accept the SSO SSL certificate before continuing on to the next screen.
• 14. Once this installation has connected to an existing Single Sign-On instance, it asks for a vCenter Administrator user or group so that when you log in for the first time, there is an account with access. By default, this is the SSO Administrator account. Click Next to continue.
• 15. Change the Inventory Service address and port if necessary and click Next to continue.
• 16. Change the directory for installation if desired and click Next.
• 17. On the final screen, to start the installation process, click Install.

After you complete the installation of vCenter Server, browse to vCenter Server's URL (https://<server name> or https://<server ip address>) to open a page that allows you to install the vSphere Client.

The vSphere Web Client connected to vCenter Server should be the primary management tool for managing vCenter. However, if you don't have access to the Web Client Server component, the older vSphere Client can manage vCenter, ESXi hosts, and also their respective VMs. As we've mentioned on several occasions already, the vSphere Client can connect directly to ESXi hosts under the context of a local user account defined on each ESXi host, or it can connect to a vCenter Server instance under the context of a Windows user account defined in Active Directory or the local SAM (Security Account Manager) of the vCenter Server computer. Using vCenter Server and SSO along with Active Directory user accounts is the recommended deployment scenario.

After you install vCenter Server, a number of new services will be installed to facilitate the operation of vCenter Server:

• VMware Log Browser
• VMware vCenter Inventory Service
• VMware VirtualCenter Management Webservices
• VMware VirtualCenter Server, which is the core of vCenter Server and provides centralized management of ESX/ESXi hosts and VMs
• VMware vSphere Profile-Driven Storage Service

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 have changed. 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 SQL Server (or Oracle) database. If vCenter Server cannot access the database because of a lack of connectivity or the database service is not running, then 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. The most important “feature” that you will need to install almost immediately is the vSphere Web Client; let us step you through that process now.

INSTALLING THE VSPHERE WEB CLIENT

In Chapter 2 we explained that there are two different clients that can be used to administer a vCenter Server installation: the old vSphere C# Client and the newer vSphere Web Client. We also guided you through installing the older client. Let us now explain the process to install the vSphere Web Client, and then later in this chapter, we'll explain the differences between these two clients. Here are the steps:

• 1. From the VMware vCenter Installer, select vSphere Web Client and then click the Install button.
• 2. Select the appropriate language and click OK.
• 3. After the installer has launched, click Next.
• 5. Select the radio button to accept the end-user license agreement and click Next.
• 6. Change the directory for installation if desired and click Next.
• 7. You will now be asked to accept or change the HTTP and HTTPS ports that the vSphere Web Client will communicate on. Leave these ports at their preconfigured defaults and click Next.
• 8. On the following screen you will be asked to register this instance of the vSphere Web Client with your existing SSO installation. Be sure to type in your SSO [email protected] password correctly, and make sure the URL Lookup Service points to the SSO server; then click Next. Click yes if prompted to accept the SSO SSL certificate.
• 9. Finally, click Install to commence the installation and start the services.
• 10. Once the installation is complete, click Finish to close the installer.

Now that you've successfully installed all the components to get vCenter Server up and running, you'll probably want to log in and get started. Unless you also wish to know how to deploy either Linked Mode or the virtual appliance version of vCenter, feel free to skip to the section “Exploring vCenter Server.”

Installing vCenter Server in a Linked Mode Group

What is a linked mode group, and why might you want to install multiple instances of vCenter Server into such a group? If you need more ESXi hosts or more VMs than a single vCenter Server instance can handle, or if you need more than one instance of vCenter Server, you can install multiple instances of vCenter Server to scale outward or sideways and have those instances share licensing and permission information. These multiple instances of vCenter Server that share information among them are referred to as a linked mode group. In a linked mode environment, there are multiple vCenter Server instances, and each of the instances has its own set of hosts, clusters, and VMs.

vCenter Server linked mode uses Microsoft ADAM to replicate the following information between the instances:

• Connection information (IP addresses and ports)
• Certificates and thumbprints
• Licensing information
• User roles and permissions

There are a few different reasons why you might need multiple vCenter Server instances running in a linked mode group. With vCenter Server 4.0, one common reason was the size of the environment. With the dramatic increases in capacity incorporated into vCenter Server 4.1 and above, the need for multiple vCenter Server instances due to size will likely decrease. However, you might still use multiple vCenter Server instances. You might prefer to deploy multiple vCenter Server instances in a linked mode group to accommodate organizational or geographic constraints, for example.

Table 3.1 shows the maximum number of hosts or VMs for a single instance of vCenter Server for versions 4.0, 4.1, 5.0, and 5.5. Using a linked mode group is necessary if you need to manage more than the number of ESXi hosts or VMs listed.

TABLE 3.1: Maximum number of hosts or VMs per vCenter Server instance

Before you install additional vCenter Server instances, you must verify the following prerequisites:

• All computers that will run vCenter Server in a linked mode group must be members of a domain. The servers can exist in different domains only if a two-way trust relationship exists between the domains.
• DNS must be operational. Also, the DNS name of the servers must match the server name.
• The servers that will run vCenter Server cannot be domain controllers or terminal servers.
• You cannot combine vCenter Server 5 instances in a linked mode group with earlier versions of vCenter Server.
• vCenter Server instances in linked mode must be connected to a single SSO server, a two-node SSO cluster, or two nodes in multisite mode.
• Windows vCenter is required. Linked mode is not supported with the Linux-based vCenter virtual appliance.

Each vCenter Server instance must have its own backend database, and each database must be configured as outlined earlier with the correct permissions. The databases can all reside on the same database server, or each database can reside on its own database server.

After you have met the prerequisites, installing vCenter Server in a linked mode group is straightforward. You follow the steps outlined previously in “Installing vCenter Server” until you get to step 10. In the previous instructions, you installed vCenter Server as a stand-alone instance in step 10. This sets up a master ADAM instance that vCenter Server uses to store its configuration information.

This time, however, at step 10 you simply select the option Join A VMware vCenter Server Group Using Linked Mode To Share Information.

When you select to install into a linked mode group, the next screen also prompts for the name and port number of a remote vCenter Server instance. The new vCenter Server instance uses this information to replicate data from the existing server's ADAM repository.

After you've provided the information to connect to a remote vCenter Server instance, the rest of the installation follows the same steps.

You can also change the linked mode configuration after the installation of vCenter Server. For example, if you install an instance of vCenter Server and then realize you need to create a linked mode group, you can use the vCenter Server Linked Mode Configuration icon on the Start menu to change the configuration.

Perform the following steps to join an existing vCenter Server installation to a linked mode group:

1. Log into the vCenter Server computer as an administrative user, and run vCenter Server Linked Mode Configuration from the Start menu.
2. Click Next at the Welcome To The Installation Wizard For VMware vCenter Server screen.
3. Select Modify Linked Mode Configuration, and click Next.
4. To join an existing linked mode group, select “Join a VMware vCenter Server group using Linked Mode to share information,” and click Next. This is shown in Figure 3.10.

   FIGURE 3.10 You can join an existing vCenter Server instance to a linked mode group.

   

5. A warning appears reminding you that you cannot join vCenter Server 5.5 with older versions of vCenter Server. Click OK.
6. Supply the name of the server and the LDAP port. Specify the server name as a fully qualified domain name.

   It's generally not necessary to modify the LDAP port unless you know that the other vCenter Server instance is running on a port other than the standard port.

   Click Next to continue.

7. Click Continue to proceed.
8. Click Finish.

Using this same process, you can also remove an existing vCenter Server installation from a linked mode group.

After the additional vCenter Server is up and running in the linked mode group, logging in via the vSphere Client displays all the linked vCenter Server instances in the inventory view, as you can see in Figure 3.11.

FIGURE 3.11 In a linked mode environment, the vSphere Client shows all the vCenter Server instances for which a user has permission.

One quick note about linked mode: While the licensing and permissions are shared among all the linked mode group members, each vCenter Server instance is managed separately, and each vCenter Server instance represents a vMotion domain by virtue of each vCenter Server having unique datacenter objects that ultimately represent a vMotion boundary. This means that you can't perform a vMotion migration between vCenter Server instances in a linked mode group. We'll discuss vMotion in detail in Chapter 12.

Installing vCenter Server onto a Windows Server–based computer, though, is only one of the options available for getting vCenter Server running in your environment. For those environments that don't need linked mode support or environments for which you want a full-featured virtual appliance with all the necessary network services, the vCenter Server virtual appliance is a good option. We'll discuss the vCenter Server virtual appliance in the next section.

Deploying the vCenter Server Virtual Appliance

The vCenter Server virtual appliance is a Linux-based VM that comes prepackaged and preinstalled with vCenter Server. Rather than creating a new VM, installing a guest operating system, and then installing vCenter Server, you only need to deploy the virtual appliance. 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 an Open Virtualization Format (OVF) template. 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.”

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

Perform the following steps to deploy the vCenter Server virtual appliance:

1. Launch the vSphere Client (not the vSphere Web Client) and connect to an ESXi host.

   You could connect to a vCenter Server instance using the Web Client, but if you are deploying the vCenter Server virtual appliance, you most likely do not already have a vCenter Server instance up and running.

2. From the File menu, select Deploy OVF Template.
3. At the first screen of the Deploy OVF Template Wizard, click the Browse button to find the OVF file you downloaded for the vCenter Server virtual appliance.
4. After you've selected the OVF file, click Next.
5. Review the details of the vCenter Server virtual appliance, as shown in Figure 3.12. Click Next when you're ready to proceed.

   FIGURE 3.12 The vCenter Server virtual appliance comes preinstalled with SuSE Linux 11 and vCenter Server.

   

6. Supply a display name for the vCenter Server virtual appliance, and click Next.
7. Select a destination datastore, and click Next.
8. Select the disk provisioning type (Thick Provision Lazy Zeroed, Thick Provision Eager Zeroed, or Thin Provision).

   Chapter 6, “Creating and Configuring Storage Devices,” 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.

   Click Next.

9. Click Finish to start deploying the virtual appliance.

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

   FIGURE 3.13 This dialog box provides information on the status of the vCenter Server virtual appliance deployment.

   

10. Once the vCenter Server virtual appliance is fully deployed, go ahead and power it on.

    You can use the VM console to watch the virtual appliance boot up. Eventually, it will display a virtual appliance management screen. When booting the vCenter Server virtual appliance it expects a DHCP server to be available on the network. If there is no IP address shown on the management screen, just like Figure 3.14, please follow the next section to assign one. If you do have an IP address, feel free to skip the next section.

    FIGURE 3.14 This management screen lets you configure network access to the vCenter Server virtual appliance.

    

Configuring an IP Address on the vCenter Server Virtual Appliance

The following steps outline how to set a static IP address on the vCenter virtual appliance after it's been booted but no IP address has been allocated. These steps are only necessary to get the virtual appliance on the network. Once complete, all further configuration is performed in the web browser.

1. After the vCenter Server virtual appliance has booted, open the console, select Login, and press Enter.
2. At the login screen, enter the default username and password for the vCenter Server virtual appliance distributed by VMware; the default passwords are root and vmware.
3. Once logged in, type /opt/vmware/share/vami/vami_config_net and press Enter. A prompt-driven network configuration script will start running.
4. Use the menu (6) to enter an IP address.
5. Use the menu (2) to enter the default gateway.
6. Use the menu (4) to enter IP addresses for a primary and secondary DNS servers.
7. Use the menu (3) to supply the fully qualified domain name for the virtual appliance.
8. Use the menu (0) to review the network configuration, and press (1) to exit if it is correct.
9. Type exit and press Enter at the command prompt.

The vCenter Server virtual appliance has reconfigured its network settings and returned you to the management console. From this point forward, all the configuration is handled via a web browser. As you can see in Figure 3.14, once networking has been established there are three major tasks to getting the virtual appliance up and running:

• Accept the end-user license agreement (EULA).
• Configure the database.
• Start the vCenter Server services.

We'll take a look at each of these steps in the next few sections.

Accepting the End-User License Agreement

To accept the EULA, open a web browser and navigate to port 5480 on the IP address of the vCenter Server virtual appliance, using a URL such as https://192.168.0.203:5480, where 192.168.0.203 should be replaced with the IP address assigned to the virtual appliance. You might be prompted with a warning about an invalid certificate; accept the certificate and continue on to the site. You'll eventually reach the login screen for the virtual appliance, as shown in Figure 3.15.

FIGURE 3.15 You must first log into the vCenter Server virtual appliance before you can change any configuration settings.

The default username and password for the vCenter Server virtual appliance distributed by VMware are root and vmware.

Immediately upon login, you will be presented with a copy of the VMware EULA for the vCenter Server virtual appliance. Review the EULA, and then mark the Accept License Agreement check box and click Next.

Once the EULA has been accepted, the wizard asks you to specify what type of configuration you would like. The options presented here are as follows:

Configure With Default Settings This option is the simplest form of setup where a local database is used for vCenter.

Update From Previous Version As the name suggests, this configuration option is to be used when upgrading an existing vCenter Server virtual appliance.

Upload Configuration File If you have a previously configured vCenter Server virtual appliance, you can save the configuration and then upload it during setup to ensure consistency.

Set Custom Configuration Custom configuration is where you are able to manually specify all aspects of the setup through the rest of the wizard.

Select Set Custom Configuration and click Next to configure the database connection.

Configuring the Database

Like the Windows Server–based version of vCenter Server, the vCenter Server virtual appliance requires a backend database in order to function properly. The virtual appliance supports Oracle and a local embedded database.

To configure the database settings, click the vCenter Server tab on the VMware vCenter Server Appliance web administration screen, and then select Database. From there, you'll have an option to select Embedded or Oracle. As mentioned previously, Microsoft SQL Server is not supported for use with the virtual appliance.

The instructions provided previously for configuring Oracle are still applicable; you need to perform those steps before you configure the database connection. Once the database has been properly configured, you can specify the database name, server, port, username, and password to use when connecting.

When you've configured your database settings accordingly, click Next to move on to the SSO settings.

Setting Up Single Sign-On

Like the database settings in the previous section, the vCenter Server virtual appliance has the ability to use an embedded copy of SSO or utilize an existing external SSO instance. Use the drop-down to select the type of SSO instance.

To complete this form you will need to enter the following information:

• Username and password for the vCenter to SSO registration
• Account to be allocated as vCenter administrator
• The lookup service location URL

Also, if the database is external to the vCenter Server virtual appliance, you need the following information:

• DB server
• Port
• Instance name
• Login
• Password
• DBA login
• DBA password

Click Next and we'll finish the wizard by entering any AD information that may be required.

Active Directory Settings

There are only three simple requirements to tie the vCenter Server virtual appliance into an existing Active Directory.

• Domain
• Administrator user
• Administrator password

Click Next to review the configuration.

Starting the vCenter Server Services

After you've accepted the EULA and configured the database SSO and AD, you can start the vCenter Server services on the virtual appliance. This is accomplished by clicking the Start button on the final page of the setup wizard. After a few minutes, the services will start (use the Refresh button to refresh the screen to see that the services are currently shown as Running).

You'll now be able to launch the vSphere Web Client and connect to this instance of the vCenter Server virtual appliance. Remember the default username and password; you'll use those for the vSphere Web Client as well.

Installing or deploying vCenter Server is just the beginning. Before you're ready to start using vCenter Server in earnest, you must become a bit more familiar with the user interface and how to create and manage objects in vCenter Server.

Exploring vCenter Server

As explained, you can access vCenter Server through either the vSphere C# Client or the vSphere Web Client. Previously, the Web Client was not as feature rich compared with the traditional vSphere Client, but in vSphere 5.5, the Web Client is the more feature rich of the two. Therefore, this is the client we will use to demonstrate the majority of features throughout this book. If you are new to vSphere, you should know that VMware has publicly stated its intention to retire the traditional vSphere Client, so it makes sense to use the Web Client and become familiar with how it works. There's a lot to cover, so let's start out at the beginning, logging in.

To run the vSphere Web Client, all that you need is a compatible web browser with Adobe Flash installed. The server that runs the vSphere Web Client has a shortcut in the Start All Programs VMware VMware vSphere Web Client folder, but to access the vCenter Web Client from another computer, go to the following address: https://<server.domain.com>:9443/vsphere-client.

For our vSphere Web Client, this address is https://vc.lab.local.9443/vsphere-client.

When you connect to a vCenter Server instance with the vSphere Web Client, you may receive a security warning message that will be slightly different depending on which web browser you are using. This security warning appears because the vSphere Web Client uses HTTP over Secure Sockets Layer (HTTPS) to connect to vCenter Server while the vCenter Server is using a Secure Sockets Layer (SSL) certificate from an “untrusted” source.

To correct this error, you have the following two options:

• You can choose the Do Not Prompt for Security Warnings option (again, the option depends on your browser). This option tells your browser to ignore that there's an untrusted certificate.
• You can install your own SSL certificate from a trusted certification authority on the vCenter Server. This is certainly recommended, and we will step you through this process in Chapter 8 when we discuss more around security.

After the vSphere Web Client connects and authenticates to the vSphere Web Client, you will notice a Getting Started tab that explains the different sections of the user interface. Closing this reveals the home screen, which is the starting point for the vSphere Web Client.

What's in 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. Hosts and VMs you already understand; clusters we'll discuss later in this chapter in the section “Creating and Managing a vCenter Server Inventory.” To see the rest of what vCenter Server has to offer, if you're not already there, click the house icon on the top of the browser next to the VMware vSphere Web Client name.

As shown in Figure 3.16, the interface is divided into three main areas and there is a search bar 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.

Search (3) This bar lets you search for any item and also allows you to save that search for later use.

Global Information (4) On the right is a column that shows what has happened and what is happening and brings potential problems to your attention.

FIGURE 3.16 The vSphere Web Client home screen shows the full selection of features within not just vCenter Server but also both other services that hook into the vSphere Web Client.

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 vCenter, Hosts And Clusters, VMs And Templates, Storage, Networking, and vCenter Orchestrator.
• Under Monitoring, the Web Client has screens for viewing tasks, events, host profiles, storage service classes, and customization specifications.
• Under Administration, there are areas to manage roles, licensing, and the vCenter Solutions Manager.

Many of these features are explored in other areas of the book. For example, networking is discussed in Chapter 5, “Creating and Configuring Virtual Networks,” and storage is discussed in Chapter 6. Chapter 10 discusses templates and customization specifications, and Chapter 8 discusses roles and permissions. 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 lefthand 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 a “greater than” arrow next to it, the menu slides sideways and displays just the subitems of the selected item (generally this will change the content area too). 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 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.

Creating and Managing a vCenter Server Inventory

As a vSphere administrator, you will spend a significant amount of time using the vSphere Web Client. You will spend a great deal of that time working with the various inventory views available in vCenter Server, so it's quite useful to first explain them.

Understanding Inventory Views and Objects

Every vCenter Server has a root object, the datacenter object, which serves 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 will work with ESXi hosts, clusters, resource pools, and VMs. In the VMs And Templates view, you will work with folders, VMs, and templates. In the Storage view, you will 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 around resource allocation or to group hosts into clusters according to business rules or other guidelines.

In VMs And Templates view, though, the placement of VMs and templates within folders is handled irrespective of the specific host on which that VM is running. This allows you to create a logical structure for VM administration that remains, for the most part, independent of the physical infrastructure upon 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, then you would most likely create a hierarchical inventory that mirrors that management style. On the other hand, if your IT management was most profoundly set by the various departments in your company, then 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 around vCenter Server permissions and how you can use them in a vCenter Server hierarchy. Figure 3.17 shows a Hosts And Clusters view of a vCenter Server inventory that is based on a geographical management style.

FIGURE 3.17 Users can create folders above the datacenter object to grant permission at a level that can propagate to multiple datacenter objects or to create folders beneath a datacenter to manage the objects within the datacenter object.

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

FIGURE 3.18 A departmental vCenter Server inventory allows the IT administrator to implement controls within each organizational department.

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.19 shows how you have the ability to create folders designated for the different objects such as hosts and clusters or VMs and templates.

FIGURE 3.19 Create folders to organize objects within the vCenter Web Client.

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, while the VMs And Templates view may reflect a departmental or functional focus. Because permissions are granted based on these structures, organizations have the ability to 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 actually build out your inventory structure and start creating and adding objects in vCenter Server.

Creating and Adding Inventory Objects

Before you can really 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.

CREATING A DATACENTER OBJECT

You might have created the datacenter object as part of the Getting Started Wizard, but if you didn't, you must create one now. Don't forget that you can have multiple datacenter objects within a single vCenter Server instance.

Perform the following steps to create a datacenter object:

1. Launch the vSphere Web Client, if it is not already running, and connect to a vCenter Server instance.
2. From the Home screen, select Hosts And Clusters.
3. In the Navigator, right-click the vCenter Server object, and select New Datacenter.
4. Type in a name for the new datacenter object and click OK.

Once you create at least one datacenter object, you're ready to add your ESXi hosts to the vCenter Server inventory, as described in the next section.

ADDING ESXI HOSTS

In order for vCenter Server to manage an ESXi host, you must first add the ESXi host to vCenter Server. The process of adding an ESXi host to vCenter Server automatically installs a vCenter agent on the ESXi host through which vCenter Server communicates and manages the host.

Note that vCenter Server 5.5 does support adding and managing ESX/ESXi 4.x hosts to the inventory. We'll only describe adding ESXi 5.5 hosts to vCenter Server, but the process is nearly identical for other versions.

Perform the following steps to add an ESXi host to vCenter Server:

1. Launch the vSphere Web Client, if it is not already running, and connect to a vCenter Server instance.
2. From the Navigator, select vCenter Hosts And Clusters, or simply click the Hosts And Clusters icon from the home screen.
3. In the Navigator, right-click the datacenter object, and select Add Host.
4. In the Add Host Wizard, supply the IP address or fully qualified hostname and user account information for the host being added to vCenter Server. This will typically be the root account.

   Although you supply the root password when adding the host to the vCenter Server inventory, vCenter Server uses the root credentials only long enough to establish a different set of credentials for its own use moving forward. This means that you can change the root password without worrying about breaking the communication and authentication between vCenter Server and your ESXi hosts. In fact, regularly changing the root password is considered a security best practice.

5. When prompted to decide whether to trust the host and an SHA1 fingerprint is displayed, click Yes.

   Strictly speaking, security best practices dictate that you should verify the SHA1 finger-print before accepting it as valid. ESXi provides the SHA1 fingerprint in the View Support Information screen at the console.

6. The next screen displays a summary of the ESXi host being added, along with information on any VMs currently hosted on that server. Click Next.
7. Figure 3.20 shows the next screen, where you need to assign a license to the host being added.

   The option to add the host in evaluation mode is also available.

   Choose evaluation mode, or assign a license; then click Next.

8. The next screen offers the option to enable lockdown mode. Lockdown mode ensures that the management of the host occurs via vCenter Server, not through the vSphere Client connected directly to the ESXi host. Click Next.
9. Click Finish at the summary screen.
10. Repeat this process for all the ESXi hosts you want to manage using this instance of vCenter Server.

FIGURE 3.20 Licenses can be assigned to an ESXi host as they are added to vCenter Server or at a later time.

Now compare the tabs in the content area in the middle of the vSphere Web Client for the vCenter Server, datacenter, and host objects. You can see that the tabs presented to you look the same, but if you select them, their subsections change depending on the object selected in the inventory tree. This is yet another example of how vCenter Server's user interface is context sensitive and changes the options available to the user depending on what is selected.

You can add hosts to vCenter Server and manage them as separate, individual entities, but you might prefer to group these hosts together into a cluster, another key object in the vCenter Server inventory. We'll describe clusters in the next section.

CREATING A CLUSTER

We've made a few references to clusters here and there, and now it's time to take a closer look at them. Clusters are administrative groupings of ESXi hosts. Once you have grouped hosts into a cluster, you have the ability to enable some of vSphere's most useful features. vSphere High Availability (HA), vSphere Distributed Resource Scheduler (DRS), and vSphere Fault Tolerance (FT) all work only with clusters. We'll describe these features in later chapters; Chapter 7, “Ensuring High Availability and Business Continuity,” discusses vSphere HA and vSphere FT, while Chapter 12 discusses vSphere DRS.

Perform the following steps to create a cluster:

1. Launch the vSphere Web Client, if it is not already running, and connect to a vCenter Server instance.
2. Right-click a datacenter object in Hosts And Clusters view.
3. Select New Cluster. This opens the New Cluster Wizard.
4. Supply a name for the cluster.

   Don't select Turn ON vSphere DRS or Turn ON vSphere HA; we'll explore these options later in the book (Chapter 12 and Chapter 7, respectively).

   Click Next.

5. Leave EVC set to Disable (the default), and click Next.
6. Don't select Turn On for vCloud Distributed Storage; again, we'll explain this in Chapter 5.
7. Click OK.

Once the cluster is created, adding hosts to it is a matter of simply dragging the ESXi host object onto the cluster object within the Navigator; vCenter Server will add the host to the cluster. You may be prompted about resource pools; refer to Chapter 11 for more information on what resource pools are and how they work.

Adding ESXi hosts to vCenter Server enables you to manage them with vCenter Server. You'll explore some of vCenter Server's management features in the next section.

Exploring vCenter Server's Management Features

After your ESXi hosts are managed by vCenter Server, you can take advantage of some of vCenter Server's management features:

• Basic host management tasks in Hosts And Clusters view
• Basic host configuration
• Scheduled tasks
• Events
• Host profiles
• Tags

In the next few sections, you'll examine each of these areas in a bit more detail.

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:

• Enter Maintenance Mode
• Reboot
• Shutdown
• Disconnect
• New Virtual Machine
• Deploy OVF Template
• New Datastore

The All vCenter Actions submenu has even more options:

• New vApp
• New Resource Pool
• Add Networking
• Enter Standby Mode
• Rescan Storage
• Export System Logs
• Host Profiles
• Remove From Inventory

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 and do not need any additional explanation.

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. In addition, 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.21 shows some of the tabs.

FIGURE 3.21 When a host is selected in the inventory view, the tabs across the top also provide host-management features.

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 and vSphere FT. 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 All 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.

Storage Reports The Storage Reports subsection brings together a number of important storage-related pieces of information. For each VM on the selected host, the Storage Views section shows the current multipathing status, the amount of disk space used, the amount of snapshot space used, and the current number of disks.

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, for example, 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.

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.

Log Browser The Log Browser allows the logs to be retrieved from the host and displayed for analysis. Any one of the host logs, such as the fdm log or the vmkernel log, can be selected and then viewed once the log bundle has been requested from the host. There are also advanced filters to assist with log analysis.

Manage The Manage 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.

Before we show 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 we showed you how to configure NTP time synchronization. Now we want to spend a bit more time on it; however, in the Web Client, the Settings subsection is in the Host Manage tab. You'll be visiting this area quite often throughout this book. In Chapter 5, you'll use the Manage tab for networking configuration, and in Chapter 6 you'll use the Manage tab for storage configuration.

SETTINGS SUBSECTION

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

FIGURE 3.22 The Manage tab of an ESXi host offers a number of different commands to view or modify the host's configuration.

There are a lot of options here, so allow us to quickly run through these options and provide a brief explanation of each.

Default VM Compatibility When a VM is created, by default it has a certain level of features available to it, and with each new revision of vSphere, new features are added. This causes backward compatibility issues when you want to migrate VMs from a newer environment to an older one. While we explain more about VM compatibility in Chapter 9, this is the area where you can set the default level when a VM is created.

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 start up 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. For example, vShield Edge and vShield Endpoint both use agent VMs to help supply their functionality.

Swap File Location This area is where you will configure the location of the swapfiles for running VMs on the host. By default, the swapfile 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.

Licensing This command allows you to view the currently licensed features as well as to assign or change the license for the selected ESXi host.

Host Profile While 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.

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 We'll discuss this in more detail in Chapter 8, but this area allows you to configure how ESXi hosts authenticate users.

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 Within this section, you can disable or specify which datastore should be used for host swapfiles. We will explain host swapping and how it differs from VM swapping in Chapter 11.

Processors In this section, 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; this 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 section, you can see what type of GPU is in the system and how much memory it has. In Chapter 9 you can read about use cases for sharing the GPU of an ESXi host to the guest VMs in certain circumstances.

Power Management The Power Management area in the Hardware section differs from the area under the System section above it. This section allows you to set various power-management policies on the selected ESXi host.

vFlash Resource Management Solid State Drive (SSD)–backed datastores can be allocated to the vFlash resource type in this section. You can then further allocate this resource in the Cache Configuration below.

Cache Configuration This area allows you to specify or view the amount of space on Solid State Drive (SSD)–backed datastores, or vFlash, 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.

NETWORKING SUBSECTION

The following areas are available in the Networking subsection of the Manage 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 in here and within the Network view.

Virtual Adapters The Virtual Adapters area is where you can configure different network interfaces to the ESXi host to use for Management, vMotion, and Fault Tolerance, for example.

Physical Adapters The Network Adapters area in the Hardware section of the Configuration tab provides read-only information on the network adapters that are installed in the selected ESXi host.

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.

STORAGE SUBSECTION

The following areas are available in the Storage subsection of the Manage 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 Adapter area described earlier is more physical in nature.

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 we explained 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.

From 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 will 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.

Perform the following 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 would 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.
5. The Add Host Wizard starts.
6. Supply the hostname, username, and password to connect to the host, just as if you were adding the host manually.
7. When prompted to accept the host's SHA1 fingerprint, click Yes.
8. The next three or four steps in the wizard—three steps for ESX, four steps for ESXi—are the same as adding the host manually. Click Next after each step until you come to the point of scheduling the task.
9. 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 really make sense. Click OK once your scheduler is configured.
10. 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 data-store, and then powering them back on again is quite useful.

Using Events Console in vCenter Server

The Events view in vCenter Server brings together all the events that have been logged by vCenter Server. Figure 3.23 shows the Events view with an event selected.

FIGURE 3.23 The Events view lets you view event details, search events, and export events (highlighted).

You can view the details of an event by simply clicking it in the list. Any text highlighted in blue is a hyperlink; 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, and just on the right below the event list is a button to export the events to a text file. Figure 3.24 shows the dialog box for exporting events.

FIGURE 3.24 Users have a number of options when exporting events out of vCenter Server to a CSV file.

Working with Host Profiles

Host profiles are a powerful feature of vCenter Server. As you'll see in upcoming chapters, there can be a bit of configuration 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 then compare the compliance of that host with the settings outlined in the host profile. If the host is compliant, then you know its settings are the same as the settings in the host profile. If the host is not compliant, then you can enforce the settings in the host profile to make it compliant. This provides administrators 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, select the Home button and then click the Host Profiles icon. Figure 3.25 shows the Host Profiles view in vCenter Server, where a host profile has been created but not yet attached to any hosts.

FIGURE 3.25 Host profiles provide a mechanism for checking and enforcing compliance with a specific configuration.

As you can see in Figure 3.25, there are a number of toolbar buttons across the top of the window, just below the Objects tab. These buttons allow you to perform the following tasks:

• Extract a profile from a host.
• Import a host profile.
• Rename the selected host profile.
• Edit the host profile settings.
• Copy settings from a host.
• Duplicate a host profile.
• Attach/detach host profiles from hosts or clusters.

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.

Perform the following 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. From the home screen, select Host Profiles.
3. Right-click the host profile to be edited, and select Edit Settings.
4. From the tree menu on the left side of the Edit Host Profile window, navigate to Networking Configuration Netstack Instance DNS Configuration.

   Figure 3.26 shows this area.

   FIGURE 3.26 To make changes to a number of ESXi hosts at the same time, put the settings into a host profile, and attach the profile to the hosts.

   

5. Change the values shown in the host profile.
6. Click Next and then 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 much the same. This allows you to quickly create a host profile based on a reference host but 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 simple 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 is a huge advantage for larger organizations that need to quickly deploy new ESXi hosts.

Host profiles are also hugely important when 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, host profiles really start to become beneficial when your environment has a large number of ESXi host to keep things consistent and manageable. However, host profiles are not the only feature included with vSphere that assists with management; a relatively recent addition to help with this is tags.

Tags

Nearly every item within a vCenter inventory can have a label and metadata added to it by the way of tags. 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. Let us explain how this might be useful with an example. Say that you want to know which VMs belong to the engineering team, but also which VMs are production, test, or development. In the section “Understanding Inventory Views and Objects” earlier in this chapter, we explained how you could use folders to organize objects for management and security. The problem with folders is that a VM can reside in only one folder; taking this example, you cannot put a VM in both the Engineering folder and the Production folder. With tags, this problem is solved. While 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. We'll now show you how to create some tags and how they could 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.
3. Click the New Tag icon to open the New Tag pop-up.
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. Select the vCenter server, and give the category a name and a description.
7. Decide if 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.27.
8. Click OK to save the new tag and category.

FIGURE 3.27 You are able to create both tags and tag categories from the New Tag dialog box.

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.28.

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

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.

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.

FIGURE 3.28 You can add metadata to objects by creating and assigning tags.

FIGURE 3.29 After you've defined a category and a tag, you can use it as search criteria for quickly finding objects with similar tags.

Managing vCenter Server Settings

To make it easier for vSphere administrators to find and change the settings that affect the behavior or operation of a vCenter Server instance, VMware centralized these settings into a single area within the vSphere Web Client user interface. This Settings area is found on the Manage tab when a vCenter Server is selected in the vSphere Web Client Navigator. From here you can configure vCenter Server after installation with options that are not provided during installation. The Administration menu contains the following items:

• General
• Licensing
• Message Of The Day
• Advanced Settings

The vCenter Server Settings area lets you change the settings that control how vCenter Server operates, as you'll see in the next section.

General vCenter Server Settings

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

• Statistics
• Runtime Settings
• User Directory
• Mail
• SNMP Receivers
• Ports
• Timeout Settings
• Logging Settings
• Database
• 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.30, 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

FIGURE 3.30 You can customize statistics collection intervals to support broad or detailed logging.

By selecting an interval and clicking the dropdown 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.

There are four Statistics Collection levels 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.

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 timeouts. 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, vCenter Server stores its logs at C:Documents and SettingsAll UsersApplication DataVMwareVMware VirtualCenterLogs (on Windows Server 2003) or C:ProgramDataVMwareVMware VirtualCenterLogs (on Windows Server 2008 and Windows Server 2008 R2).

Database The Database page lets you configure the maximum number of connections to the backend database, and 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.

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. We'll discuss more on SSL certificates in Chapter 8.

Licensing

The Licensing configuration area of the vCenter Server Settings dialog box, shown in Figure 3.31, 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.

FIGURE 3.31 Licensing vCenter Server is managed through the vCenter Server Settings dialog box.

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.

vSphere Web Client Administration

As we explained when outlining the home screen of the vSphere Web Client, there are three distinct areas: Inventories, Monitoring, and Administration. So far we've explained a number of features of the Inventories and Monitoring areas, but we also need to briefly touch on the third category of features, Administration.

There are three areas under the Administration banner, Roles, Licensing, and vCenter Solutions Manager. There is some overlap between these areas and those that come under Inventories.

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. While 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 we explained how you would 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 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 VSPP licensing agreements are all managed through the overall licensing area.

vCenter Solutions Manager

As extensions are added to vCenter Server—such as vSphere Update Manager or vSphere Auto Deploy—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.

The next chapter, Chapter 4, discusses one such extension to vCenter Server, and that is vSphere Update Manager.

Log Browser

The Log Browser feature doesn't come under the Administration banner on the vSphere Web Client home screen (because it's only listed in the Navigator), but just like the Licensing section, this feature gives you an aerial view of all logs within your environment. We explained previously, in the section “Understanding Basic Host Management,” that within the various objects, you can check their individual logs. This command allows you to view, browse, search, and export the logs from vCenter Server and/or one or more ESXi hosts. When you select the Log Browser from the Navigator on the home screen, you can select which object you wish to see the log entries for and the dialog box shown in Figure 3.32 appears.

Perform the following tasks to export system logs out of vCenter Server:

1. With the vSphere Web Client running and connected to a vCenter Server instance, from the home screen, select Log Browser.
2. Select the vCenter Server from the Select An Object dialog box and click OK.
3. Expand the tree and select the datacenter, cluster, or host objects whose logs you want to export.
4. Select the log(s) you want to export. By default, vpxd is selected. Use the drop-down to select the desired log.
5. Click the Actions menu on the top of the content area and select Export.
6. If you want to include all logs, select VMsupport bundle. Click Export.
7. A new browser window will pop up to specify a local path to save the logs.

FIGURE 3.32 You can view logs from vCenter Server or ESXi hosts easily from the Log Browser on the home screen.

In the location you selected, vCenter Server will download hostname_vmsupport.tgz; if you decompress that file, you'll find the system logs for the vCenter Server computer. Figure 3.33 shows some log files exported from vCenter Server.

FIGURE 3.33 These logs are for vCenter Server, a single ESXi host, and the computer running the vSphere Client.

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

The Bottom Line

Understand the components and role of vCenter Server. vCenter Server plays a central role in the management of ESXi hosts and VMs. Key features such as vMotion, Storage vMotion, vSphere DRS, vSphere HA, and vSphere FT are all enabled and made possible by vCenter Server. vCenter Server provides scalable authentication and role-based administration based on integration with Active Directory.

Master It Specifically with regard to authentication, what are three key advantages of using vCenter Server?

Plan a vCenter Server deployment. Planning a vCenter Server deployment includes selecting a backend database engine, choosing an authentication method, sizing the hardware appropriately, and providing a sufficient level of high availability and business continuity. You must also decide whether you will run vCenter Server as a VM or on a physical system. Finally, you must decide whether you will use the Windows Server–based version of vCenter Server or deploy the vCenter Server virtual appliance.

Master It What are some of the advantages and disadvantages of running vCenter Server as a VM?

Master It What are some of the advantages and disadvantages of using the vCenter Server virtual appliance?

Install and configure a vCenter Server database. vCenter Server supports several enterprise-grade database engines, including Oracle and Microsoft SQL Server. Depending on the database in use, there are specific configuration steps and specific permissions that must be applied in order for vCenter Server to work properly.

Master It Why is it important to protect the database engine used to support vCenter Server?

Install and configure the Single Sign-On service. SSO is a major change for the security model of vCenter Server. It allows the vSphere Web Client to present multiple solutions interfaces within a single console provided the authenticated user has access.

Master It After installing vCenter 5.5 and all the appropriate components, an administrator cannot log into the vCenter Server Web Client with his local credentials and gain access to vCenter. What could be missing from the configuration of SSO?

Install and configure the Inventory Service. The vCenter Inventory Service is a caching service that sits between the vCenter database and the vSphere Web Client used to reduce the load on the database and the vCenter Server itself.

Master It A corrupt Inventory database has been discovered in your vCenter server infrastructure and needs to be restored from backup. What data will be lost between when the backup was taken and when the corruption occurred?

Install and configure vCenter Server. vCenter Server is installed using the VMware vCenter Installer. You can install vCenter Server as a stand-alone instance or join a linked mode group for greater scalability. vCenter Server will use a predefined ODBC DSN to communicate with the separate database server.

Master It When preparing to install vCenter Server, are there any concerns about which Windows account should be used during the installation?

Install and configure the Web Client Server. The vSphere Web Client is the next generation of the vSphere client from VMware. Instead of installing a client on every machine used to administer vCenter, simply point a web browser to the Web Server Client Server from any machine.

Master It You have multiple vCenter Server instances within your environment that you wish to manage with the vCenter Web Client. Do you need to install a separate Web Client service for each vCenter server?

Use vCenter Server's management features. vCenter Server provides a wide range of management features for ESXi hosts and VMs. These features include scheduled tasks, host profiles for consistent configurations, tags for metadata, and event logging.

Master It Your manager has asked you to show him all of the VMs and hosts that belong to the accounts department but is not interested in seeing the test servers. What tools in vCenter Server will help you in this task?