Mastering VMware® Infrastructure3

As indicated in the introduction to Chapter 5, centralizing management of the sheer number of virtual machines and their ESX hosts has become an issue in most growing datacenters. Delegating control to the appropriate users so they can assist in managing the virtual infrastructure is also a large part of the centralized management model. For instance, how do you assign permissions to a group of users responsible for setting up virtual machines to test a new application? They might need to create the virtual machine and manage its access to resources, but they may need to be restricted in what they can do in other areas of the virtual infrastructure.

Permissions to a virtual infrastructure can be managed through a VirtualCenter server or directly through an ESX Server host.

In this chapter you will learn to:

Manage and maintain ESX Server permissions Manage and maintain VirtualCenter permissions Manage virtual machines using the web console

Managing and Maintaining ESX Server Permissions

Both the VirtualCenter Server and the ESX Server use the same structured security model to grant users the ability to manage portions of the virtual infrastructure. As shown in Figure 8.1, this model consists of users (groups), roles, privileges, and permissions.

The items that differ between the non-VirtualCenter environment and the VirtualCenter environment are predominantly in two areas:

♦ The location of the user and group objects created

♦ The level of granularity of the roles and privileges available in each environment

For environments that don't have VirtualCenter, or where the administrator chooses to have users authenticate directly to the ESX Server to perform management tasks, it is important to start with a discussion of the security model.

Permissions to an ESX Server host are assigned to Linux-based users and groups that exist in the Service Console. Perform the following steps to view the ESX Server users and groups:

1. Use the VI Client to connect to an ESX Server host.

2. Select the host in the inventory panel and then click the Users & Groups tab, as shown in Figure 8.2.

Figure 8.1 VI3 security model for assigning access control

Figure 8.2 ESX users and groups are stored in the Service Console.

When constructing a virtual infrastructure, it is important from a security standpoint to identify who in your organization needs access to your ESX host to perform any level of management, using either an SSH connection (like Putty, WinSCP, FastSCP, etc.), the VI Client, and/or the web interface that we will discuss later in this chapter. The root username and password should be distributed with caution. If you determine that multiple users should be allowed direct access to an ESX Server host, provide each user with their own user account.

As mentioned in the introduction, the VI3 and ESX Server security model are composed of users (or groups), roles, privileges, and permissions. In its most basic format, users or groups are assigned to a role that has privileges. The user-role-privilege combination is then associated with an object in the inventory as a permission.

There are two buttons on the Users & Groups tab, the Users button and the Groups button, as shown in Figure 8.2. Users and groups — or at least the groups — are created in order to assign the group to the appropriate role. So what exactly is a role?

ESX Server permissions are set up to help simplify assignment. Rather than choose the individual privilege to be assigned each time you need to delegate, you assign a user or group to a role. Then, the role is granted role a privilege or group of privileges. As shown in Figure 8.3, the Service Console houses three default roles: No Access, Read-only, and Administrator.

Figure 8.3 The Service Console includes default roles for assigning capabilities on an ESX Server host.

The No Access role works as the name suggests. This role prevents access to an object or objects in the inventory. The No Access role can be used if a user was granted access higher up in the inventory. The No Access role can also be used at lower-level objects to prevent object access. For example, if a user is granted permissions at the ESX Server host but should be prevented access to a specific virtual machine, use the No Access role.

Read-Only allows a user to see the objects within the VI Client inventory. It does not allow the user to interact with any of the visible objects in any way. For example, a user with the Read-Only permission would be able to see a list of virtual machines in the inventory but could not act on any of them.

The Administrator role by nature has the utmost authority, but it is only a role, and it needs to be assigned using a combination of a user or group object and an inventory object like a virtual machine.

With only three built-in roles in the Service Console, the defaults don't leave room for much flexibility. However, don't let that slow you down. The limits of the default roles are easily overcome by creating custom roles. You can create custom roles that will better suit your needs, or you can clone existing roles to make additional roles to modify for your own purposes.

The default roles should not be modified. If a role does not suit the management needs, create a custom role. If you alter a default role, it may present a scenario where other administrators unknowingly grant too much or too little permission by assigning membership in a default role.

