Mastering VMware® Infrastructure3

In the majority of today's information systems, the client-server domain environment is king. This is because the client-server domain has the ability to centralize management of resources and to provide end users and client systems with access to those resources in a simplified manner. Imagine, or recall if you can, the days when information systems existed in a flat, peer-to-peer model... when user accounts were required on every system where resource access was needed, and significant administrative overhead was needed simply to make things work. The advent of the domain model brought about tremendous changes in the way we design and manage all the components of our infrastructure. Today we would not think twice about deploying a client-server network infrastructure.

In this chapter you will learn to:

♦ Understand the features and role of VirtualCenter

♦ Install and configure a VirtualCenter database

♦ Install and configure a VirtualCenter Server

♦ Use VirtualCenter topology maps

♦ Plan a VirtualCenter deployment

Introducing VirtualCenter 2.5

As the size of a virtual infrastructure grows, the ability to manage the infrastructure from a central location becomes significantly more important. VirtualCenter 2.5 is a Windows-based application that serves as a centralized ESX Server and virtual machine management tool. VirtualCenter acts as a proxy that performs tasks on the individual ESX Server hosts that have been added as members of a VirtualCenter installation. VirtualCenter is licensed and sold as an optional component in the VI3 product suite. VirtualCenter offers terrific enhancements in the areas of:

♦ Resource management for ESX Server and virtual machines

♦ Template management and virtual machine deployment

♦ ESX Server and virtual machine management

♦ Scheduled tasks

♦ Statistics and logging

♦ Alarms and event management

Figure 5.1 outlines the cores services available through a VirtualCenter installation.

Figure 5.1 VirtualCenter 2.0 is a Windows-based application that allows virtual infrastructure administrators to centrally manage ESX Server hosts and their respective virtual machines.

In a virtual infrastructure with only one or two servers, administrative effort is not a major concern. Administration of one or two servers would not incur incredible effort on the part of the administrator, and the creation of user accounts for virtual infrastructure administrators would not be too much of a burden. In situations like this, VirtualCenter may not be missed from a management perspective, but it will certainly be missed from a feature set viewpoint. In addition to its management capabilities, VirtualCenter offers the ability to perform VMware VMotion, configure VMware Distributed Resource Scheduler (DRS), and establish VMware High Availability (HA). These features are not accessible when ESX Servers act as individual servers running under a host-based license. VirtualCenter should be considered a requirement for any enterprise-level virtualization projects.

As a byproduct of an ever-growing virtual infrastructure, new users will consistently be brought into the environment. These users will likely need various levels of permissions to perform their job. VirtualCenter includes a scalable framework for providing Windows users and groups with varying levels of access to objects throughout the inventory.

VirtualCenter, acting as proxy for host and virtual machine management, does not store the virtual infrastructure data locally on the VirtualCenter server. Instead, all data is stored on a back-end database server that runs either Microsoft SQL Server or Oracle. In the section ‘‘Installing the VirtualCenter Back-end Database’’ later in this chapter, we will dig deeper into VirtualCenter planning. We will discuss the importance of data availability from the database server perspective.

In Chapter 2, we discussed a user's authentication to an ESX Server under the context of a user account created and stored in the Service Console. Without VirtualCenter, a user account on each ESX Server would be required for each administrator who needed access to the server.

VirtualCenter installs on a Windows Server operating system, and uses Windows' user accounts and groups to authenticate to VirtualCenter. These users and groups can reside in the local security accounts manager (SAM) of VirtualCenter, or they can belong to the Windows Active Directory domain to which VirtualCenter server belongs. For example, if a user account named Shane is created in the Service Console of an ESX Server host named silo3504.vdc.local and the user account is granted the permissions necessary to manage the host, Shane will not be able to utilize the Virtual Infrastructure Client connected to VirtualCenter to perform his management capabilities. The inverse is also true. If a Windows user account named Elaine is granted permissions through VirtualCenter to manage an ESX Server host named silo3505.vdc.local, then Elaine will not be able to manage the host by using the Virtual Infrastructure Client to connect directly to the ESX Server. Figure 5.2 exemplifies the authentication agents when using the Virtual Infrastructure client to connect to an ESX Server host or a VirtualCenter Server.

Figure 5.2 The Virtual Infrastructure client can be used to connect directly to an ESX Server under the context of a Service Console (Linux) user, or it can be used to connect to a VirtualCenter under the context of a Windows user.

The VirtualCenter component of VI3 is the most extensible in regard to allowing third-party support. Some of these applications will be covered in Appendix A. Figure 5.3 shows the many components that revolve around the core services of VirtualCenter 2.5.

Figure 5.3 Although the foundation of virtual infrastructure is the ESX Server product, it is VirtualCenter that provides enhanced functionality and added features like HA, DRS, and VMotion as well as centralized management.

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. VMware has shown its interest in allowing third-party software development houses to play an integral part in virtualization by providing an application programming interface (API) to VirtualCenter. This API allows companies to develop custom applications that can take advantage of the virtual infrastructure created in VirtualCenter. For example, Vizioncore's vRanger Pro, a product we will look at in our appendix of tools, is a simplified backup utility that works off the exact inventory created inside VirtualCenter to allow for advanced backup options of virtual machines.

This chapter will cover the installation, configuration, and management of VirtualCenter. In addition, you will find helpful information about best practices for VirtualCenter maintenance, availability, and disaster recovery. A detailed look at templates will be provided in Chapter 6, and Chapter 11 will offer an in-depth look at ESX Server and virtual machine monitoring.

Installing the VirtualCenter Back-end Database

By now, you have a good understanding of the importance of VirtualCenter in a large enterprise environment. As noted in the introduction to this chapter, all things VirtualCenter are stored in a back-end database. So the truth is that the back-end database, not so much the front-end VirtualCenter, is the key component. Without the back-end database, you will find yourself rebuilding an entire infrastructure. Figure 5.4 illustrates the components of a typical Virtual Server infrastructure.

Figure 5.4 VirtualCenter acts as a proxy for managing ESX Server 3.0 hosts. All of the data for Virtual-Center is stored in an external database.

VirtualCenter Business Continuity

Losing the server that runs VirtualCenter might result in a small period of downtime; however, losing the back-end database to VirtualCenter could result in days of downtime and extended periods of rebuilding.

As with most enterprise-level databases that store critical company data, you will want to take especially good care of and take precautions with the VirtualCenter database. Whether this means building the database on a server cluster that provides high availability, or developing a rock-solid backup strategy to ensure smooth and timely restore in the event of loss, measures must be taken to guarantee access and availability of VirtualCenter data.

In light of the sensitive and critical nature of the data in the VirtualCenter database, VMware will only support VirtualCenter issues with back-end databases on enterprise-level database applications. VirtualCenter 2.0.1 supports the following database applications:

♦ Oracle 9i

♦ Oracle 10g

♦ Microsoft SQL Server 2000 with Service Pack 4

♦ Microsoft SQL Server 2005 with Service Pack 1

