Terms you’ll need to understand
Datacenter
Inventory
Root Folder
Guided Consolidation
Maps
Lockdown Mode
Clusters
Folders
Core Services
Distributed Services
Concepts and techniques you’ll need to master
VC database requirements and sizing
VC hierarchal inventory design
The management capabilities of VC
The software and hardware requirements for a VC Server
The importance of VirtualCenter (VC) is that it is the one fundamental piece of the VMware Infrastructure suite that enhances the value for the enterprise. VirtualCenter unlocks all the enterprise features that make the VMware Infrastructure so valuable; features like VMotion, High Availability, and others all rely on VirtualCenter. It is the backbone of the infrastructure that can make ESX hosts aware of each other and make them work together in resource pools, for example. This chapter covers installation of VirtualCenter, design of a functional VC inventory, and administration with VC.
VirtualCenter 2.5 is a Windows-based application that allows you to control both ESX hosts and their virtual machines. It is also the application that allows you to use enterprise technologies such as VMotion, High Availability, and Distributed Resource Scheduler. VirtualCenter 2.5 also introduces the following new technologies to complement and enhance its other features:
• VMware Update Manager: An automated tool used for patch management of ESX hosts and virtual machines.
• VMware Converter Enterprise for VirtualCenter: A conversion tool that allows you to perform physical to virtual machine migration in addition to virtual machine to virtual machine migrations into the VI3 infrastructure.
• Guided Consolidation: Toned-down version of VMware Capacity Planner, a tool used to analyze a physical server infrastructure and recommend physical machines that are good candidates for conversion to virtual machines.
VirtualCenter is a framework that requires several elements to be functioning to make the entire suite work properly. Depending on the deployment scenario of your VirtualCenter Server and its different elements, sometimes ports need to be open to allow the flow of communications to take its proper course. Table 6.1 shows ports and their use in the VC deployment.
Table 6.1. VC Port Matrix
Understanding the architecture behind VirtualCenter greatly impacts the level of understanding you possess of the technology. VirtualCenter is not complicated software; on the contrary, it is very cleanly built and well defined. Figure 6.1 illustrates how the VirtualCenter blueprint is laid out.
The following different architectural pieces make up the blueprint:
• Core Services: The main module of VirtualCenter, the basic heart of the application that gives way to VM provisioning, Task Scheduler, events logging, and so on.
• Distributed Services: The module that gives way to features like VMotion, HA, and DRS. This is the place where the features that require a separate license stem from.
• Additional Services: The place where independent modules stem from, technologies such as VMware Converter Enterprise and Update Manager.
• Database Interface: The link that is established with a database server that provides VC with a centralized repository for all its data.
• ESX host management: The interface that allows VC to plug into ESX hosts and manage them.
• Active Directory Interface: The link that is established with an Active Directory domain to extend user and group support to VirtualCenter.
• Virtual Infrastructure Application Programming Interface (VI API) and Virtual Infrastructure Software Development Kit (VI SDK): The programming codethat provide a framework for developers of custom applications.
VirtualCenter communicates and issues commands to ESX Servers it manages using the vpxa daemon. However, if you are using the VI client to connect directly to the ESX host and issue commands to manage it that way, the vmware-hostd daemon, also known simply as hostd, is used.
As with any application with a critical role in the enterprise, proper planning, sizing, and preinstallation steps and tasks exist that you should be familiar with to successfully complete VirtualCenter installation. Before you can size hardware and software, you need to know the minimum requirements, and that is what we cover in the following sections.
The minimum hardware requirements for a VirtualCenter Server vary depending on the roles this server will play. The more roles you add to a server, the more hardware you will most likely throw at for it to perform its functions in an optimal manner. Therefore, if you decide that the server hardware will run the VirtualCenter Server and also the VirtualCenter database, the hardware requirements are one thing, and if the server hardware will support only the VirtualCenter Server, the hardware is in a different configuration. The following minimum requirements are for a server that runs VirtualCenter Server only:
• CPU: 2GHz or better processor.
• Memory: 2GB or more.
• Storage: A minimum of 560MB is needed, of which 245MB are for program installation and 315MB for the temporary directory. Best practice calls for a minimum of 2GB disk space for the installation.
• Networking: A network interface card (NIC) that supports 10/100MB, with 1GB being the best practice recommendation.
Now that we have covered the minimum hardware requirements, let’s shift our attention to the software requirements needed to host VirtualCenter Server. Keep in mind that VirtualCenter is a 32-bit application and therefore is supported on 32-bit operating systems. This is not to say it will not work on a 64-bit operating system; it is just not supported. The following operating systems are supported, however:
• Windows XP Professional SP2
• Windows 2000 Server SP4 with Update Rollup 1
• Windows Server 2003 SP1
• Windows Server 2003 R2
The server is only as good as the data repository that supports it, so no matter how great VirtualCenter is, it is only as good as the database that supports it. For this reason, designing a good database back end is imperative for performance, scalability, and stability.
When you are planning for a VirtualCenter database, best practice calls for hosting the database on a separate dedicated server. In other words, it is not recommended to have the database and VirtualCenter on the same server. That being said, the following databases are supported by VirtualCenter Server:
• Microsoft SQL Server 2005 Express.
• Microsoft SQL Server 2000 Standard SP4 and Enterprise. If this option is selected, DAC 2.8 is a required installation on the client.
• Microsoft SQL Server 2005 Enterprise SP1, SP2, and Express. If this option is chosen, MDAC 2.8 is a required installation on the client.
• Oracle 9iR2, 10gR1 (10.1.0.3 and higher), 10gR2.
CAUTION
When you use Microsoft SQL Server 2005 Express, the database size limit is 4GB. If the VC database reaches this size limit, performance degradation occurs. Best practice calls for using this type of database only for test or demonstration purposes, but not for production.
EXAM ALERT
VMware supports the Microsoft SQL Express database for up to 5 ESX hosts with a maximum of 15 virtual machines on each.
Prior to installing VirtualCenter Server, you need to complete the following preparatory steps if you choose to use Microsoft SQL Server as your database software of choice:
• You need to create a database on the database server and a database user with either the sysadmin server role or the db_owner fixed database role assigned to it.
• You should create a system DSN, otherwise known as an ODBC connection, on the VirtualCenter Server that points to the database server. This process ensures that when the installation wizard needs to connect to the database, it knows how to communicate with it.
• You need to configure your DSN connection to use SQL server authentication.
NOTE
The only time you should use Windows authentication is when your VirtualCenter Server and your SQL Server are on the same server host.
EXAM ALERT
SQL authentication is supported on both local and remote instances of a SQL database server.
After installing VirtualCenter Server, you are provided with a small bunch of useful tools; among them is a calculator that allows you to design your database size based on a number of different parameters. For instance, you tell the calculator how many ESX hosts you have and how many virtual machines you have, and it estimates the database size you need. Figure 6.2 illustrates what this calculator looks like.
To access this sizing tool, follow these steps:
1. Log in to VirtualCenter using the Virtual Infrastructure client.
2. From the menu bar, select Administration.
3. Choose VirtualCenter Management Server Configuration.
4. Choose Statistics.
On the right pane of the statistics window, you enter your values and the calculator crunches your numbers for you.
VirtualCenter Server can be installed on a physical server or on a VM. The advantages of hosting it on a VM are endless, including its capability to participate in HA and DRS, making the server even more reliable and stable. Some administrators might hesitate to put VirtualCenter on a VM and allow it to participate in HA or DRS because they fear that they don’t want to put the server that published these technologies in a position where it is also taking advantage of its technologies due to fear of complications. VMware does recommend and support this type of configuration for VirtualCenter. With the many deployments that we have made, we think this solution is a good one.
When you are ready to perform the installation, you should become familiar with the components of VirtualCenter and the order in which they should be installed so as to avoid any complications. For that matter, this order is recommended:
1. Database Server: This step includes creating the database on the database server, assigning it the proper permissions, and creating the associated ODBC connection on the VirtualCenter Server.
2. License Server: The use of a license server is imperative to enable some enterprise-level features. We covered licensing and the license server in greater detail in Chapter 4, “Virtual Networking Operations.” Refer to that chapter for installation of the license server and any other licensing explanation you may need.
3. VirtualCenter Server: This is the actual application server software to be installed.
4. VI Client: This is the application that you use to log in to VirtualCenter from a GUI and manipulate it.
During the installation of VirtualCenter, you have the opportunity to modify the communications ports that VirtualCenter will use. You have a chance to modify the following. In most cases, the default values work just fine.
• HTTP Web Service is configured by default on port 80 and is used for client connections to VC via a web browser.
• HTTPS Web Service is configured by default on port 443 and is used for client connections to VC via a secure web browser.
• Heartbeat (UDP) is configured by default on UDP 902 and is used by VC to maintain ESX host connectivity. In other words, as long as VC is receiving packets from the ESX hosts on these ports, the ESX host is online and communicating, and if VC stops receiving a heartbeat, it assumes the ESX host is down.
• Web Server Port is configured by default on port 8086 and is used by the Apache web server.
If you installed VirtualCenter on a server that is part of an Active Directory domain, you can add users and groups from that domain and any trusted domain directly into VC. Furthermore, once part of a domain, the Domain Admins group is automatically added and granted full control over hosts and VMs. So, if this is not something you desire, you should plan accordingly. After the installation of VC, a number of Windows services are added, as follows:
• VMware Capacity Planner Service: This service controls the Guided Consolidation feature of VC.
• VMware Converter Enterprise Service: This service controls VMware Converter, which allows you to migrate physical machines to virtual machines or virtual machines to virtual machines.
• VMware Infrastructure Web Access: This service controls your ability to log in and manage VMs from a web browser.
• VMware License Server: This service controls whether the license server is online or offline.
• VMware Mount Service for VirtualCenter Service: This service is used during the creation or cloning of VMs.
• VMware Update Manager Service: As the name implies, this service controls the Update Manager.
• VMware VirtualCenter Server Service: The most important service and heart of VC, this service is what makes VirtualCenter Server run. If this service is not running, VC will not run, and as a result, all its service offerings will not run either.
Depending on the size of your environment and how much you expect it to grow in the future, designing a functional VirtualCenter inventory is critical because doing so will make it much easier for you to apply security and enact role-based access to the different hosts and VMs within this inventory. An organizational hierarchy is important also because it gives you quick access to the systems you are trying to reach, whereas putting all the hosts and all the VMs in one folder will make finding what you are looking for more time consuming and frustrating if you are dealing with several dozen virtual machines. In the following sections, we discuss the different ways you can group and organize resources to gain the maximum flexibility and the easiest management and controlled access possible.
At the top of the inventory’s hierarchy sits the root folder, which is, as the name implies, the topmost structure. The Alpha folder presents itself sometimes as Hosts and Clusters and other times as Virtual Machines and Templates, depending on the Inventory view you are in. You can use folders and subfolders to organize VMs and hosts in a way that is functional to your enterprise. A word of caution here: Make sure you do not overuse or overorganize your hierarchy because that, too, can make finding objects difficult for you and very difficult for others browsing the inventory.
If you want to break the VMs into folders, you can divide them based on the overall function they serve. Some people might want to break them down based on the function of the server. So, for example, file servers go in one folder, whereas database servers go in another and so on. We have found that dividing the VMs based on what they do in the enterprise may be easier. For example, if you have a Citrix or Terminal Server implementation in your environment and you group all your Citrix or Terminal Server-related VMs in one folder, users can more easily find the server they are looking for. You would use the same approach to Microsoft Exchange, where you group all servers in the same folder. Figure 6.3 illustrates how folders could be used.
Before you can add any hosts or VMs to the inventory, you need to create at least one datacenter. A datacenter is the logical repository of hosts and VMs. You can create a folder under the root and then add a datacenter, but you cannot create a folder and add hosts and VMs before first adding a datacenter. The best approach to a datacenter setup is to follow what you currently have in your organization. Therefore, if you have two datacenters, create two datacenter objects and group them in folders accordingly and based on geographical location. Figure 6.4 illustrates how a datacenter could be laid out.
Virtual machines in one datacenter cannot be VMotioned to another datacenter. Objects are manipulated in their parent datacenter. However, you can clone a virtual machine from one datacenter to another.
Clusters are created by grouping multiple ESX hosts under the same resource pool. By doing that, you allow these ESX hosts to pool resources and distribute load among them in the most efficient way. You also allow these hosts to calculate and take into consideration one or more host failures and the ability to restart VMs on different hosts. When you create a resource pool, you can enable it to be a High Availability resource pool only, a Distributed Resource Scheduler resource pool only, or both at the same time, which is what best practice calls for. Keep in mind that when you are creating a resource pool, the maximum number of hosts that it can support is 32. Figure 6.5 illustrates a cluster that is both VMware HA and VMware DRS enabled.
When you access VirtualCenter via the VI client, you are presented with numerous tabs from which you can administer, manage, and support your infrastructure. The following sections focus on these tabs and tools in VirtualCenter and how you can use them in an efficient way.
The following subsections cover the following VI client tabs:
• Inventory
• Scheduled Tasks
• Events
• Administration
• Maps
• Consolidation
The Inventory tab allows you to switch the view of the hierarchy between
• Hosts and Clusters
• Virtual Machines and Templates
• Networks
• Datastores
As their names imply, a view of Hosts and Clusters primarily focuses on displaying the hosts and the different cluster configurations. You can, however, still drill down on every host or in every cluster and find the VM or template you are looking for. On the other hand, a view of Virtual Machines and Templates displays all the VMs and templates available. Similarly, a view of Networks or Datastores primarily displays the different network configurations and the available datastores. Figure 6.6 shows where you can change the views.
Scheduled tasks are an extremely helpful method of automating certain tasks to be performed at a given time. Without scheduled tasks, get ready to be up and bright at 3:00 a.m. to power down a host or run an update or any other task that would be required after hours or when load is at a minimum. Scheduled tasks allow you to perform these tasks in an automated manner. Figure 6.7 shows the Scheduled Tasks tab and some available scheduled tasks.
The Events tab is an imperative first step in any troubleshooting undertaking that you will engage in. This panel displays the different events that have occurred. This may include errors that have been registered, alarms that have been triggered, or tasks that have been completed. From this panel, you also have access to search with query keywords and display relevant results. If looking at all the events in one panel is too cumbersome and you want a more focused list, you can select any object in the inventory and browse its Tasks & Events window, which displays information on this object only.
The Administration tab offers several tabs that allow you to manipulate different functions in the infrastructure. These tabs are
• Roles: This tab is discussed in greater detail with security and access control topics in Chapter 8, “VMware Infrastructure Security and Web Access.” On this tab, you can define or view a defined role based on access to VirtualCenter.
• Sessions: This tab shows you who is currently logged in to VirtualCenter and how long that user has been logged in. It also enables you to send messages to these sessions in case of an announcement that you want to make.
• Licenses: This tab allows you to view licenses within the environment.
• System Logs: Like events, system logs are imperative when you are troubleshooting, and this tab gives you a list of system-related logs that you can browse through. You may also search system logs by keyword. Because there may be more than one version of the vpxd-index file, which is the file that holds the system logs, make sure you are using the latest one. The most recent one is usually incremented by a number, and the higher the number, the more recent the file. So, for example, you may have vpxd-2.log and vpxd-3.log, the latter being the more recent one. Figure 6.8 illustrates this tab in greater detail.
Maps are a fantastic way of graphically understanding the topology and what is connected to what. They can be used in many different ways. Say you want to find out which hosts are connected to which datastores or which VMs are on which hosts. Maps can be useful in making sure the VMotion requirements are met by inspecting the ESX hosts in question and making sure they see the correct networking and storage. The more seasoned you become with ESX, the more you will appreciate the power that maps offer you, especially in larger, more complicated environments. Figure 6.9 shows the Maps tab; it shows, on the right, the different criteria that can be selected that would update maps to reflect your selection.
Guided Consolidation is covered in greater detail in Chapter 7, “Virtual Machine Operations.” On this tab, you plan and execute a Guided Consolidation. The tools under this tab allow you to discover, analyze, and consolidate physical servers into virtual machines on ESX hosts.
Lockdown mode allows you to control direct VI client access to an ESXi host. In other words, you shouldn’t directly log in to hosts that are being managed by VirtualCenter because this may cause issues. To prevent administrators from logging in to a host directly, you can modify the Security Profile by selecting an ESXi host, choosing Configuration > Security Profile > Edit, and checking the box next to Enable Lockdown Mode. This prevents any direct access to this ESXi host.
Plug-ins are applications that can be enabled from within VirtualCenter. Plug-ins extend the capabilities of VirtualCenter by giving it more features. Plug-ins are written to connect through the framework that VirtualCenter provides. As of this release, there are two plug-ins for VirtualCenter: VMware Update Manager and VMware Converter Enterprise. This is not to say that VMware could not release a plug-in tomorrow that would take advantage of the VC framework; that’s the beauty and power of VC. Plug-ins are also installed and upgraded separately, which makes installing them independent from the VC installation. When a plug-in is enabled, the VI client GUI is modified, and new features appear accordingly to help manage the new plug-ins.
Because the VI client is the arm by which you manipulate VirtualCenter, knowing how to tweak some of its settings is an important step. You can modify the Timeout settings of the VI client so it is more tolerant to slow WAN connections or even limit the number of VI clients that can concurrently connect to VC. You can access these settings from the File menu: Select Edit and then Client Settings.
The first thing you should know before we get into the discussion of how to back up and recover VirtualCenter is that if the VC Server goes offline, your environment will not stop working. As a matter of fact, everything will continue to function normally. You will be limited only to what new tasks you can perform, and when the VirtualCenter Server is back online, it will resume its responsibilities.
Now let’s talk about what you can do to back up VC Server or to provide some redundancy and High Availability. First, you can put your VirtualCenter Server on a VM and make it part of a cluster. That way, it is taking advantage of both HA and DRS. This takes care of ensuring the server stays up but does not protect you in case of operating system corruption or crashes. To protect against that, you can always have a copy of the VC virtual machine stored somewhere safe that you can recover from in case of emergency.
If the idea of having VirtualCenter on a VM does not appeal to you, you can have a cold standby server that is the exact replica of the VC Server in production. In the event that the production server goes offline, you can recover in a relatively short period. You can also mix and match. Therefore, instead of having a physical server in standby, doing nothing and collecting dust, you can P2V your VC to a VM and turn it off. Then you can use it in the event your physical server should go offline. Being able to do this would hold you up until you recover your server.
Another approach would also be to use clustering of the VC Server, either between two physical servers or two virtual servers, or a mix of physical and virtual. Clustering can also be extended to the database because both Microsoft SQL and Oracle offer clustering.
The options and configurations you can use to protect against a VC failure are numerous. The choice you make depends on what you see as the most efficient solution for your environment. Remember to keep it simple. As long as you have a good backup of your database and a good strategy on how to handle outages in VC, you should be good to go.
1. Which VirtualCenter interface allows developers to write third-party applications for use with VC?
A. VC API
B. VI API
C. VC SDK
D. VM API
2. How many ESX hosts can you have per cluster?
A. 16
B. 24
C. 32
D. 36
3. Which file is responsible for holding the system logs?
A. vpxd-logs
B. vpxd-events
C. vpxd-alerts
D. vpxd-index
4. What is the maximum number of virtual machines that can be managed by a single VirtualCenter Server?
A. 1000
B. 1500
C. 2000
D. 2500
5. Which option is not a VirtualCenter inventory hierarchy?
A. Hosts and Clusters
B. Datacenters
C. Networks
D. Datastores
6. Which two technologies are considered VirtualCenter plug-ins?
A. Guided Consolidation
B. VMware Consolidated Backup
C. Update Manager
D. VMware Converter Enterprise
7. Consider a scenario in which ESX Servers are separated from a VirtualCenter Server by a firewall. What port would you need to open to allow authentication communications?
A. 902
B. 903
C. 904
D. 906
8. True or false: You can create a database for VirtualCenter using the setup wizard during the installation of VirtualCenter.
A. True
B. False
9. True or false: It is recommended that VirtualCenter Server and the license server be installed on the same server.
A. True
B. False
10. What is the maximum number of ESX hosts that can be managed by a single VirtualCenter Server?
A. 100
B. 200
C. 500
D. 1000
Answers to Exam Prep Questions
1. Answer B is correct. The interface that allows developers to create third-party applications for use with VirtualCenter is the VI API.
2. Answer C is correct. The maximum number of ESX hosts that is supported per cluster is 32.
3. Answer D is correct. The file responsible for indexing the system logs is vpxd-index.
4. Answer C is correct. The VMware Configuration Maximum states that the maximum number of virtual machines to be managed by a single VC Server is 2000.
5. Answer B is correct. Datacenters is not a correct VirtualCenter hierarchy; the other hierarchy that is missing from the list is Virtual Machines and Templates.
6. Answers C and D are correct. The two technologies that are VirtualCenter plug-ins are VMware Update Manager and VMware Converter Enterprise.
7. Answer A is correct. Port 902 needs to be open when ESX hosts and VirtualCenter Server are separated by a firewall for authentication communications to flow back and forth.
8. Answer B, False, is correct. The VirtualCenter database cannot be created by the setup wizard during the installation of VC and must be created prior to the installation of VirtualCenter.
9. Answer A, True, is correct. VMware best practice calls for the VC Server and the license server to be installed on the same server because this setup avoids any possible communication issues, and given that VC features rely heavily on a license server being present, the recommendation is that they share the same server.
10. Answer B is correct. The VMware Configuration Maximums state that the maximum number of ESX hosts that can be managed by a single VC Server is 200.