For example, assume that a set of users needs to interact with the console of a virtual machine, and also needs to change the CD and floppy media of those virtual machines. In the following steps, you'll create a custom role named VMusers:

1. Use the VI Client to connect to an ESX Server host.

2. Click the Admin button from the menu bar.

3. Ensure the Roles tab is selected and click the Add Role button.

4. Type the name of the new role in the Enter Name text box (in this example, VMUsers) and then select the privileges that will be required by members of the role, as shown in Figure 8.4.

5. Click OK to complete the custom role creation.

Figure 8.4 Custom roles strengthen management capabilities and add flexibility to permission delegations.

As simple and useful as roles are, they are not functional until a user or group is assigned to the role, and then the role is assigned to an inventory object. Assume that a group of users exists that needs to interact with all virtual machines that are web servers. If access control is managed through the ESX Server, then you have to create a user account in the Service Console along with a new group — for example, SiteOperators. Once you've created these Linux-based users and groups, you can execute the security model. Follow these steps to grant virtual machine access control to a Service Console user or group:

1. Use the VI Client to connect to an ESX Server host.

2. Right-click the object in the inventory to which permission should be assigned and click the Add Permission option, as shown in Figure 8.5.

Figure 8.5 Granting access control begins with selecting the inventory object to which access must be granted.

3. Click the Add button in the Assign Permissions dialog box, as shown in Figure 8.6.

Figure 8.6 The Assign Permissions dialog box allows you to select a user or group and associate it with an ESX Server role.

4. Select the appropriate user or group (in this case, SiteOperators) and then click the Add button, as shown in Figure 8.7.

5. Select the role that the Service Console users or groups should belong to, as shown in Figure 8.8.

Figure 8.7 Service console users and groups can be granted access to inventory objects.

Figure 8.8 The selection of a role ultimately dictates the privilege level a user or group has on an object.

What if you have an ESX Server that will host 30 virtual machines and 10 of those are the web server virtual machines? As previously demonstrated, this approach then requires that you assign permissions on each of the ten web server virtual machines. This is not an efficient process. Further growth resulting in more web server virtual machines would require additional administrative effort to ensure access control. When creating a role, you'll notice an option, Propagate to Child Objects, that you can use to facilitate access control implementation. This option works like the inheritance settings in a Windows file system. It allows the privileges assigned in this role to be applied to objects beneath the selected object. For example, if the VMUsers role is applied as a permission on the ESX Server host in the inventory panel, and the Propagate to Child Objects option is enabled, all members of the VMusers role could interact with all the virtual machines hosted on the ESX Server. While this certainly simplifies access control implementation, it adds another problem: the permissions of the VMUsers role has been overextended and now applies to all virtual machines and not just the web server. With access control granted at the host level, VMUsers will be able to change floppy and CD media and use the console of the web server virtual machines, but they will also be able to do that on any other virtual machine in the inventory.

This issue presents one of the drawbacks of managing access control on an individual ESX Server host. Keep in mind as well that all of the steps we have discussed so far would have to be performed on each ESX Server in the virtual infrastructure. What if there was a way to organize the inventory of virtual machines? In other words, what if we could create an object for the web server virtual machines and put all of the web server virtual machines within that object? Then we could assign the group to the role at the parent object level and let inheritance take over. As shown in Figure 8.9, the problem is that folder objects are not possible on a single ESX Server host.

Figure 8.9 Folder objects cannot be added to an individual ESX Server, leaving resource pools as the only viable solution for organizing virtual machines.

A resource pool is actually a special object, a folder of sorts, that we will discuss in the next chapter in great detail, but the good news is that it will also help to organize our virtual machines. One byproduct of the resource pool is the ability to manipulate and manage many virtual machines as objects within the logical resource pool object.

Perform the following steps to create a resource pool:

1. Use the VI Client to connect to an ESX Server host.

2. Right-click the hostname and select New Resource Pool, as shown in Figure 8.10.

3. Type a resource pool name in the Name text box, in this case WebServers, as shown in Figure 8.10.

Figure 8.10 Resource pools provide a means of allocating resources as well as organizing virtual machines.