♦ Microsoft SQL Server Desktop Engine (MSDE)

VirtualCenter Database Support

SQL Server 2005 Service Pack 1 is not supported on VirtualCenter 2.0.0. To use SQL Server 2005 Service Pack 1 as the back-end database for VirtualCenter, you must be running VirtualCenter 2.0.1 or higher.

For administrative purposes, you might find it easy to install the database application and the VirtualCenter application on the same computer. This configuration, however, is not considered best practice as you would then have a single point of failure for two core components of the virtual infrastructure. The more common, and recommended, infrastructure design includes deploying VirtualCenter and its back-end database on two different computers. Later in this chapter we will explore some options for building a highly available VirtualCenter installation.

Connecting VirtualCenter to its back-end database requires that an Open Database Connectivity (ODBC) connection be created on VirtualCenter. The ODBC connection should be created under the context of a database user who has full rights and permissions to a database that has been created specifically for storing VirtualCenter data.

open_cursors - 300 to the C:\Oracle\Admin\VPX\pfile\init.ora

CREATE TABLESPACE vc DATAFILE 'C:\Oracle\ORADATA\VPX\vpx.dat' SIZE 250M;

CREATE USER vdcdbuser IDENTIFIED BY vdcdbuser DEFAULT TABLESPACE vc;

VPX =