4. Configure the resource allocations if desired to establish limits and reservations for the resource pool. The limit will establish a hard cap on the resource usage while the reservations establish a resource guarantee.

5. Click OK.

So now that we've created a WebServers resource pool, virtual machines can be placed under the resource pool, as shown in Figure 8.11.

Figure 8.11 Virtual machines can be placed into resource pools for resource management purposes.

Resource pools become inventory objects to which permissions can be assigned, as shown in Figure 8.12.

Figure 8.12 As an object in the inventory, resource pools are potential levels of infrastructure management.

Permissions can be removed from inventory objects when management needs change or when improper assignments have been made. In the previous example, the inappropriate permission previously applied to the host itself should be removed now that more appropriate permissions have been configured at the resource pool object.

Use the following steps to remove permissions on an object in the inventory:

1. Use the VI Client to connect to an ESX Server host.

2. Select the object in the inventory and then select the Permissions tab.

3. Right-click the permissions entry to be deleted from the list of existing permissions and then click the Delete option, as shown in Figure 8.13.

Figure 8.13 Permissions are removed from inventory objects as easily as they are added.

You should see a warning indicating that users may retain their permissions because of an assignment higher in the hierarchy; however, in this case, that is what we are trying to accomplish. We want the users to have access to the virtual machines as a result of permissions applied at the resource pool, not the ESX Server.

Once permissions have been assigned throughout the inventory, it is easy to lose track of what has been previously been done. Of course, if your company mandates documentation, there might already be a solid audit trail. However, it is easy to see existing role usage from within the VI Client.

To identify where a role has been assigned as a permission:

1. Use the VI Client to connect to an ESX Server host.

2. Click the Admin button from the toolbar.

3. Click on the role whose usage you wish to identify.

As shown in Figure 8.14, the details pane will identify where in the inventory the role has been used.

Figure 8.14 The VI Client makes it easy to identify where a role has been assigned as a permission.

Over time, it is almost inevitable that management needs will change. At times, you may have to create new roles, edit an existing role, or even delete a role. If a role is not used, it should be removed simply to minimize the number of objects to be viewed and managed.

To delete a role:

1. Use the VI Client to connect to an ESX Server host.

2. Click the Admin button from the toolbar.

3. From the Roles tab, right-click the role to be deleted and select the Remove option, as shown in Figure 8.15.

Figure 8.15 Unused roles should be removed to minimize the objects viewed and managed on an ESX Server.

When a role is in use and is selected for removal, the ESX Server will offer the opportunity to transfer the existing role members to a new role or simply to drop all members from the role, as shown in Figure 8.16. This eliminates the opportunity for accidentally deleting roles that are being used in the inventory.

Figure 8.16 When you attempt to delete a role that is in use, you'll see a prompt that asks if you want to drop or reassign the role members.

Now that you understand how to work with Linux-based users, groups, roles, and permissions on an ESX Server host, be aware that you more than likely will not be doing much of this. Managing the Linux-based user accounts is administratively more cumbersome because of the lack of centralized management and authentication. This is, of course, because the bulk, if not all, of your access control strategies should revolve around Windows-based user accounts accessing the VirtualCenter environment. This offers the advantage of having a centralized user database with a single password management process.

Managing and Maintaining VirtualCenter Permissions

The security model for VirtualCenter is identical to that explained in the previous section for an ESX Server: take a user or group and assign them to a role for a specific inventory object. The difference in the VirtualCenter security model is the origin of the user or group objects. In the VirtualCenter environment, the users and groups are actually Windows users and groups, but exactly which users will depend on whether your VirtualCenter server is a part of a domain or not. If the VirtualCenter server belongs to a workgroup, then the users and groups are stored in the local Security Accounts Manager (SAM) on that server and are managed through the Local Users and Groups node of the Computer Management snap-in. If the VirtualCenter server belongs to an Active Directory domain, then the users and groups available for assignment to roles are pulled from the Active Directory database and are managed through the Active Directory Users and Groups snap-in. This is fairly typical for a Windows server-based application, and also helps us to continue to manage all of the users in our network in one place: Active Directory. If you don't have the ability to create users and/or groups in Active Directory, you will need to make arrangements with your Active Directory administration team to assist you in that area. Once the users and/or groups are created, they will be available for you to assign roles to them through VirtualCenter. We will assume that the VirtualCenter environment is based on a server that is a part of an Active Directory domain for the purposes of this discussion, although the procedures for assigning permissions remains essentially the same if you have a workgroup-based installation. The key is to remember where to create the users and groups you need to use.

VirtualCenter has a more structured hierarchy with greater depth than an ESX Server host. As outlined in the previous section, the only way to organize virtual machines on an individual ESX host is to build a resource pool, and then move the appropriate virtual machines into that resource pool. The VirtualCenter hierarchy opens opportunities to create folder structures for organizing objects like datacenters and virtual machines.

In the VirtualCenter environment, start by creating, as a minimum, a datacenter. The datacenter object is the building block of a VirtualCenter hierarchy.

Perform the following steps to create a datacenter object:

1. Use the VI Client to connect to a VirtualCenter server.

2. Right-click the Hosts & Clusters root node in the inventory and select the New Datacenter option, as shown in Figure 8.17.

3. Type a name for the new datacenter object.

So what exactly is a datacenter object used for? A datacenter is used to organize ESX Server hosts, resource pools, virtual machines, and templates based on a company's management style. It is the building block of the VirtualCenter inventory, much like organizational units are the foundation of an Active Directory structure. An ESX host cannot be added directly to the VirtualCenter. A datacenter must exist in order to add an ESX Server. VirtualCenter is designed as an enterprise management application for all of the ESX servers in your worldwide organization. So the question remains: How do you manage resources? Is your management strategy based on geography, departments, or projects? Or do you prefer an arbitrary management style? In any case, Virtual-Center supports your style. Datacenters can be named by location, department, project, or can be given generic names like Datacenter1, Datacenter2, and so forth.

Figure 8.17 The Datacenter object is the building block of the VirtualCenter inventory.

Think about what would happen if you were to place every document in your computer at the root of your hard drive. Finding documents would be difficult to say the very least, and assigning permissions to objects would be similarly difficult. Thus would be the case if our virtual infrastructure objects (hosts, resource pools, virtual machines, templates) were all located in a flat structure under the root.

Take, for example, an organization with offices in St. Petersburg, Florida, and Los Angeles, California, where each office will have several ESX hosts and dozens of virtual machines and template objects. The infrastructure might be constructed so that the hosts in Los Angeles are attached to a shared storage device in Los Angeles, and the St. Petersburg ESX Server hosts are attached to a second shared storage device local to their site. Keep in mind that these servers will be able to talk to each other via a WAN connection, but they can only access storage in their specific region. In addition, if the company has an IT staff in each location, then the administrators will create logical datacenter objects based on physical location.

This example could just as easily have been detailed as a departmental-specific configuration in which the finance, marketing, and sales departments have their own respective ESX Server hosts. In this case, the logical datacenter objects would be labeled by department rather than physical location.

This organization also does one more thing: a datacenter is a boundary for the configuration of VMotion, HA, and DRS. In other words, you can only migrate a virtual machine with VMotion to another host in the same datacenter where it is currently running, in the same way that HA can only fail over to another host in the same datacenter. The VMotion, HA, and DRS topics will be covered in more detail in Chapters 9 and 10.

But what happens if there are 30 datacenters in your organization, some located in Europe, some in North America, some in South America — and all with different teams of administrators managing them? The simple answer is to create folders under the root object in VirtualCenter and then create (or move) your datacenter objects under those folders. Creating folders under the root and placing datacenter objects beneath them allows for broader access control management. Think about why you create folders on network drives: to organize files and other folders and to simplify the assignment of permissions to many objects. Designing a VirtualCenter inventory employs the same logic. Figure 8.18 details a VirtualCenter inventory where multiple datacenter objects exist beneath a folder structure that provides an additional layer of management and access control. In this case, the datacenters are managed by geography: East Coast or West Coast.

Figure 8.18 Folders created above the datacenter object offer flexibility in providing broader access control.