(Description =

(Description

(AddressList=

Address=(Protocol=TCP)(Host=vpxd-Oracle)(Port1521)))

Host =

Working with Microsoft SQL Server Databases

In light of the existing widespread deployment of Microsoft SQL Server 2000 and Microsoft SQL Server 2005, it is most common to find SQL Server as the back-end database for VirtualCenter. 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 back-end for VirtualCenter.

Using SQL Server 2005 Express Edition

With the introduction of VirtualCenter 2.5, SQL Server 2005 Express Edition is now the minimum database available as a back-end to VirtualCenter. In fact, SQL Server 2005 Express Edition has replaced the MSDE option for demo or trial installations.

Microsoft SQL Server 2005 Express Edition, like MSDE, has physical limitations that include:

♦ 1 CPU maximum

♦ 1GB of maximum of addressable RAM

♦ 4GB database maximum

Large virtual enterprises will quickly outgrow these SQL Server 2005 Express edition limitations. Therefore, you might assume that any virtual infrastructures using SQL Server 2005 Express Edition are smaller deployments with little projections, if any, for growth. VMware suggests the use of SQL Server 2005 Express Edition only for VI3 deployments with 5 or fewer hosts and 50 or fewer virtual machines.

Connecting VirtualCenter to a Microsoft SQL Server database, like the Oracle implementation, requires some specific configuration steps. The SQL Server computer must be configured in Mixed Mode authentication, as shown in Figure 5.5. This setting allows authentication to be performed by either Windows or SQL Server (see the sidebar “Windows Authentication vs. SQL Server Authentication”). Once you configure the SQL Server to allow the appropriate authentication, you must create a new database for VirtualCenter. Finally, you must create a SQL Server user account that has full access to the database you created for VirtualCenter. You can easily set the appropriate permissions for the account by making the account a member of the db_owner database role, as shown in Figure 5.6.

Figure 5.5 Using SQL Server 2000 or SQL Server 2005 requires that the database server allow Windows and SQL Server Authentication.

Take these steps prior to creating the ODBC connection to the SQL Server database. Using SQL Server 2005 requires not only that the account have dbo (db_owner) privileges, but that the account created actually own the database. In addition, the account used by VirtualCenter to access the SQL Server 2005 database must have membership in the db_owner database role in the msdb for the duration of the installation process. Figure 5.7 shows the creation of a new SQL Server 2005 database with the default owner changed to a custom SQL Server user account.

Figure 5.6 The user account VirtualCenter uses to access the back-end SQL 2000 Server database requires database owner privileges to build the table structure and populate the tables with data.

Figure 5.7 SQL Server 2005 databases used by VirtualCenter must be owned by the account Virtual-Center uses to connect to the database.

SQL Server 2005 Permissions

Not only will most database administrators cringe at the thought of over extending privileges to a SQL Server computer, it is not good practice to do so. As a best and strong security practice, it is best to minimize the permissions of each account that access the SQL Server computer. Therefore, in the case of the VirtualCenter 2.5 installation procedure, you will need to grant a SQL Server user account the db_owner membership on the MSDB database. However, once the installation is complete this role membership can be removed, and should be removed. Normal day-to-day operation of and access to the VirtualCenter database does not require this permission. It is a temporary requirement needed for the installation of VirtualCenter 2.5.

If you have an existing SQL Server 2005 database that needs to be used as the back-end for VirtualCenter, you can use the sp_changedbowner stored procedure command to change the database ownership accordingly. For example, EXEC sp_changedbowner @loginame='vcdbuser', @map=' true' would change the database owner to a user account named vcdbuser.

Windows Authentication vs. SQL Server Authentication

Microsoft SQL Server, both the 2000 and 2005 versions, supports two methods of authentication: Windows and SQL Server. While a default installation of SQL Server will allow only the Windows authentication method, this setting can be changed and in some cases, as with VirtualCenter, must be changed. Figure 5.8 shows a SQL Server 2005 server configured to allow Windows and SQL Server authentication, or what is often called Mixed Mode authentication.

Windows Authentication, as the name implies, involves authentication at the operating system level. The Windows operating system checks the username and password for a user attempting to use SQL Server. The SQL Server then only looks at the user's identity, including group memberships, to determine the level of access allowed to the SQL Server.

SQL Server authentication removes the Windows aspect of the authentication leaving the SQL Server to check the requesting user's username and password. SQL Server authentication is most commonly used when connecting non-Windows clients to a SQL Server database.

SQL Server 2000 and SQL Server 2005 can be configured to allow Windows-only authentication or to allow Windows and SQL Authentication (Mixed Mode), but there is no way to enforce a SQL Server authentication-only mode.

The configuration necessary to allow VirtualCenter to communicate with SQL Server is not an uncommon one and should result in little resistance from seasoned database administrators. In some cases, however, company policy may prevent the use of SQL Server authentication on specific SQL Servers or perhaps entirely. In this case, administrators might have to install and configure a new SQL Server computer or SQL instance to host the VirtualCenter database. If your company policy does not allow SQL Authentication to be used anywhere on the network, you will have to install SQL Server on the same computer as VirtualCenter. Figure 5.8 illustrates the scenarios in which VirtualCenter and SQL Server can communicate.

Figure 5.8 Authentication from VirtualCenter to SQL Server must use SQL Authentication for a SQL Server user account; however, if VirtualCenter and SQL Server are on the same computer, a Windows user account can be used for authentication.

VirtualCenter Authentication to SQL Server

VirtualCenter will only support the Windows Authentication method to a SQL Server if VirtualCenter and SQL Server are installed on the same computer.

Once your database is setup you can create the ODBC connection to be used during the VirtualCenter Server installation wizard. If using SQL Server 2000, the ODBC connection can be created with the SQL Server driver. However, using SQL Server 2005 requires use of the SQL Native Client. Figure 5.9 shows both options available in the Create New Data Source wizard.

Figure 5.9 ODBC connections to SQL Server 2005 require the SQL Native Client driver.

If you do not find the SQL Native Client option during the creation of the ODBC Connection string you can download it from Microsoft's Web site or install it off of a SQL Server 2005 installation CD-Rom.

On the server where VirtualCenter will be installed perform the following steps to create an ODBC connection to a SQL Server 2005 database:

1. Open the Data Sources (ODBC) applet from the Administrative Tools menu.

2. Select the System DSN tab.

3. Click the Add button.

4. 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 it can be downloaded from Microsoft's Web site.

5. The Create New Data Source to SQL Server dialog box will open. In the Name text box, type the name you want to use to reference the ODBC connection. This is the name you will give to VirtualCenter to establish the database connection.

6. In the Server drop down list, select the SQL Server 2005 computer where the database has been created.

7. Click the Next button.

8. Select the With SQL Server authentication using a login ID and password entered by the user radio button.

9. Enter the username and password for the SQL Server authenticated user account that has the appropriate permissions to the VirtualCenter database and the MSDB database.

10. Click the Next button.

11. If the default database is listed as Master select the Change the default database to: check box and then select the name of the VirtualCenter database as the default. The appropriate database might be selected if the SQL Server user account was configured with the VirtualCenter database as the default.

12. Click the Next button.

13. Click the Finish button.

14. Click the Test Data Source button to test the ODBC connection.

15. Click the OK button twice.

Migrating from MSDE Databases

VirtualCenter and MSDE

VMware does not support MSDE or SQL Server 2005 Express Edition databases as the back-end database for production VirtualCenter installations.

Older versions of VirtualCenter (pre VC 2.5) were able to use the free Microsoft SQL Server Desktop Engine (MSDE) as the back-end database for a VirtualCenter installation, however doing so would not earn support from VMware. The use of MSDE as a VirtualCenter database should be restricted to demonstration or development implementations where loss of data or excess downtime is not a major concern.

If the threat of nonsupport isn't enough to scare you away from relying on MSDE for production environments, perhaps knowing the limitations of MSDE will. The MSDE database, though robust enough to support development, test, and training environments for previous VirtualCenter versions, is hard-coded with a database size limit of 2GB and maximum RAM use of 2GB.

If you use an MSDE database simply to get your virtual infrastructure up and running without incurring the administrative or financial overhead of a full-blown SQL Server 2005 computer, it's possible to make the transition later. Use the following procedure to move an MSDE or SQL Server 2000 database to SQL Server 2005e:

1. Stop the SQL Server service on the existing VirtualCenter that runs the MSDE database.

2. Copy the *.mdf and *.ldf for the respective VirtualCenter database to a directory on the SQL Server 2005 computer.

3. Open the SQL Server 2005 Management Studio on the SQL Server computer. Authenticate to the local SQL Server installation and navigate through the tree structure to find the imported database.

4. Right-click the databases node and select the Attach option.

5. In the Attach Databases window, select the MDF file for the database you wish to attach.

6. Modify the database owner to match the name of the user account that VirtualCenter uses in its ODBC connection, as shown in Figure 5.10.

7. Perform a simple query against the VPXHOST table, as shown in Figure 5.11.

Figure 5.10 Attaching an MSDE database requires selecting the appropriate database files and assigning a new database owner to match the name on the user account used by VirtualCenter.

Figure 5.11 A simple query against the VPXHOST table is a good way to test that your data migration process is complete.

Microsoft Access

Microsoft Access is no longer supported as the back-end database for any installation of VirtualCenter.

ESX 3.5 and VirtualCenter 2.5 Licensing Strategies

The latest release of the VirtualCenter application, VirtualCenter 2.5, includes significant enhancements that make it much more powerful than any of the previous versions. The new features include VMware Update Manager, a built-in Vmware Converter tool, expanded licensing options, and more. The installation of VirtualCenter 2.5 requires a system with the following minimum hardware specifications:

♦ 2.0 GHz processor or faster

♦ 2 GB of RAM or more

♦ 560 MB of free disk space or more

♦ A network adapter (preferably gigabit)

♦ Windows 2000 Server with Service Pack 4 or Windows Server 2003 with Service Pack 1 or Windows Server 2003 R2

♦ Internet Explorer 5.5 or higher

Table 5.1: Features of ESX Server Editions

Large enterprise environment with many ESX Server hosts and virtual machines should scale the VirtualCenter server accordingly. In addition, if your VirtualCenter computer will also function as the database server, the hardware specifications should be adjusted to support the additional overhead.

In Chapter 2 on installation we did not spend much time on licensing because the reality of the virtual environment is that server based licensing will be the dominate scenario. VirtualCenter 2.5 combined with ESX Server 3.5 introduces a new line of licensing options for VMware Infrastructure 3. This new strategy makes virtualization readily available to the small and medium businesses by making the licensing more affordable for those types of environments. Table 5.1 outlines the features available with each of the new ESX 3.5 editions.

The host-based licensing configuration for ESX sets limitation that result in the inability to have floating licenses and, more importantly, the inability to use the advanced VMotion, DRS, and HA features of ESX and VirtualCenter. As previously mentioned, managing ESX servers individually becomes an administrative hassle as the number of servers is increased. Once the decision is made to move away from the individual host management, the first step in moving to a more centralized model is to install VirtualCenter Server's back-end database. (See the previous section for more about this.) Once the database is ready to go, the next step is to install the VMware License Server. The license server is most commonly installed on the same computer that will run VirtualCenter, though that approach is not mandatory. The VMware License Server will allow the migration from host-based licensing to a centralized license repository, where licenses can float between ESX hosts. Figure 5.12 illustrates the difference between a host-based licensing strategy and a server-based licensing strategy.

Figure 5.12 VMware ESX Server computers can be licensed individually with host-based licensing or can share a license repository using the VMware License Server.

VirtualCenter 2.5 can be deployed with either of the following license types:

♦ VirtualCenter Foundation edition

♦ VirtualCenter edition

Earlier I mentioned some changes to the VI3 licensing strategy that made virtualization on VMware products more readily available to smaller network environments. The VirtualCenter Foundation edition is the licensing option for the small and medium business. This edition allows for managing a maximum of three ESX server hosts. Although they can be purchased separately, VMotion, DRS, and HA are not available with the Foundation Edition of VirtualCenter 2.5. VC Foundation with three years of platinum support retails for $3,140.

The VirtualCenter edition of VirtualCenter 2.5 (I know it sounds weird) is the larger enterprise version that is not limited to only three hosts. All of the enterprise features of VMotion, DRS, and HA are supported. VirtualCenter Server Virtual Center edition (still weird) with three years of platinum support retails for $8,180.

Starting out your virtual infrastructure with the Foundation edition of VirtualCenter or ESX Server does not lock you into those editions. As your virtual infrastructure grows, and potentially outgrows the Foundation Edition, you can purchase upgrades for the VirtualCenter Server and ESX Server products. Naturally these upgrades will include the additional features and functionality as outlined in Table 5.1.

The options and features available to you are dependent on the license file that is configured for use by the licensing server. License keys are able to open up or prevent features. With the exception of the VirtualCenter 2.5 product, all other products and features of the VI3 suite are licensed on a per-processor basis. This includes ESX Server, VMotion, Storage VMotion, HA, DRS, and VCB.

You can obtain a VMWare your server licenses by visiting the website (http://www.vmware.com) and entering the activation codes provided. The FLEXnet licensing, as it is called, lets you combine and download licenses to ensure the target ESX Server infrastructure works correctly. Figure 5.13 shows the license management website, and Figure 5.14 shows a sample license file obtained from the site.

Figure 5.13 Licenses can be combined on VMware's website and then downloaded and installed to a license server.

Figure 5.14 This sample server.lic file is human readable, is shared by all virtual machines, and has more items appended to it.

Even after the license server is installed, there may come a time when a company outgrows an existing license and must download and install a new license. Figure 5.15 shows one of the tabs available in the LMTOOLS licensing tool (a Macrovision product installed with VMware) used to start, stop, and read license files.

Growing a VI3 deployment is quite easy because VMware has constructed the product to use a license directory as opposed to a single file. Certainly, as you will soon see, you can specify a single license file during the installation of VirtualCenter, however, adding new licenses to support more ESX Server hosts requires downloading a new license and saving it to the C:\Program Files\VMware\VMware License Server\Licenses directory on the licensing server. After a restart of the VMware License Server service the new licenses will be effective.

Many IT professionals have the misconception that using a centralized license server introduces a single point of failure for which we so diligently try to maintain high availability. In the event that an ESX host is unable to communicate with a license server, there will be a 14-day grace period during which all network management practices and virtual machines will continue to run. At the end of the 14 days, additional restrictions are imposed. Tasks that are not permitted after the 14-day grace period has expired include:

♦ Turning on a virtual machine

♦ Restarting virtual machines that failed because of a failed host that belongs to a DRS cluster

Tasks that are not permitted once the licensing server becomes unavailable include:

♦ Adding an ESX host to inventory

♦ Moving an ESX host into a VMotion/HA/DRS cluster

♦ Adding/removing licenses

Some of the more common tasks that are still permitted once the license server becomes unavailable include:

♦ Creating and deleting virtual machines

♦ Suspending and resuming virtual machines

♦ Turning an ESX host on or off

♦ Configuring an VirtualCenter or ESX host using the VI Client

♦ Removing an ESX host from inventory

♦ Maintaining DRS automated efficiency

Figure 5.15 The LMTOOLS program allows you to update server-based licenses when you want to add more licenses to your virtual infrastructure.

While a licensing server can be installed on its own, it is more convenient to install it as part of the VirtualCenter installation procedure. If you wish to install the licensing server separately, use VMware-licenseserver.exe in the \vpx directory of the VirtualCenter installation folder (VMware-VIMSetup-2.5.0-xxxxxx).

Installing VirtualCenter 2.5

With the database in place and a solid understanding of the licensing options, you can now install and properly configure VirtualCenter. Once you've done that, you can add servers and continue the configuration of your virtual infrastructure.

The VirtualCenter 2.5 installation takes only a few minutes and is not administratively intensive, assuming all of the pre-installation tasks have been completed. The VirtualCenter 2.5 installation can be started by double-clicking autorun.exe inside the VirtualCenter installation directory.

After a brief overview of the benefits of VirtualCenter the installation will continue through the acceptance of a license agreement and the provision of the organization information. At this point, you must select the role to be played by the server. As shown in Figure 5.16, the installation procedure offers the following installation types:

♦ VMware Infrastructure Client

♦ VMware VirtualCenter Server (default)

♦ Custom

Figure 5.16 VirtualCenter Server installation types provided during the installation wizard.

Selecting the Custom option leads to a components selection screen shown in Figure 5.17. This page of the installation wizard offers the following component selections which are all selected by default:

♦ VMware Infrastructure Client

♦ VMware VirtualCenter Server

♦ VMware Update Manager

♦ VMware Converter Enterprise for VirtualCenter

Figure 5.17 Custom options are available during the VirtualCenter installation wizard to allow for selection of individual components.

The latter two options in the list are new features of VirtualCenter 2.5. Chapter 12, “Securing and Managing a VMware Virtual Infrastructure” and Chapter 7, “Migrating and Importing Virtual Machines” will provide more detail on the VMware Update Manager and VMware Converter Enterprise features respectively.

The next step in the installation process is to identify the location of the back-end database. Figure 5.18 shows the two options of installing a local database on SQL Server 2005 Express Edition or using an existing (separate or local) database server. The Use existing database server option should be selected for remote back-end SQL Server 2000/2005 or Oracle databases.

After successfully connecting to a pre-configured VirtualCenter database running on SQL Server 2005, you will receive a warning message regarding the database being set to the Full recovery model. The warning message continues on identifying that this model runs the risk of growing large transaction logs for the VirtualCenter database. The knowledge base article identified in the warning message suggests reconfiguring the VirtualCenter 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 backup transaction logs for the VirtualCenter database. If you leave the database set to Full recovery, be sure to work with the database administrator to routinely backup and truncate the transaction logs. By having transaction log backups from a database in Full recovery you will 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 taking consistent full backups of the database, but understand that you will only be able to recover to the point of the last full backup as transaction logs will be unavailable.

Figure 5.18 The VirtualCenter installation wizard provides options for installing a local SQL Server 2005 Express Edition instance or using an existing database server running SQL Server 2000/2005 or Oracle.

The next step in the VirtualCenter installation wizard is to select the VirtualCenter License Server configuration. The default setting on this page is a new option that allows a 60-day evaluation mode, shown in Figure 5.19. This new option allows administrators that are interested in virtualization to deploy test or proof-of-concept environments that support all of the features of VI3. The Virtual Infrastructure client will reflect the number of days remaining in the evaluation period. Once the evaluation period has expired, you can purchase license to install, thereby allowing you to maintain all of the work performed to assemble the evaluation environment.

Opting out of the evaluation mode by deselecting the option opens up the ability to choose between using and existing licensing server, shown in Figure 5.20, or to install a new licensing server as shown in Figure 5.21. An existing licensing server is references by 27000@ to indicate the licensing port of 27000 and the host functioning as the licensing server. If the local system is also the licensing server then the name localhost can be used in place of the actual host name. By not selecting the Use an Existing License Server option, you will need to browse to find a license file that has been obtained from the VMware Web site. In either case you must also select the appropriate edition of VirtualCenter from the Management Server and Foundation Management Server options.

By default VirtualCenter is setup to use a set of default ports for the various types of communication it engages in, as shown in Figure 5.22. These default ports include:

♦ Port 80 for the HTTP Web Service

♦ Port 443 for the HTTPS Web Service

Figure 5.19 A new 60-day evaluation mode is available for VirtualCenter.

Figure 5.20 An existing license server is referenced by using @hostname syntax.

♦ Port 902 (UDP) for the Heartbeat

♦ Port 8086 for the Web Server management (running on Apache Tomcat)

Although these ports can be altered but it is not recommended to do as it would incur additional administrative overhead in ensuring that all other application accessing VirtualCenter were aware of the port alterations.

Figure 5.21 The system where VirtualCenter is being installed can be configured as the licensing server by browsing for the appropriate downloaded .LIC file.

Figure 5.22 VirtualCenter ports are defined for the various types of management communication.

VirtualCenter extensions add new functionality in the areas of ESX Server updates management and consolidation assistance. Figure 5.x shows the configuration of administrative credentials in support of the installation of the VMware Converter Enterprise for VirtualCenter Server and VMware Update Manager extensions. Later in this chapter we will discuss enabling and configuring these new extensions.

The VMware Update Manager maintains data in its own back-end database. The next page of the installation wizard identifies a local or remote database to be used by the VMware Update Manager. Similar to the VirtualCenter database, there is an option for installing SQL Server 2005 Express Edition or for using an existing remote database. If you wish, you can even use the same database used for VirtualCenter.

Figure 5.23 New extensions available in VirtualCenter 2.5 allow for VMware Update Manager and VMware Converter Enterprise to be integrated into VirtualCenter.

The VMware Update Manager installation includes some additional configuration for the SOAP and Web ports to be used for the downloading of updates. As shown in Figure 5.24, you can also enable and configure a proxy server for use by the VMware Update Manager.

Figure 5.24 VMware Update Manager ports are used to download ESX Server updates directly from the VMware Web site.

After the configuration of the VMware Update Manager the next page in the wizard, shown in Figure 5.25, allows for the ports configuration for the VMware Converter Enterprise that is now built into VirtualCenter.

Figure 5.25 VMware Converter Enterprise is now built into VirtualCenter for facilitating consolidation of physical serves into virtual machines.

Upon completion of the VirtualCenter installation, browsing to VirtualCenter's URL (http:// or http://) will turnup a page that allows for the installation of the VI Client, or the use of a web-based tool for managing the individual virtual machines hosted by the ESX Server 3.0 hosts within the VirtualCenter inventory. Figure 5.26 shows a sample home page for VirtualCenter.

The VI Client connected to VirtualCenter should be the primary management tool for managing ESX Server 3.5 hosts and their respective virtual machines. The VI Client can connect directly to ESX Server 3.5 hosts under the context of a user account defined in the Service Console, or it can connect to a VirtualCenter server under the context of a Windows user account defined in Active Directory or the local security accounts manager (SAM) of the VirtualCenter computer.

Figure 5.26 The home page of an ESX Server host or a VirtualCenter both offer a download of the VI Client and a web access login.

VirtualCenter is a critical application for the management of your virtual infrastructure. Its implementation should be carefully designed and executed to ensure availability and data protection.

As a virtual infrastructure administrator, you should be familiar with the default states of these services. In times of troubleshooting, check the status of the services to see if they have changed. Keep in mind the dependencies that exist between VirtualCenter and other services on the network. For example, if the VirtualCenter Server service is failing to start, be sure to check that the system has access to the SQL Server (or Oracle) database. If VirtualCenter cannot access the database due to lack of connectivity or the database service not running, then it will not start. Perform the following steps to install VirtualCenter 2.5 and all of the additional licensing and extension components:

1. Ensure that the appropriate ODBC connections have been created for connectivity to the VirtualCenter database and the VMware Update Manager Database.

2. Initiate the VirtualCenter 2.5 installation from a CD-ROM or a downloaded set of files. If the files have been downloaded from the http://www.vmware.com/download site the installation can be initiated by double-clicking the autorun.exe file in the Vmware-VIMSetup-2.5.0-xxxxx folder.

3. Once the VMware Infrastructure Management installation wizard appears click the Next button.

4. Click the Next button after reviewing the introduction page that highlights the features of VirtualCenter.

5. Select the I accept the terms in the license agreement radio button and then click the Next button.

6. Provide a User Name and Organization in the appropriate text boxes and then click the Next button.

7. Select the VMware Infrastructure Client radio button to install only the management client, select the VMware VirtualCenter Server radio to accept the defaults of all options, or select the Custom radio button to choose which options to be installed. Choosing the custom option allows for choosing between the following:

♦ VMware Infrastructure Client

♦ VMware VirtualCenter Server

♦ VMware Update Manager

♦ VMware Converter Enterprise for VirtualCenter Server

8. On the VMware VirtualCenter Server Deployment Options-Step 1 page select the appropriate database option. Choose SQL Server 2005 Express for small deployments or demo installation. Choose use an existing database server for enterprise deployments that will use SQL Server 2005 or Oracle.

9. If using SQL Server 2005 or Oracle provide the ODBC data source name and the appropriate user account information. For SQL Server 2005 this is the SQL user account that has been granted ownership of the VirtualCenter database and db_owner database role for the MSDB database. It is also the use account used for the creation of the ODBC connection to the SQL Server 2005 computer.

10. Click the OK button if your receive the following warning message:

11. Please make sure SQL Server Agent service is running on the database server.

12. If the SQL Server 2005 database has been left with the default configuration it will be set to Full Recovery model and a warning message will appear, click the OK button. The warning will suggest a VMware knowledge base article that will direct you to change the recovery model to Simple. If you are unsure of the ramifications of doing this please revisit an earlier section of this chapter where we discussed the Full versus Simple recovery model. Or ask your friendly neighborhood database administrator.

13. On the VMware VirtualCenter Server Deployment Options-Step 2 page select the appropriate licensing strategy. The default selection will allow a 60 day evaluation. It is also possible to select the use of an existing licensing server or to configure the local server as a licensing server by using the Browse button to find a valid server-based licensing license file. If you choose to use and existing license server or configure the local server as a licensing server select the VirtualCenter edition from the drop down list. It is important to select the version that matches the license you have purchased else you will have to reconfigure VirtualCenter after installation. You can revisit the earlier section of this chapter that discussed the differences in licensing.

14. If the installation is being installed to use the 60 day trial you will receive an information box regarding the trial period. Click the OK button to continue.

15. On the VMware VirtualCenter Server Deployment Options-Step 3 page click the OK button to accept the default VirtualCenter port configuration. The ports can be edited if conflicts might occur with existing applications using similar ports. You should avoid altering the default port settings.

16. On the VirtualCenter Server Authorization page provide the administrative credentials necessary for VirtualCenter to install the VirtualCenter extensions. Click the Next button to continue.

17. On the VMware Update Manager Deployment Options-Step1 page, select the appropriate back-end database option for use by the VMware Update Manager. Provide the appropriate ODBC connection name and corresponding username and password. Once again a warning regarding the database recovery model might be presented. Click the OK button to proceed past the warning, then click the Next button to continue.

18. On the VMware Update Manager Deployment Options-Step 2 page configure the appropriate name and port setting for the VMware Update Manager to use. You should avoid altering the default port settings. Click the Next button to continue.

19. On the VMware Converter Enterprise Deployment Options page configure the appropriate name and port setting for use by the VMware Converter built into VirtualCenter. You should avoid altering the default port settings. Click the Next button to continue.

20. On the Destination Folder selection page configure the installation directory for VirtualCenter and its components and the directory for storing updates downloaded by VMware Update Manager. Click the Next button to continue.

21. Click the Install button to initiate the installation.

22. After the installation is complete use the VMware Virtual Infrastructure Client to connection to the VirtualCenter Server installation.

Creating and Managing a VirtualCenter Inventory

Upon first connecting to VirtualCenter you will notice a getting started tab that facilitates the construction of a new datacenter. The starting point for the VirtualCenter inventory is called the root, while the building block of the VirtualCenter inventory is called a datacenter object. Along with the link for creating new data is a set of links to help you quickly find more information about getting the VirtualCenter up and running. The links in the Explore Further menu include:

♦ Learn more about inventory views

♦ Learn more about virtualization

♦ Learn more about datacenter

From the Hosts & Clusters node in the inventory tree, there are several tabs across (see Figure 5.27) for reviewing data about all objects beneath the Hosts & Clusters view root. Within each tab you can right click the column headers and select additional data to be reviewed or existing data to be removed. In addition to the Getting Started tab, the tabs available from the Hosts & Clusters root include:

♦ Datacenters-viewing all datacenter objects as well as the number of hosts and virtual machines within

♦ Virtual Machines-provides a list of virtual machines within the root as well as performance data, state, and host.

♦ Hosts-provides a list of each host within the root as well as performance data and state of each host.

♦ Tasks & Events-provides a listing of the most recent tasks and events that have taken place

♦ Alarms-displays a list of alarms that have been defined to fire for each host or VM within the root

♦ Permissions-provides information and configuration capability for delegating authority at the root level

♦ Map-provides a tool for reviewing the virtualization architecture and the relationships between the various components.

Figure 5.27 Hosts & Clusters is the root of the VirtualCenter management utility.

VirtualCenter is a dynamic application in that when a different object in the inventory is selected, the available tabs become customized for the selected object. For example, when an ESX Server host is selected in the inventory the available tabs change to reflect the administrative tasks and data for the host, shown in Figure 5.28. The tabs available when a host is selected include:

♦ Summary

♦ Virtual Machines

♦ Resource Allocation

♦ Performance

♦ Configuration

♦ Tasks & Events

♦ Alarms

♦ Permissions

♦ Topology Maps

Figure 5.28 VirtualCenter management tools are dynamic. The tools change based on the object selected from the inventory.

Prior to adding a host to a VirtualCenter inventory, you must create a datacenter object. Keep in mind that the naming strategy you provide for the objects in VirtualCenter should mirror the way that network management is performed. 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 VirtualCenter inventory will be a hybrid that involves management by geography, department, server type, and even project title.

The VirtualCenter 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. Figure 5.29 shows a Hosts & Clusters view of a VirtualCenter inventory that is based on a geographical management style.

Figure 5.29 The VirtualCenter inventory should reflect a company's IT management needs. Folders can be created above the datacenter object to grant permission at a level that can propagate to multiple datacenter objects, or folders can be created beneath a datacenter to manage the objects within the datacenter.

Figure 5.30 A departmental Virtual-Center inventory allows the IT administrator to implement controls within each organizational department.

In most enterprise environments, the VirtualCenter 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.

Along the top of the VirtualCenter user interface there are six menu buttons for changing the scope of management in VirtualCenter. The buttons include:

♦ Inventory-menu selection for changing the list of inventory objects

♦ Scheduled Tasks-menu selection for creating a job to be executed

♦ Events-a look at recent events that have occurred in the VirtualCenter deployment

♦ Administration-menu selection for accessing VirtualCenter data about roles, sessions, licenses, and VirtualCenter logs

♦ Maps-menu selection for reviewing topology maps for selected inventory objects

♦ Consolidation-menu selection for managing the guided consolidation feature in VirtualCenter

The VirtualCenter application has four views, accessible from the Inventory drop down list, that can be used to shift the focus between the various components in the virtual infrastructure:

♦ Hosts & Clusters

♦ Virtual Machines & Templates

♦ Networks

♦ Datastores

Each of the views has a distinct advantage because they can filter out unnecessary objects to allow administrators to concentrate on one particular aspect of the virtual infrastructure. Figure 5.31 compares three of the VirtualCenter views.

Figure 5.31 Each of the views available through VirtualCenter provide an insight into some aspect of the virtual environment.

The VirtualCenter inventory is the framework built to deliver a management infrastructure for hosts, virtual machines, and templates. Hosts are added to VirtualCenter under the context of the root user account, as shown in Figure 5.32. At this point, a new VirtualCenter agent service is installed on the ESX Server host. This new service is installed with the name vpxa and is responsible for VirtualCenter to ESX Server communication. All subsequent connections from a VirtualCenter server to an ESX Server 3.0 host happen under the context of a vpxuser account created by root when the new host is added to the inventory.

Figure 5.32 Adding an ESX Server 3.5 host into a VirtualCenter under the context of root allows root to create a new user account named vpxuser that will be used for all subsequent logins and actions.

Chapter 8 will describe the security model of VirtualCenter that will work hand-in-hand with the management-driven inventory design.

From the Scheduled Tasks menu you can create jobs to run based on a defined logic. The list of tasks that can be scheduled include:

♦ Change the power state of a virtual machine

♦ Clone a virtual machine

♦ Deploy a virtual machine

♦ Move a virtual machine with VMotion

♦ Relocate a virtual machine

♦ Create a virtual machine

♦ Make a snapshot of a virtual machine

♦ Add a host

♦ Export a virtual machine

♦ Import a virtual machine

The data to be provided for each task varies and therefore each of the wizards that results from the task selection is unique in its own way.

Using VirtualCenter Topology Maps

The new Maps feature of VirtualCenter is a great tool for quickly infrastructure. Topology maps graphically represent the relationship that exists between different types of objects in the virtual infrastructure. The maps can display any of the following relationships:

♦ Host to Virtual Machine

♦ Host to Network

♦ Host to Datastore

♦ Virtual Machine to Network

♦ Virtual Machine to Datastore

In addition to defining the relationships to display, you can include or exclude specific objects from the inventory. Perhaps you are only interested in the relationship that exists between the virtual machines and the networks that are on a single host. In this case, you can exclude all other hosts from the list of relationships by deselecting their icons in the VirtualCenter inventory. Figure 5.33 shows a series of topology maps that defines the relationships for a set of objects in the VirtualCenter inventory. For historical purposes or further analysis, topology maps can be saved as JPG, BMP, or EMF file formats.

Figure 5.33 VirtualCenter's Maps feature is a flexible, graphical utility that helps identify the relationships that exist between the various objects in the virtual infrastructure.

Topology maps are available by clicking the Maps button on the VirtualCenter menu or by selecting an inventory object and then selecting the Maps tab. Figure 5.33 showed the Maps feature from the VirtualCenter menu while Figure 5.34 shows the Maps tab available for each inventory object. In either case the depth of the relationship can be identified by enabling or disabling options in the list of relationships.

Figure 5.34 The Maps tab for inventory objects limits the scope of the map to the selected object.

The Maps button on the menu allows for the scope of the relationship to be edited by enabling and disabling objects in the VirtualCenter inventory. By selecting an inventory object and then viewing the topology map the focus is limited to just that object.

Planning a VirtualCenter Deployment

When discussing the deployment of VirtualCenter, some of the most common topics include:

♦ How much hardware do I need to power VirtualCenter?

♦ How do I prepare VirtualCenter for disaster recovery?

♦ Should I run VirtualCenter in a virtual machine?

The amount of hardware required by VirtualCenter is directly related to the number of hosts and virtual machines it will be managing.

The operating system running VirtualCenter has a maximum memory limit of 4GB: 2GB for use by the operating system and the other 2GB allocated for the application. In addition, VirtualCenter with multiple processors can support large enterprise environments.

VMware suggests that VirtualCenter be configured with two processors and 3GB of RAM to support up to 100 ESX Server hosts and 2,000 virtual machines. An environment of that size is much larger than a typical environment might be, so it's feasible to simply scale the specifications back to meet your needs. For example, a single processor and 1.5GB of RAM should suffice for up to 50 ESX Server hosts and 1,000 virtual machines. Though it helps to have a good starting point for the deployment of VirtualCenter, you can always alter the specifications to achieve adequate performance levels.

More important than detailing the CPU and memory allocations for VirtualCenter is the plan devised for recovery in the event of disaster. Remember, the heart of the VirtualCenter content is stored in a back-end SQL Server or Oracle database. Any good disaster recovery or business continuity plan should include instructions on how to handle data loss or corruption on the back-end.

If the VirtualCenter server is a physical box, the best approach to providing availability is to create a stand-by VirtualCenter server that can be turned on in the event of a failure of the online VirtualCenter server. After failure, the stand-by server can be brought online and attached to the existing SQL Server database, and then the hosts can be added to the new VirtualCenter server.

For high availability of the data component of VirtualCenter, you can configure the back-end database on a SQL Server cluster. Figure 5.35 illustrates using a SQL Server cluster for the back-end database and a stand-by VirtualCenter computer. If a SQL Server cluster is not available or 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 will allow you to restore data up to the minute when loss or corruption occurred.

Figure 5.35 A good disaster recovery plan for VirtualCenter should include a quick means of regaining the user interface as well as ensuring the data is highly available and protected against damage.

Snapshot functionality will give you the ability to return to a point in time for your VirtualCenter. VMotion will give you the portability required to move the server from host to host without experiencing server downtime. But what happens when a snapshot is corrupted or the virtual machine is corrupt altogether? With VirtualCenter as your virtual machine, you can make regular copies of the .vmdk 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 in the last. vmdk copy process, which should not be extremely different, given that the bulk of the data processing by VirtualCenter ends up in a back-end database running on a different server. Figure 5.36 illustrates the setup of a manual cloning of the VirtualCenter server.

Figure 5.36 If VirtualCenter is installed and configured as a virtual machine, its .vmdk file can be copied regularly and used as the hard drive for a new virtual machine, effectively providing a point in time restore in the event of complete server failure or loss.

As a last resort for recovering VirtualCenter, it's possible to just reinstall the software, point to the existing database, and connect the host systems. The installation of VirtualCenter is not a time-consuming process. Ultimately the most important part of the VirtualCenter recovery plan is to ensure that the database server is redundant and protected.

Managing VirtualCenter Settings

The Administration menu in VirtualCenter allows for post-installation configuration of the VirtualCenter. In fact, it even contains configuration options that are not provided during installation. The Administration menu contains the following items:

♦ Custom Attributes

♦ VirtualCenter Management Server Configuration

♦ Roles

♦ Session

♦ Edit Message of the Day

♦ Export Diagnostic Data

♦ Consolidation Settings

The custom attributes option let you define custom identification or information options for virtual machines, hosts, or both (global). Let's look at a good example of how the Custom Attributes can be used. Say that you want to add metadata to each virtual machine to identify if it is an application server, infrastructure server (I.E. DHCP Server, DNS Server), or a domain controller. Adding a custom virtual machine attribute named VM role as shown in Figure 5.37 will allow you to add the required information.

Figure 5.37 Custom attributes allow you to store metadata about virtual machines and hosts.

Once a custom attribute is created, the attribute data can be edited from the Summary tab of the object.. Once the custom attribute is added to the Annotations section of the object, as shown in Figure 5.38, you can use the Edit button to pull up the Custom Attributes window and add the required metadata, as shown in Figure 5.39.

With the metadata clearly defined for various object you can then search based on that data. Figure 5.40 shows a custom search for all virtual machines with a VM role equal to domain controller.

The VirtualCenter Management Server Configuration dialog box contains 12 VirtualCenter settings:

♦ License Server

♦ Statistics

♦ Runtime Settings

♦ Active Directory

♦ Mail

Figure 5.38 Custom attributes will show in the Annotations section of the Summary tab for an object.

Figure 5.39 Metadata can be added to objects by editing the values of the custom attributes.

Figure 5.40 Once the data for a custom attribute is defined it can be used as search criteria for quickly finding objects with similar metadata.

♦ SNMP

♦ Web Service

♦ Timeout Settings

♦ Logging Options

♦ Database

♦ SSL Settings

♦ Advanced Settings

The License Server configuration page, shown in Figure 5.41, of the VirtualCenter Management Server Configuration dialog box provides the parameters for establishing the location of the license server. The options include using an evaluation mode, a local license server, or pointing to a specific license server hosted on another server. Clicking the Use the Following License Server radio button lets you configure different license servers in the format of port@server. For example, using port 27000 on a server named License1 would be identified as 27000@License1.

Figure 5.41 The licensing mode of VirtualCenter is managed through the VirtualCenter Management Server Configuration.

When an evaluation of VI3 is no longer required and the appropriate licenses have been purchased you must deselect the evaluation option and configure the appropriate licensing strategy. When the evaluation option is unchecked a warning message is presented as shown in Figure 5.42.

A checkbox labeled Change Host License Server Settings to Match These VirtualCenter Settings Whenever a Host Is Added to the Inventory is available for facilitating the configuration of new hosts that are added to the VirtualCenter inventory. With this box selected, any host added to VirtualCenter will automatically be reconfigured to use the license server as configured here.

The Statistics page, shown in Figure 5.43, offers the ability to configure the collection intervals and the system resources for accumulating statistical performance data in VirtualCenter.

Figure 5.42 Upgrading from an evaluation of VI3 requires purchase of a license and configuration of a licensing server.

In addition it also provides a database sizing calculator that can estimate the size of a Virtual-Center database based upon the configuration of statistics intervals. By default, 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 hour per sample at statistics level 1

♦ Past year: 1 day per sample at statistics level 1

Figure 5.43 Statistics collection intervals can be customized to support broad or detailed logging.

By selecting an interval from the list and clicking the Edit button you can customize the interval configuration. Figure 5.44 shows the Edit Statistics Interval page where the interval, how long to keep the sample, and the statistics level can be set.

Figure 5.44 Statistics collection can be customized to keep as much or as little information as needed.

The Statistics Collection level offers the following four collection levels defined in the user interface:

Level 1 Basic metrics for average usage of CPU, Memory, Disk, and Network. 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. 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. Maximum and minimum rollup types are not included.

Level 4 Includes all metrics supported by VirtualCenter.

The Runtime Settings, shown in Figure 5.45, let you configure the VirtualCenter Unique ID, the port over which VirtualCenter communicates, and the IP address used to manage VirtualCenter. The unique ID and port will be populated by default and each requires a restart of the VirtualCenter Server service. By default VirtualCenter uses port 902. These settings would normally require changing only when multiple virtual center instances exist in the same environment and conflicts might exist if not altered.

Figure 5.45 VirtualCenter ID, port settings, and Managed IP address can be altered from the RunTime Settings page of the VirtualCenter Management Server Configuration dialog box.

Figure 5.46 shows the Active Directory settings for VirtualCenter. This page includes the ability to set the Active Directory timeout value, a limit for the number of users and groups returned in a query against the Active Directory database, and the validation period (in minutes) for synchronizing users and groups used by VirtualCenter.

Figure 5.46 You can customize the communication and relationship between VirtualCenter and Active Directory for each VirtualCenter deployment.

The Mail page, shown in Figure 5.47, might be the most commonly customized page as its configuration is crucial to the sending of alarm results. 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.

Figure 5.47 Mail settings in Virtual-Center are important for sending VirtualCenter alarm results.

Figure 5.48 shows the SNMP configuration page. 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).

Figure 5.48 VirtualCenter can be configured to send SNMP traps as a result of VirtualCenter alarms.

The Web Service page, shown in Figure 5.49, is used to configure the HTTP and HTTPS ports used by the VirtualCenter Web Access feature.

Figure 5.49 VirtualCenter Web Access uses default HTTP and HTTPS ports by default but you can change that.

Figure 5.50 highlights the Timeout Settings where client connection timeouts are configured. The settings by default allow for a 30-second timeout for normal operations or 120 minutes for long operations.

Figure 5.50 You can adjust Virtual-Center timeout settings in the VirtualCenter Management Server Configuration dialog box.

The Logging Options page, shown in Figure 5.51, customizes the level of detail accumulated in VirtualCenter logs. The logging options include:

♦ None (Disable Logging)

♦ Errors (Errors Only)

♦ Warning (Errors and Warnings)

♦ Info (Normal Logging)

♦ Verbose (Verbose)

♦ Trivia (Extended Verbose)

Figure 5.51 VirtualCenter offers several options for configuring the amount of data to be stored in VirtualCenter logs.

The Database page, shown in Figure 5.52, lets you configure the database password and the maximum number of connections.

Figure 5.52 Database settings can be configured through the Database page of the VirtualCenter Management Server Configuration dialog box.

Figure 5.53 shows the SSL settings configuration for VirtualCenter. This page includes the ability to configure a certificate validity check between VirtualCenter Server and the VI Client. If enabled, both systems will check the trust of the SSL certificate presented by the remote host when performing tasks like adding a host to inventory or establishing a remote console to a virtual machine.

Figure 5.53 VirtualCenter and the VI Client can be forced into checking the trust of an SSL certificate presented by a remote host.

The Advanced Settings page provides for an extensible configuration interface.

Roles

The Roles option from the Administration menu is only available when the view is set to Administration and the Roles tab is selected. This menu works like a right-click context menu that offers the ability add, edit, rename, or remove roles based on what object is selected.

Sessions

The Sessions menu option is only available when the view is set to Administration and the Sessions tab is selected. As shown in Figure 5.54 the session tab allows for terminating all sessions and editing the text that makes up the Message of the Day (MOTD). The currently used session identified by the status ‘‘This Session’’ cannot be terminated.

Edit Message of the Day

As the name suggests this menu item allows for editing the Message of the Day (MOTD). The MOTD is displayed to users each time they log in to VirtualCenter. This provides an excellent means of distributing information regarding maintenance schedules or other important information.

Figure 5.54 The sessions tab (and menu) control the termination of sessions and the message of the day.

The Consolidation Settings menu item provides an interface for establishing the credentials used when using the Guided Consolidation feature of VirtualCenter. We will discuss the Guided Consolidation feature in much more detail in Chapter 7, however, as shown in Figure 5.55, the Service Credentials and Default Credential for the Guided Consolidation feature can be established here.

Figure 5.55 The service and default credentials for Guided Consolidation can be established using the Consolidation Settings menu item.

The Bottom Line

Understand the features and role of VirtualCenter. If ESX Server 3.0 is the heart and soul of the virtual infrastructure, then VirtualCenter is the equivalent of the brain that keeps it all moving. VirtualCenter keeps the management capabilities within a defined framework and allows for controlled, detailed delegation of permissions assignment to meet a company's management needs. Access control strategies maintain the principle of least privilege, while VMotion and DRS maintain performance levels and resource fairness.

The VirtualCenter inventory will be a living entity in your virtual world; it will change regularly in response to the changing demands of the network and the consistently changing management practices of today's IT environments. There is no single way to design or implement a VirtualCenter inventory, just as there is no single design implementation that will stand the test of time. Be open to change and to utilizing the dynamic nature of VirtualCenter to allow your infrastructure to be flexible, scalable, and secure.

Install and configure a VirtualCenter database. VirtualCenter can use Oracle, SQL Server, or MSDE as its back-end database platform. Production environments will not be supported unless running on Oracle or SQL Server, reserving MSDE for nonproduction, demonstration, or evaluation purposes.

Master It Configure a SQL Server 2000 database to support VirtualCenter.

Master It Configure a SQL 2005 database to support VirtualCenter.

Install and configure a VirtualCenter Server. VirtualCenter and the VirtualCenter License Server should be installed on the same server. For web access to VirtualCenter, the Apache Tomcat service can be installed and enabled.

Use VirtualCenter topology maps. VirtualCenter topology maps offer a graphical display of the relationships that exist between hosts, virtual machines, datastores, and networks.

Plan a VirtualCenter deployment. The VirtualCenter application is a proxy that acts on the ESX Server hosts that are in the inventory. Ensuring availability of the VirtualCenter application requires planning the redundancy and availability of the back-end database and the application itself.