In the same way you can use folders to organize datacenters, you can also create folders within the datacenter to organize virtual machines according to your needs. For more detailed micromanaging scenarios, folders within folders can be created. Figure 8.19 details an inventory structure where datacenters are organized by geography and servers are managed by the rack in which they exist.

Figure 8.19 Creating folders beneath a datacenter provides more granular access control and management strategies.

As explained in the previous section, a special type of folder called a resource pool is used to organize virtual machines. The key difference between a regular folder and a resource pool is that a resource pool allows for the carving of CPU and memory resources to provide resource limitation to virtual machines within the pool. Resource pool functionality will be discussed with more detail in Chapter 9; for now, our focus is on the access control capabilities of the resource pool as an object in the inventory.

VirtualCenter offers two main views of the objects within the inventory: Hosts & Clusters and Virtual Machines & Templates. Until now we have remained in the default view of Hosts & Clusters, but the Virtual Machines & Templates view is extremely valuable for organizing virtual machines with respect to the management and access control needs of the traditional Windows administrators. The alternate views available in VirtualCenter maintain their own respective structures to support management of the various objects. For example, changes to objects in the Hosts & Clusters view does not necessarily result in changes to the objects in the Virtual Machines & Templates view. Figure 8.20 shows details of a Virtual Machines & Templates view constructed to support access control implementation based on the types of virtual machines in the infrastructure. The inventory is made up of several custom folders called Finance VMs, Medical System VMs, Infrastructure VMs, and the default Discovered Virtual Machine, which catches any unassigned virtual machines. These folders, like those in the Hosts & Clusters view, provide a boundary for assigning permissions.

Figure 8.20 The Virtual Machines & Templates view maintains its own hierarchical structure to enhance access control possibilities.

The remaining views in VirtualCenter, Networks and Datastores, though not more common utilities, provide consolidated looks at all the networks and datastores configured within the available datacenter objects. Figures 8.21 and 8.22 show examples of these views.

Figure 8.21 The Networks view provides a consolidated look at all the available networks and the virtual machines connected to each respective network.

Figure 8.22 The Datastores view provides a consolidated look at all datastores available in a datacenter as well as a summary of the datastore, the virtual machines it contains, and the hosts that have access.

Where the ESX Server host was quite limited in its default roles, VirtualCenter provides more default roles, thereby offering a much greater degree of flexibility in constructing access control. Although both security models offer the flexibility of creating custom roles, ESX Server included three default roles while VirtualCenter provides eight default roles, including the same three offered in ESX Server. Figure 8.23 details the default VirtualCenter roles.

Figure 8.23 The VirtualCenter default roles offer much more flexibility than an individual ESX Server.

As you can see, there are a large number of roles provided by VMware in a default Virtual-Center installation. Remember, just like the default ESX roles, it is considered a best practice to not modify the default roles provided by VMware. Editing the defaults could result in over- or under-assigning permissions. If the default roles are edited and other administrators are unaware of the alteration, the use of the default role results in unexpected privileges or a lack of any privileges. If you need a similar role to one that is a default, then clone that role and change the permissions assignment for the cloned role. The key to using these roles effectively is to understand the functions of each of the roles provided by VMware:

No Access This role is just what it sounds like — it permits a user or group no access. But why do we need it? The idea behind this role is to prevent a user or group that has permissions at some point higher in the hierarchy from having permissions on the object to which this role is assigned. For instance, you may have granted Bob the Virtual Machine Administrator a role at the datacenter level, which would permit him to administer all of the virtual machines in the datacenter, but there is a security concern about him having access to one of the accounting virtual machines in that datacenter. You could assign Bob to the No Access role on the Accounting virtual machine, which would effectively supersede his Virtual Machine Administrator privileges.

Read-Only Read-Only allows users to see the VirtualCenter inventory. It does not allow them to interact with any of the virtual machines in any way through the VI Client or the web client except to see what the power status of each virtual machine is in the inventory where they have the Read-Only role applied.

Administrator A user assigned to an object with the Administrator role will have full administrative capabilities over that object in VirtualCenter. Note that this does not grant any Windows privileges. For instance, a user assigned the Administrator role for a virtual machine may be able to change the RAM assigned to the virtual machine and alter its performance parameters (Shares, Reservations, and Limits), but may not even have the permissions to log into that Windows virtual machine unless his or her Windows account has those permissions.

The Administrator role can be granted at any object level in the hierarchy and the user or group that is assigned the role at that level will have VirtualCenter administrative privileges over that object and (if the inheritance box is checked) any child objects in the hierarchy. This is in contrast to the Virtual Machine Administrator, who has limited privileges on certain inventory objects but full administrative capabilities over virtual machines.

Virtual Machine Administrator The VM Administrator role is used to assign full administrative privileges to a user or group, but only to virtual machines. The idea here is, as an example, if a user is granted the VM Administrator role at a datacenter level, he or she would only be able to fully administer virtual machines in that datacenter, but that user would not be able to change settings on objects such as resource pools in that datacenter.

Datacenter Administrator The Datacenter Administrator role is targeted at users whose primary function is to set up the infrastructure of the hosts, clusters, and networks within the Datacenter object. Interestingly enough, the Datacenter Administrator Role does not include the ability to create virtual machines, although the administrator can set up folders and resource pools for the virtual machines to be placed into.

Resource Pool Administrator The Resource Pool administrator is able to manage and configure resources with a resource pool including virtual machines, child pools, scheduled tasks, and alarms.

VMware Consolidated Backup User As the role name suggests, the VMware Consolidated Backup user has the privileges required for performing a backup of a virtual machine using VCB.

Virtual Machine Power User The VM Power User role grants a user the ability to interact with and change the configuration of an existing virtual machine. The VM Power User role is essentially a VM Administrator without the ability to create or delete a virtual machine. In addition, a user cannot move a virtual machine within the VirtualCenter hierarchy.

Virtual Machine User The Virtual Machine User role grants the user the ability to interact with a virtual machine, but not the ability to change its configuration. Users can operate the virtual machine's power controls and change the media in the virtual CD-ROM drive or floppy drive as long as they also have access to the media they wish to change. For instance, a user who is assigned this role for a virtual machine will be able to change the CD media from an ISO image on a shared storage volume to their own client system's physical CD-ROM drive. If you want them to have the ability to change from one ISO file to another (both stored on a Virtual Machine File System [VMFS] volume or Network File [NFS] volume), they will also need to be granted the Browse Datastore permission at the parent of the Datastore object in the VirtualCenter hierarchy — usually the datacenter that the ESX host is located in.

What if the roles listed here don't provide you with the necessary functionality for a particular grouping of users? Well, it depends on what the problem is. Let's take the most basic problem. You've chosen a best fit role to assign a user privileges, but you just want them to do one more thing — or perhaps it's that the role assigns too many privileges. For such cases, it is best to clone the existing role and make the minor adjustments.

Perform the following steps to clone a role in VirtualCenter:

1. Use the VI Client to connect to a VirtualCenter server.

2. Click the Admin button on the toolbar and then select the Roles tab.

3. Right-click on the role that is to be cloned and then click the Clone option, as shown in Figure 8.24.

Figure 8.24 Cloning an existing role provides a starting point for role customization.

Once you've cloned the role, you can add or remove privileges as needed.

That takes care of just tweaking a role for your own purposes, but what if a user needs permissions on two different objects in the inventory? The example we discussed previously is when the user needs to change the ISO image that's mounted in the CD-ROM drive of the virtual machine to a different ISO. A Virtual Machine User has access to the CD-ROM properties of a virtual machine, but they don't have access (by default) to browse the datastores where the ISO images are stored. In this case, you would perform two separate permissions assignments. First, you would assign the user to the VM User role directly on the virtual machine or on the folder in which the virtual machines are stored. Next, you would create a custom role, grant the Browse Datastore privilege to the role, and assign the user to the role. Last, you would assign the permission in the inventory.

Roles are very useful, but now that we've started to peek into the properties of the roles, we should take a look at what each of the privileges are and what they do for you in terms of customizing roles. Remember that privileges are individual tasks that are assigned to roles. This is a rather long list of privileges, but it's broken down into some general categories, so we'll begin by looking at what each of the categories means in general terms:

Global Includes the ability to manage VirtualCenter license settings and server settings like SNMP and SMTP.

Folder Controls the creation, deletion, and general manipulation of folders in the Virtual-Center hierarchy.

Datacenter Controls the ability to create, delete, move, and rename datacenters inside VirtualCenter.

Datastore Controls who can access files stored on an ESX attached volume. This permission needs to be assigned at the parent object of the ESX host itself — for instance, a datacenter, an ESX cluster, or a folder that contains ESX hosts.

Network Controls the removal of networks from the VirtualCenter inventory.

Host Controls what users can do with the ESX host itself in inventory. This includes tasks like adding and removing ESX hosts from the inventory, changing the host's memory configuration, or changing the Service Console firewall setting's network configuration.

Virtual Machine Controls the manipulation of Virtual machines in the VirtualCenter inventory, including the ability to create, delete, or connect to the remote console of a virtual machine, to control the power state of a virtual machine, to change floppy and CD media, and to manipulate templates among other privileges.

Resource Controls resource pool manipulation, including creating, deleting, or renaming the pool itself, and controls migration by using VMotion and applying DRS recommendations.

Alarms Controls the configuration of alarms in the VirtualCenter hierarchy.

Scheduled Task Controls the configuration of tasks and the ability to run a task that is scheduled inside VirtualCenter.

Sessions Controls the ability to view and disconnect VI Client sessions connected to VirtualCenter and to send a global message to connected VI client users. As shown in Figure 8.25, a user without Sessions privileges cannot terminate VI Client sessions.

Figure 8.25 Session Control in VirtualCenter allows a user to disconnect VI Client sessions.

Performance Controls the ability of users to modify the intervals at which the performance chart information is displayed on the performance tab of an object.

Permissions Controls who has the ability to modify the permissions assigned to a role and who can manipulate a role/user combination for a particular object.

Extensions Controls the ability to register, update, or unregister extension in VirtualCenter. The two existing extensions include VMware Update Manager and VMware Converter.

VMware Update Manager Controls who has the ability to manage system baselines and updates as well as configure the VMware Update Manager service.

Table 8.1 details the default privileges assigned to each of the VirtualCenter roles.

Table 8.1: Table of Privileges for Default Roles

Virtual Machine | Inventory | Create

Virtual Machine | Inventory | Add new disk

Virtual Machine | Inventory | Add existing disk

Virtual Machine | Configuration | Raw Device

Resource | Assign virtual machine to Resource Pool

Datastore | Browse Datastore

Virtual Machine | Configuration

Virtual Machine Interaction

Manage your permissions carefully. Do not provide more permissions than are necessary for the job role at hand. It is always better to err on the side of caution when it comes to delegating authority. Just as in any other information systems environment, your access control implementation will be a living object that will consistently require consideration and revision. Be flexible, and expect that users and administrators alike are going to be curious and will push their access levels to the limits. Stay a step ahead and always remember the principle of least privilege.

Virtual Machine Management Using the Web Console

Imagine a situation where you are away from your desk at the office and you get a call or a page indicating that there is a problem with a virtual machine in one of your datacenters. These types of situations have been known to happen. Your desk isn't close at hand and you don't have your laptop with you. How can you quickly take a look at the virtual machine in order to diagnose the issue?

Fortunately, VMware has included an optional web service that can be installed on your VirtualCenter server and is installed by default on all of your ESX hosts. All it requires is a web browser and IP connectivity.

This service can give you access to the virtual machines running in your infrastructure, and it is based on the Apache Tomcat web service. The Apache Tomcat web service is part of the VirtualCenter installation, as you learned in Chapter 5. Tomcat is most commonly known for its use as a web server running on Linux operating systems. However, the Windows version of Tomcat is used for the web access component of VirtualCenter instead of building on top of the Internet Information Services (IIS) web server available natively in Windows. This web access component, like the VI Client, maintains the level of security as defined by the permissions established in VirtualCenter.

To use the web console to access and manage virtual machines on a VirtualCenter server:

1. Open a web browser and type in the IP address or fully qualified domain name of the VirtualCenter server.

2. At the default VirtualCenter web page, shown in Figure 8.26, click the Log In to Web Access link.

Figure 8.26 VirtualCenter default web page

3. Type a valid username and password at the VMware Virtual Infrastructure Web Access login page, shown in Figure 8.27.

Once you have entered a valid Windows username and password for a user that has permissions in VirtualCenter, you'll see an inventory of the virtual machines, as shown in Figure 8.28.

Figure 8.27 By logging in to VirtualCenter via the web page, you maintain the same security as the VI Client.

Figure 8.28 The web console lets you access and manage the virtual machines that are available to you.

Selecting an individual virtual machine alters the layout of the web console by offering additional tabs and links for managing the virtual machine. Figure 8.29 shows the default view once a virtual machine has been selected in the inventory. In addition to the five management tabs, the toolbar at the top of the page contains buttons for managing virtual machine power states as well as CD-ROM, floppy, and network devices.

Figure 8.29 You can view details on console access, hardware management, and power management.

The Events tab, shown in Figure 8.30, details the most recent events that have occurred for the selected virtual machine. Events in this view include information on changes in power state as well as resource utilization.

The Alarms tab will allow you to examine the recent alerts that this virtual machine has triggered according to the Alarms that are configured for the virtual machine. Alarm creation and management will be discussed in great detail in Chapter 11.

The Tasks tab lists any recent tasks that have recently taken place upon the virtual machine along with any tasks that might still be in progress.

As shown in Figure 8.31, the Console tab provides access to a console session for the virtual machine that grants access similar to using a keyboard and mouse connected directly to a physical server.

Figure 8.30 Events tab in the web console

Figure 8.31 The Console tab provides desktop access to a virtual machine when traditional in-band management tools are inoperable.

You can log in to a virtual machine desktop through the web console by pressing Ctrl+Alt+Insert or by clicking the Virtual Machine menu in the toolbar and then selecting the Send Ctrl+Alt+Delete option.

Quickly revisit Figure 8.32, noting the Commands section on the right side of the page. This section contains a Generate Remote Console URL link, which generates a URL that provides direct access to a virtual machine. Figure 8.32 shows the details of the remote URL generation page. By default, the Limit View to the Remote Console and Limit View to a Single Virtual Machine options are selected, thereby confining the remote console URL to only the target virtual machine. The URL begins with the IP address or fully qualified domain name of the VirtualCenter depending on how the connection has been established in the web browser.

Figure 8.32 A URL generated for a virtual machine provides direct access to a console session; however, successful access still requires authentication and privileges.

The URL is rather long and therefore not one to be committed to memory. For the user who needs occasional access to a virtual machine, the remote console URL can be pasted into an e-mail message or instant messaging session. Once the user clicks on the link, an authentication page much like the one seen earlier in this section will open. The ID that the user authenticates with must have at least the Virtual Machine User role assigned to it for the link to function as expected.

The Bottom Line

Manage and maintain ESX Server permissions. Grant permissions to an ESX Server host with caution. Ideally, the number of individuals who have the ability to connect directly to an ESX Server host should be minimized.

Master It A group of administrators need the ability to connect directly to an ESX Server host to perform management tasks.

Manage and maintain VirtualCenter permissions. The VirtualCenter permissions model builds off Windows-based user accounts and provides a great degree of flexibility, thus allowing virtual infrastructure administrators to maintain the principle of least privilege.

Master It Domain administrators from a Windows Active Directory domain should not be able to manage the virtual infrastructure.

Master It Users with Windows-based groups need varying levels of access to the Virtual-Center inventory.

Master It A default VirtualCenter role provides too much permission for a new user who needs access to VirtualCenter objects.

Manage virtual machines using the web console. The web console utility is solely for the management of virtual machines. It is a great tool for allowing virtual machine administrators management capabilities without using the full VI Client. Like the VI Client, however, the web console is an excellent means for connecting to a virtual machine when traditional in-band management tools are not available.

Master It You need to access a virtual machine but the corporate firewall does not permit traffic on nonstandard ports.

Master It You need to send a Windows administrator a link that will provide access to a virtual machine console. The administrator wants to establish this link as an Internet Explorer favorite.