Chris McCain - Mastering VMware® Infrastructure3

</p> <p>2. Click the Admin button on the toolbar and then select the Roles tab.</p> <p>3. Right-click on the role that is to be cloned and then click the Clone option, as shown in Figure 8.24.</p> <img src=#i_302.png" > <p> <strong>Figure 8.24</strong>Cloning an existing role provides a starting point for role customization.</p> <empty-line > <p>Once you've cloned the role, you can add or remove privileges as needed.</p> <p>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.</p> <cite> <p> <strong>Real World Scenario</strong> </p> <div class="title">Real World Scenario: VirtualCenter Permissions Interaction</div> <p>In organizations, both large and small users will often belong to multiple groups, and those groups will be assigned different levels of permissions on different objects. Let's observe the effects of multiple group memberships and multiple permission assignments in the virtual infrastructure.</p> <p>In the first scenario, we look at the effective permissions when a user belongs to multiple groups that have different permissions on objects at different levels in the inventory. In the example, a user named Rick Avsom is a member of the ResPoolAdmins and VMAuditors Windows groups. As shown in the next images, the ResPoolAdmins group is assigned membership in the Resource Pool Admins VirtualCenter role and the permission is set at the Production Resource Pool while the VMAuditors group is assigned membership in the Read-Only VirtualCenter role and the permission is set at the Win2008-02 virtual machine.</p> <p> <img src=#i_303.png" > <img src=#i_304.png" > </p> <p>When logged on to the VirtualCenter server as Rick Avsom, the inventory will reflect only the objects available to him through his permissions application. Based on the permission assignment shown in the images above, Rick Avsom will be able to manage the Production resource pool and will have full privileges over the Win2008-01 virtual machine to which the Resource Pool Admin privileges are propagating. However, Rick Avsom will not be able to manage the Win2008-02 virtual machine to which he is limited to Read-Only privileges. The conclusion to this scenario is that users in multiple groups with conflicting permissions on objects lower in the inventory will be granted only the permissions configured directly on the object.</p> <p>Another common scenario to understand is the effective permissions when a user belongs to multiple groups that have different permissions on the same objects. In this example, a user named Sue Rindlee is a member of the VMAdmins and VMAuditors Windows groups. The VMAdmins group has been assigned membership in the Virtual Machine Administrator VirtualCenter role while the VMAuditors group has been assigned membership in the Read-Only VirtualCenter role. As shown in the image here, both of these roles have been assigned permissions on the Production resource pool.</p> <p> <img src=#i_305.png" > </p> <p>When logged on to the VirtualCenter Server as Sue Rindlee, the inventory will reflect only the objects available to her through her permissions application. Based on the permission assignment shown in the image, Sue Rindlee will be able to fully manage all of the virtual machines in the production resource pool. The image shown here validates that Sue's Virtual Machine Administrator status through membership in the VM Admin group prevails over the Read-Only status obtained through her membership in the VMAuditors group. <img src=#i_306.png" ></p> <p>The conclusion to this scenario is that the effective permission is a cumulative permission when a user belongs to multiple groups with different permissions on the same object. Even if Sue Rindlee belonged to a group that had been assigned to the No Access VirtualCenter role, her Virtual Machine Administrator role would prevail. However, if Sue Rindlee's user account was added directly to a VirtualCenter object and assigned the No Access role, as shown in this image, then she would not have access to any of the objects to which that permission has propagated, as shown in the next image.</p> <p> <img src=#i_307.png" > <img src=#i_308.png" ></p> <p>Even with a good understanding of permission propagation, you should always proceed with caution and always maintain the principle of least privilege to ensure that no user has been extended privileges beyond those that are needed as part of a job role. </p> </cite> <p>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: </p> <p> <strong>Global</strong>Includes the ability to manage VirtualCenter license settings and server settings like SNMP and SMTP.</p> <p> <strong>Folder </strong>Controls the creation, deletion, and general manipulation of folders in the Virtual-Center hierarchy.</p> <p> <strong>Datacenter </strong>Controls the ability to create, delete, move, and rename datacenters inside VirtualCenter.</p> <p> <strong>Datastore</strong>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.</p> <p> <strong>Network </strong>Controls the removal of networks from the VirtualCenter inventory.</p> <p> <strong>Host </strong>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. </p> <p> <strong>Virtual Machine </strong>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.</p> <p> <strong>Resource </strong>Controls resource pool manipulation, including creating, deleting, or renaming the pool itself, and controls migration by using VMotion and applying DRS recommendations.</p> <p> <strong>Alarms </strong>Controls the configuration of alarms in the VirtualCenter hierarchy.</p> <p> <strong>Scheduled Task </strong>Controls the configuration of tasks and the ability to run a task that is scheduled inside VirtualCenter.</p> <p> <strong>Sessions </strong>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.</p> <img src=#i_309.png" > <p> <strong>Figure 8.25</strong>Session Control in VirtualCenter allows a user to disconnect VI Client sessions.</p> <empty-line > <p> <strong>Performance </strong>Controls the ability of users to modify the intervals at which the performance chart information is displayed on the performance tab of an object.</p> <p> <strong>Permissions </strong>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.</p> <p> <strong>Extensions </strong>Controls the ability to register, update, or unregister extension in VirtualCenter. The two existing extensions include VMware Update Manager and VMware Converter.</p> <p> <strong>VMware Update Manager </strong>Controls who has the ability to manage system baselines and updates as well as configure the VMware Update Manager service.</p> <p>Table 8.1 details the default privileges assigned to each of the VirtualCenter roles.</p> <empty-line > <p>Table 8.1: Table of Privileges for Default Roles</p> <table> <tr> <th> </th> <th>Administrator</th> <th>Datacenter Administrator</th> <th>Virtual Machine Administrator</th> <th>Virtual Machine Power User</th> <th>Virtual Machine User</th> <th>Resource Pool administrator</th> </tr> <tr> <td> <strong>All Privileges</strong> </td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td>■</td> <td>■</td> </tr> <tr> <td> <strong>Global</strong> </td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> </tr> <tr> <td>Manage Custom Attributes</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td> </td> </tr> <tr> <td>Set Custom Attribute</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Log Event</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Cancel Task</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> </tr> <tr> <td>Licenses</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Diagnostics</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Settings</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>VC Server</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td> <strong>Folder</strong> </td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Create Folder</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Delete Folder</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Rename Folder</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Move Folder</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td> <strong>Datacenter</strong> </td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Create Datacenter</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Remove Datacenter</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Rename Datacenter</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Move Datacenter</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td> <strong>Datastore</strong> </td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Rename File</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Remove Datastore</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Browse Datastore</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Remove File</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td> <strong>Network</strong> </td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Remove</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td> <strong>Host</strong> </td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Inventory</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Add Standalone Host</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Create Cluster</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Add Host To Cluster</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Remove Host</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Move Cluster/Standalone Host</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Rename Cluster</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Remove Cluster</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Modify Cluster</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Move Host</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Configuration</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Connection</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Maintenance</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Virtual Machine Auto-Start Configuration</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>HyperThreading</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Storage Partition Configuration</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Security Profile and Firewall</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Memory Configuration</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Network Configuration</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Advanced Settings</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>System Resource Allocation</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Change SNMP settings</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Local Operations</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Add Host to VirtualCenter</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Manage User Groups</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Create Virtual Machine</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Delete Virtual Machine</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td> <strong>Virtual Machine</strong> </td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> </tr> <tr> <td>Inventory</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Create</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Remove</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Move</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Interaction</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> </tr> <tr> <td>Power On</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> </tr> <tr> <td>Power Off</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> </tr> <tr> <td>Suspend</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> </tr> <tr> <td>Reset</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> </tr> <tr> <td>Answer Question</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> </tr> <tr> <td>Console Interaction</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> </tr> <tr> <td>Device Connection</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> </tr> <tr> <td>Configure CD Media</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> </tr> <tr> <td>Configure Floppy Media</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> </tr> <tr> <td>Tools Install</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> </tr> <tr> <td>Configuration</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Rename</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Add Existing Disk</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Add New Disk</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Remove Disk</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td> </td> </tr> <tr> <td>Raw Device</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Change CPU Count</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Memory</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Add or Remove Device</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Modify Device Settings</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Settings</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Change Resource</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Upgrade Guest Information</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Advanced</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Disk Lease</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>State</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Create Snapshot</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Revert To Snapshot</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Remove Snapshot</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Rename Snapshot</td> <td>■</td> <td> </td> <td>■</td> <td>■</td> <td> </td> <td>■</td> </tr> <tr> <td>Provisioning</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Customize</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Clone</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Create Template From Virtual Machine</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Deploy Template</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Clone Template</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Mark As Template</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Mark As Virtual Machine</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Read Customization Specifications</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Modify Customization Specifications</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Allow Disk Access</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Allow Read-Only Disk Access</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Allow Virtual Machine Download</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Allow Virtual Machine Files Upload</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td> <strong>Resource</strong> </td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Assign Virtual Machine to Resource Pool</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Apply Recommendation</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Create Pool</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Rename Pool</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Modify Pool</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Move Pool</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Remove Pool</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Migrate</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Relocate</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Query VMotion</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td> <strong>Alarms</strong> </td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Create Alarm</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Remove Alarm</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Modify Alarm</td> <td>■</td> <td>■</td> <td>■</td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td> <strong>Scheduled Task</strong> </td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> </tr> <tr> <td>Create Tasks</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> </tr> <tr> <td>Remove Task</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> </tr> <tr> <td>Run Task</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> </tr> <tr> <td>Modify Task</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> <td>■</td> </tr> <tr> <td> <strong>Sessions</strong> </td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>View and Terminate Sessions</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Global Message</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td> <strong>Performance</strong> </td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Modify Intervals</td> <td>■</td> <td> </td> <td>■</td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td> <strong>Permissions</strong> </td> <td>■</td> <td> </td> <td> </td> <td> </td> <td> </td> <td>■</td> </tr> <tr> <td>Modify Role</td> <td>■</td> <td> </td> <td> </td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Reassign Role Permissions</td> <td>■</td> <td> </td> <td> </td> <td> </td> <td> </td> <td> </td> </tr> <tr> <td>Modify Permission</td> <td>■</td> <td> </td> <td> </td> <td> </td> <td> </td> <td>■</td> </tr> </table> <cite> <p> <strong>Real World Scenario</strong> </p> <div class="title">Delegating the Ability to Create Virtual Machines and Install a Guest Operating System</div> <p>One common access control delegation in a virtual infrastructure is to give a group of users the rights to create virtual machines. After just browsing through the list of available privileges, it might seem simple to accomplish this. It is, however, more complex than meets the eye. Providing a user with the ability to create a virtual machine involves assigning a combination of privileges at multiple levels throughout the VirtualCenter inventory.</p> <p>Follow these steps to allow a Windows-based user or group to create virtual machines:</p> <p>1. Use the VI Client to connect to a virtual server. Log in with a user account that has been assigned the Administrator role.</p> <p>2. Create a new role called <strong>VMCreators.</strong></p> <p>3. Select the following privileges:</p> <p> <code>Virtual Machine | Inventory | Create</code> </p> <p> <code>Virtual Machine | Inventory | Add new disk</code> </p> <p> <code>Virtual Machine | Inventory | Add existing disk</code> </p> <p> <code>Virtual Machine | Configuration | Raw Device</code> </p> <p>4. Create a new role called <strong>VMAssigners:</strong></p> <p> <code>Resource | Assign virtual machine to Resource Pool</code> </p> <p>5. Assign a Windows-based user or group the VMCreators role on a folder or datacenter object.</p> <p>6. Assign the same Windows-based user or group the VMAssigners role on a resource pool, host, or cluster.</p> <p>7. Assign the same Windows-based user or group the Read-Only role on a datacenter object or a folder containing a datacenter object. Disable the propagation if the role is assigned directly to the datacenter. Leave the propagation enabled if the role is assigned to a folder that contains the datacenter object.</p> <p>At this point, the privileges for creating a virtual machine are complete; however, the user or group from steps 5 through 7 does not have the rights to mount an ISO image and therefore could not install a guest operating system.</p> <p>Perform these steps to allow a Windows-based user or group to install a guest operating system from an ISO file:</p> <p>1. Use the VI Client to connect to a virtual server. Log in with a user account that has been assigned the Administrator role.</p> <p>2. Create a new role named <strong>GOS_Installers.</strong></p> <p>3. Select the following privileges:</p> <p> <code>Datastore | Browse Datastore</code> </p> <p> <code>Virtual Machine | Configuration</code> </p> <p> <code>Virtual Machine Interaction</code> </p> <p>4. Assign a Windows-based user or group the GOS_Installers role on the datacenter object.</p> </cite> <p>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.</p> <div class="title"> <p>Virtual Machine Management Using the Web Console</p> </div> <p>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?</p> <p>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.</p> <cite> <div class="title">VirtualCenterWeb Access Browser Requirements</div> <p>Connecting to the VirtualCenter web access utility from a Windows or Linux client requires any of the following browsers:</p> <p>♦ Internet Explorer 6.0 or later (Windows only)</p> <p>♦ Netscape Navigator 7.0</p> <p>♦ Mozilla 1.x</p> <p>♦ Firefox 1.0.7 or later </p> </cite> <p>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.</p> <p>To use the web console to access and manage virtual machines on a VirtualCenter server:</p> <p>1. Open a web browser and type in the IP address or fully qualified domain name of the VirtualCenter server.</p> <p>2. At the default VirtualCenter web page, shown in Figure 8.26, click the Log In to Web Access link.</p> <img src=#i_310.png" > <p> <strong>Figure 8.26</strong>VirtualCenter default web page</p> <empty-line > <p>3. Type a valid username and password at the VMware Virtual Infrastructure Web Access login page, shown in Figure 8.27.</p> <p>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.</p> <img src=#i_311.png" > <p> <strong>Figure 8.27</strong>By logging in to VirtualCenter via the web page, you maintain the same security as the VI Client.</p> <empty-line > <img src=#i_312.png" > <p> <strong>Figure 8.28</strong>The web console lets you access and manage the virtual machines that are available to you.</p> <empty-line > <cite> <div class="title">Web-Based Virtual Machine Management</div> <p>The VirtualCenter web console is used solely for the purpose of accessing and managing virtual machines. There will not be any ESX Server hosts listed in the inventory; you must perform all host management tasks through the VI Client or from a command line. </p> </cite> <p>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.</p> <img src=#i_313.png" > <p> <strong>Figure 8.29</strong>You can view details on console access, hardware management, and power management.</p> <empty-line > <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <img src=#i_314.png" > <p> <strong>Figure 8.30</strong>Events tab in the web console</p> <empty-line > <img src=#i_315.png" > <p> <strong>Figure 8.31</strong>The Console tab provides desktop access to a virtual machine when traditional in-band management tools are inoperable.</p> <empty-line > <cite> <div class="title">Web Service Connections</div> <p>The web console is not meant to be a replacement for Terminal Services, Remote Desktop, VNC, Citrix, or any other remote management tool. The greatest value to the web console is during the situation where the aforementioned in-band management tools are unable to connect to a server. The web console will provide access for the purposes of troubleshooting and restoring common remote management tools. However, the web console also poses problems when multiple users establish connections. Since the connection is considered a console session, multiple users would be forced to share mouse and keyboard control unlike a typical Remote Desktop or Terminal Services connection, where users would be unaware of each other's presence without some investigation. </p> </cite> <p>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. </p> <p>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.</p> <img src=#i_316.png" > <p> <strong>Figure 8.32</strong>A URL generated for a virtual machine provides direct access to a console session; however, successful access still requires authentication and privileges.</p> <empty-line > <p>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.</p> <cite> <div class="title">Remote Console URLs</div> <p>The web access component of an individual ESX Server host is identical in nature to the one shown here for VirtualCenter. However, you can view only the virtual machines on that specific host. In addition, if a remote console URL is created by connecting to an individual host, the URL will begin with the IP address or fully qualified domain name of that host instead of the VirtualCenter server's information. The problem with this arises when the virtual machine is relocated to new host as a result of VMotion or HA. The relocation of the virtual machine in this case invalidates the URL. Because of these limitations, you should always create remote console URLs by connecting to a Virtual-Center server and not an ESX Server host.</p> </cite> <div class="title"> <p>The Bottom Line </p> </div> <p> <strong>Manage and maintain ESX Server permissions</strong>. 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.</p> <p> <strong>Master It</strong> A group of administrators need the ability to connect directly to an ESX Server host to perform management tasks.</p> <p> <strong>Manage and maintain VirtualCenter permissions</strong>. 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.</p> <p> <strong>Master It</strong> Domain administrators from a Windows Active Directory domain should not be able to manage the virtual infrastructure.</p> <p> <strong>Master It</strong> Users with Windows-based groups need varying levels of access to the Virtual-Center inventory.</p> <p> <strong>Master It</strong> A default VirtualCenter role provides too much permission for a new user who needs access to VirtualCenter objects.</p> <p> <strong>Manage virtual machines using the web console</strong>. 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.</p> <p> <strong>Master It</strong> You need to access a virtual machine but the corporate firewall does not permit traffic on nonstandard ports.</p> <p> <strong>Master It</strong> 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. </p> <div class="title"> <p>Chapter 9</p> <p>Managing and Monitoring Resource Access</p> </div> <p>The idea that we can take a single physical server and host many virtual machines has a great deal of value in today's dynamic datacenter environments, but let's face it — there are limits to how many virtual machines can be hosted on an ESX Server platform. The key to making the most of your virtualization platform is understanding how resources are consumed by the virtual machines running on the host and how the host itself consumes resources. Then, there's the issue of how we, the administrators, can exercise control over the way a virtual machine or group of virtual machines uses resources.</p> <p>The key resources are memory, processors, disks, and networks. When a number of virtual machines are hosted on an ESX host, each virtual machine consumes some of these resources; however, the method the ESX Server uses to arbitrate access to each resource is a bit different. This chapter will discuss how the ESX Server allocates these resources, how you can change the way these resources are allocated, and how you can monitor the consumption of these resources over time.</p> <p>In this chapter you will learn to:</p> <p>♦ Manage virtual machine memory</p> <p>♦ Manage virtual machine CPU allocation</p> <p>♦ Create and manage resource pools</p> <p>♦ Configure and execute VMotion</p> <p>♦ Create and manage clusters</p> <p>♦ Configure and manage Distributed Resource Scheduling (DRS)</p> <div class="title"> <p>Allocating Virtual Machine Memory</p> </div> <p>One of the most significant advantages of server virtualization is the ability to allocate resources to a virtual machine based on the machine's actual performance needs. In the traditional physical server environment, a server is often provided with more resources than it really needs because it was purchased with a specific budget in mind and the server specifications were maximized for the budget provided. For example, does a DHCP server really need dual processors, 4GB of RAM, and 146GB mirrored hard drives? In most situations, the DHCP server will most certainly under-utilize those resources. In the virtual world, we can create a virtual machine better suited for the DHCP services provided by the virtual machine. For this DHCP server, then, we would assemble a virtual machine with a more suitable 1GB of RAM, access to a single CPU, and 20GB of disk space, all of which are provided by the ESX host that the virtual machine is running on. Then, we can create additional virtual machines with the resources they need to operate effectively without wasting valuable memory, CPU cycles, and disk storage. As we add more virtual machines, each machine places additional demand on the ESX Server, and the host's resources are consumed to support the virtual machines. At a certain point, either the host will run out of resources or we will need to find an alternate way to share access to a limited resource.</p> <cite> <div class="title">The Game Plan for Growth</div> <p>One of the most challenging aspects of managing a virtual infrastructure is managing growth without jeopardizing performance and without overestimating. From small business to large enterprise, it is critical to establish a plan for managing virtual machine and ESX Server growth.</p> <p>The easiest approach is to construct a resource consumption document that details the following:</p> <p>♦ What is the standard configuration for a new virtual machine to be added to the inventory? What is the size of the operating system drive? What is the size of the data drive? How much RAM will it be allocated?</p> <p>♦ What are the decision points for creating a virtual machine with specifications beyond the standard configuration?</p> <p>♦ How much of a server's resources can be consumed before availability and performance levels are jeopardized?</p> <p>♦ At the point where the resources for an ESX Server (or an entire cluster) are consumed, do we add a single host or multiple hosts at one time?</p> <p>♦ What is the maximum size of a cluster for our environment? When does adding another host (or set of hosts) constitute building a new cluster?</p> </cite> <p>Let's start with how memory is allocated to a virtual machine. Then, we'll discuss the mechanisms ESX will use to arbitrate access to the memory under contention and what you as administrator can do to change how virtual machines access memory. </p> <p>When you create a new virtual machine through the VI Client, the wizard will ask you how much memory the virtual machine should have, as shown in Figure 9.1.</p> <p>The amount of memory you allocate on this screen is the amount the guest operating system will see — in this example, it is 1024MB. This is the same as when you build a system and put two 512MB memory sticks into the system board. If we install Windows 2003 in this virtual machine, Windows will report 1024MB of RAM installed. Ultimately this is the amount of memory the virtual machine "thinks" that it has.</p> <p>Let's assume we have an ESX Server with 4GB of physical RAM available to run virtual machines (in other words, the Service Console and VMkernel are using some RAM and there's 4GB left over for the virtual machines). In the case of our new virtual machine, it will comfortably run, leaving approximately 3GB for other virtual machines (there is some additional overhead that we will discuss later, but for now let's assume that the 3GB is available to other virtual machines).</p> <p>What happens when we run three more virtual machines each configured with 1GB of RAM? Each of the additional virtual machines will request 1GB of RAM from the ESX host. At this point, four virtual machines will be accessing the physical memory.</p> <p>What happens when you launch a fifth virtual machine? Will it run? The short answer is yes, but the key to understanding why this is so is the mechanism that ESX Server employs — and it is based on some default settings in the virtual machines' configuration that administrators have control over.</p> <img src=#i_317.png" > <p> <strong>Figure 9.1</strong>Initial Memory settings for a virtual machine indicate the amount of RAM the virtual machine "thinks" that it has.</p> <empty-line > <p>In the advanced settings for a virtual machine, as shown in Figure 9.2, we can see there is a setting for a reservation, a limit, and shares. In this discussion, we will examine the limit and reservation settings and then come back later to deal with the shares.</p> <img src=#i_318.png" > <p> <strong>Figure 9.2</strong>Each virtual machine can be configured with a shares value, a reservation, and a limit.</p> <empty-line > <p>To edit the reservation, limit, or shares of a virtual machine:</p> <p>1. Use the VI Client to connect to a VirtualCenter Server or directly to an ESX Server host.</p> <p>2. Drill down through the inventory to find the virtual machine to be edited.</p> <p>3. Right-click the virtual machine and select the Edit Settings option.</p> <p>4. Click the Resources tab.</p> <p>5. On the Resources tab, select the CPU or Memory options from the Settings list on the left.</p> <p>6. Adjust the Shares, Reservation, and Limit values as desired.</p> <p>The following sections will detail the ramifications of setting custom Reservation, Limit, and Shares values.</p> <div class="title"> <p>Memory Reservation</p> </div> <p>The Reservation value is an optional setting you can set for each virtual machine — but note that the default value is 0MB, as this has a potential impact on virtual machine performance. The Reservation amount specified on the Resource tab of the virtual machine settings is the amount of actual, real physical memory that the ESX Server <em>must</em> provide to this virtual machine for the virtual machine to power on. A virtual machine with a reservation is guaranteed the amount of RAM configured in its Reservation setting. In our previous example, the virtual machine configured with 1GB of RAM and the default reservation of 0MB means the ESX Server does not have to provide the virtual machine with any physical memory. If the ESX Server is not required to provide actual RAM to the virtual machine, then where will the virtual machine get its memory? The answer is that it provides swap, or more specifically something called VMkernel swap.</p> <p>VMkernel swap is a file created when a virtual machine is powered on with a .vswp extension. The per-virtual machine swap files created by the VMkernel reside by default in the same datastore location as the virtual machine's configuration file and virtual disk files. By default, this file will be equal to the size of the RAM that you configured the virtual machine with, and you will find it in the same folder where the rest of the virtual machines files are stored, as shown in Figure 9.3.</p> <img src=#i_319.png" > <p> <strong>Figure 9.3</strong>The VMkernel creates a per-virtual machine swap file stored in the same datastore as the other virtual machine files. The swap file has a .vswp extension.</p> <empty-line > <p>In theory, this means a virtual machine can get its memory allocation entirely from VMkernel swap — or disk — resulting in virtual machine performance degradation. If the virtual machine is configured with a reservation or a limit, the VMkernel swap file could differ.</p> <cite> <div class="title">The Speed of RAM</div> <p>How slow is VMkernel swap when compared to RAM? If we make some basic assumptions regarding RAM access times and disk seek times, we can see that both appear fairly fast in terms of a human but that in relation to each other RAM is faster:</p> <p>RAM access time = 10 nanoseconds (for example) Disk seek time = 8 milliseconds (for example) The difference between these is calculated as follows:</p> <p>0.008 ÷ 0.000000010 = 800,000</p> <p>RAM is accessed 800,000 times faster than disk. Or to put it another way, if RAM takes 1 second to access, then disk would take 800,000 seconds to access — or nine and a quarter days — ((800,000 ÷ 60 seconds) ÷ 60 minutes) ÷ 24 hours).</p> <p>As you can see, if virtual machine performance is your goal, it is prudent to spend your money on enough RAM to support the virtual machines you plan to run. There are other factors, but this is a very significant one. </p> </cite> <p>Does this mean that a virtual machine will get all of its memory from swap when ESX Server RAM is available? No. What this means is that if an ESX host doesn't have enough RAM available to provide all of the virtual machines currently running on the host with their memory allocation, the VMkernel will page some of each virtual machine's memory out to the individual virtual machine's VMkernel swap file (VSWP), as shown in Figure 9.4.</p> <img src=#i_320.png" > <p> <strong>Figure 9.4</strong>Memory allocation for a virtual machine with 1024MB of memory configured and no reservation</p> <empty-line > <p>How do we control how much of an individual virtual machine's memory allocation can be provided by swap and how much must be provided by real physical RAM? This is where a memory reservation comes into play.</p> <p>Let's look at what happens if we decide to set a memory reservation of 512MB for this virtual machine, shown in Figure 9.5. How does this change the way this virtual machine gets memory?</p> <img src=#i_321.png" > <p> <strong>Figure 9.5</strong>A virtual machine configured with a memory reservation of 512MB</p> <empty-line > <p>In this example, when this virtual machine is started, the host must provide at least 512MB of real RAM to support this virtual machine's memory allocation, and the host could provide the remaining 512MB of RAM from VMkernel swap. See Figure 9.6.</p> <p>This ensures that a virtual machine has at least some high-speed memory available to it if the ESX host is running more virtual machines than it has actual RAM to support, but there's also a downside. If we assume that each of the virtual machines we start on this host have a 512MB reservation and we have 4GB of available RAM in the host to run virtual machines, then we will only be able to launch eight virtual machines concurrently (8×512MB=4096MB). On a more positive note, if each virtual machine is configured with an initial RAM allocation of 1024MB, then we're now running virtual machines that would need 8GB of RAM on a host with only 4GB.</p> <img src=#i_322.png" > <p> <strong>Figure 9.6</strong>Memory allocation for a virtual machine with 1024MB of memory configured and a 512MB reservation</p> <div class="title"> <p>Memory Limit</p> </div> <p>If we look back at Figure 9.5, you will also see a setting for a memory limit. By default, all new virtual machines are created without a limit, which means that the initial RAM you assigned to it in the wizard is its effective limit. So, what exactly is the purpose of the limit setting? The limit sets the actual limit. A virtual machine cannot be allocated more physical memory than is configured in the limit setting.</p> <p>Let's now change the limit on this virtual machine from the unlimited default setting to 768MB, as shown in Figure 9.7.</p> <img src=#i_323.png" > <p> <strong>Figure 9.7</strong>A virtual machine configured with 1024MB of memory, a 512MB reservation, and a 768MB limit</p> <empty-line > <p>This means that the top 256MB of RAM will <em>always</em> be provided by swap, as shown in Figure 9.8.</p> <img src=#i_324.png" > <p> <strong>Figure 9.8</strong>Memory allocation for a virtual machine with 1024MB of memory configured, a 512MB reservation, and a 768MB limit</p> <empty-line > <p>Think about the server administrator who wants a new virtual machine with 16GB of RAM. You know his application doesn't need it, but you can't talk him out of his request — and worse than that, your supervisor has decided you need to build a virtual machine that actually has 16GB of RAM. Consider creating the virtual machine with an initial allocation of 16GB, and set a reservation of 1GB and a limit of 2GB. The operating system installed in the virtual machine will report 16GB of RAM (making that person happy and keeping your supervisor happy, too). The virtual machine will always consume 1GB of host memory. If your host has available RAM, then the virtual machine might consume up to 2GB of real physical memory with the top 14GB always being provided by VMkernel swap. Of course, the virtual machine performance should not be expected to perform as if it had all 16GB of memory from physical RAM.</p> <p>Working together, an initial allocation of memory, a memory reservation, and a memory limit can be powerful tools in efficiently managing the memory available on an ESX Server host.</p> <div class="title"> <p>Memory Shares</p> </div> <p>In Figure 9.5, there was a third setting called Shares that we have not discussed. The share system in VMware is a proportional share system that provides administrators with a means of assigning resource priority to virtual machines. For example, with memory settings, shares are a way of establishing a priority setting for a virtual machine requesting memory that is above the virtual machine's reservation but below its limit. In other words, if two virtual machines want more memory than their reservation limit, and the ESX host can't satisfy both of them using RAM, we can set share values on each virtual machine so that one gets higher-priority access to the RAM in the ESX host than the other. Some would say that you should just increase the reservation for that virtual machine. While that may be a valid technique, it may limit the total number of virtual machines that a host can run, as indicated earlier in this chapter. Increasing the limit also requires a reboot of the virtual machine to become effective, but shares can be dynamically adjusted while the virtual machine remains powered on.</p> <p>For the sake of this discussion, let's assume we have two virtual machines (VM1 and VM2) each with a 512MB Reservation and a 1024MB Limit, and both running on an ESX host with less than 2GB of RAM available to the virtual machines. If the two virtual machines in question have an equal number of shares (let's assume it's 1000 each), then as each virtual machine requests memory above its reservation value, each virtual machine will receive an equal quantity of RAM from the ESX host and, because the host cannot supply all of the RAM to both virtual machines, each virtual machine will swap equally to disk (VMkernel pagefile VSWP).</p> <p>If we change VM1's Shares setting to 2000, then VM1 now has twice the shares VM2 has assigned to it. This also means that when VM1 and VM2 are requesting the RAM above their respective reservation values, VM1 will swap one page to VMkernel pagefile for every two pages that <em>VM2</em> swaps. Stated another way, VM1 gets two RAM pages for every one RAM page that VM2 gets. If VM1 has more shares, VM1 has a higher-priority access to available memory in the host.</p> <p>It gets more difficult to predict the actual memory utilization and the amount of access each virtual machine gets as more virtual machines run on the same host. Later in this chapter we will discuss more sophisticated methods of assigning memory limits, reservations, and shares to a group of virtual machines using resource pools.</p> <div class="title"> <p>Allocating Virtual Machine CPU</p> </div> <p>When creating a new virtual machine using the VI Client, the only question you are asked related to CPU is, “Number of virtual processors?”, as shown in Figure 9.9.</p> <img src=#i_325.png" > <p> <strong>Figure 9.9</strong>When a virtual machine is created, the wizard provides the opportunity to configure the virtual machine with one, two, or four virtual CPUs.</p> <empty-line > <p>The CPU setting effectively lets the guest operating system utilize one, two, or four virtual CPUs on the host system. When the VMware engineers designed the virtualization platform, they started with a real system board and modeled the virtual machine after it — in this case, it was based on the Intel 440BX chipset. The PCI bus was something the virtual machine could emulate, and could be mapped to input/output devices through a standard interface, but how could a virtual machine emulate a CPU? The answer was “no emulation.” Think about a virtual system board that has a “hole” where the CPU socket goes — and the guest operating system simply looks through the hole and sees one of the cores in the host server. This allowed the VMware engineers to avoid writing CPU emulation software that would need to change each time the CPU vendors introduced new instruction sets. If there was an emulation layer, it would also add a significant quantity of overhead, which would limit the performance of the virtualization platform by adding more computational overhead.</p> <p>So how many CPUs should a virtual machine have? Creating a virtual machine to replace a physical DHCP server that runs at less than 10 percent CPU utilization at its busiest point in the day surely does not need more than one virtual CPU. As a matter of fact, if we give this virtual machine two virtual CPUs (vCPUs), then we would effectively limit the scalability of the entire host.</p> <p>The VMkernel simultaneously schedules CPU cycles for multi-CPU virtual machines. This means that when a dual-CPU virtual machine places a request for CPU cycles, the request goes into a queue for the host to process, and the host has to wait until there are at least two cores with concurrent idle cycles to schedule that virtual machine. This occurs even if the virtual machine only needs a few clock cycles to do some menial task that could be done with a single processor. Think about it this way: You need to cash a check at the bank, but because of the type of account you have, you need to wait in line until two bank tellers are available <em>at the same time.</em> Normally, one teller could handle your request and you would be on your way — but now you have to wait. What about the folks behind you in the queue as you wait for two tellers? They are also waiting longer because of you.</p> <p>On the other hand, if a virtual machine needs two CPUs because of the load it will be processing on a constant basis, then it makes sense to assign two CPUs to that virtual machine — but only if the host has four or more CPU cores total. If your ESX host is an older generation dual-processor single-core system, then assigning a virtual machine two vCPUs will mean that the virtual machine owns all of the CPU processing power on that host every time it gets CPU cycles. You will find that the overall performance of the host and any other virtual machines will be less than stellar.</p> <cite> <div class="title">One (CPU) for All… at Least to Begin With</div> <p>Every virtual machine should be created with only a single virtual CPU so as not to create unnecessary contention for physical processor time. Only when a virtual machine's performance level dictates the need for an additional CPU should one be allocated. Remember that multi-CPU virtual machines should only be created on ESX Server hosts that have more cores than the number of virtual CPUs being assigned to the virtual machine. A dual-CPU virtual machine should only be created on a host with two or more cores, and a quad-CPU virtual machine should only be created on a host with four or more cores.</p> </cite> <div class="title"> <p>Default CPU Allocation </p> </div> <p>Like the memory settings discussed, the settings Shares, Reservation, and Limit can be configured for CPU. Figure 9.10 shows the default values for CPU Resource settings.</p> <img src=#i_326.png" > <p> <strong>Figure 9.10</strong>A virtual machine's CPU can be configured with Shares, Reservation, and Limit values.</p> <empty-line > <p>When a new virtual machine is created with a single vCPU, the total maximum CPU cycles for that virtual machine equals the clock speed of the host system's core. In other words, if you create a new virtual machine, it can see through the “hole in the system board” and it sees whatever the core is in terms of clock cycles per second — an ESX host with 3GHz CPUs in it will allow the virtual machine to see one 3GHz core.</p> <div class="title"> <p>CPU Reservation</p> </div> <p>As shown in Figure 9.10, the default CPU reservation for a new virtual machine starts at 0MHz. Therefore, by default a virtual machine is not guaranteed any CPU activity by the VMkernel. This means that when the virtual machine has work to be done, it places its CPU request into the CPU queue so that the VMkernel can handle the request in sequence along with all of the other virtual machines' requests. On a lightly loaded ESX host, it's unlikely the virtual machine will wait long for CPU time; however, on a heavily loaded host, the time this virtual machine may have to wait could be significant.</p> <p>If we were to set a 300MHz reservation, as shown in Figure 9.11, this would effectively make that amount of CPU available instantly to this virtual machine if there is a need for CPU cycles.</p> <img src=#i_327.png" > <p> <strong>Figure 9.11</strong>A virtual machine configured with a 300 MHz reservation for CPU activity</p> <empty-line > <p>This option also has another effect similar to that of setting a memory reservation. If each virtual machine you create has a 300 MHz reservation and your host has 6000 MHz of CPU capabilities, you can deploy no more than 20 virtual machines even if all of them are idle. The host system must be able to satisfy all of the reservation values concurrently. Now, does that mean each virtual machine is limited to its 300 MHz? Absolutely not — that's the good news. If VM1 is idle and VM2 needs more than its CPU reservation, the ESX host will schedule more clock cycles to VM2. If VM1 suddenly needs cycles, VM2 doesn't get them any more and they are assigned to VM1.</p> <div class="title"> <p>CPU Limit</p> </div> <p>Every virtual machine has an option that you can set to place a limit on the amount of CPU allocated. This will effectively limit the virtual machine's ability to see a maximum number of clock cycles per second, regardless of what the host has available. Keep in mind that a single virtual CPU virtual machine hosted on a 3GHz, quad-processor ESX Server will only see a single 3GHz core as its maximum, but as administrator you could alter the limit to hide the actual maximum core speed from the virtual machine. For instance, you could set a 500 MHz limit on that DHCP server so that when it reindexes the DHCP database, it won't try to take all of the 3GHz on the processor that it can see. The CPU limit provides you with the ability to show the virtual machine less processing power than is available on a core on the physical host. Not every virtual machine needs to have access to the entire processing capability of the physical processor core.</p> <cite> <p> <strong>Real World Scenario</strong> </p> <div class="title">Increasing Contention in the Face of Growth</div> <p>One of the most common problems administrators can encounter occurs when several virtual machines without limits are deployed on a new virtualized environment. The users get accustomed to stellar performance levels early in the environment lifecycle, but as more virtual machines are deployed and start to compete for CPU cycles, the relative performance of the first virtual machines deployed will degrade. One approach to this issue is to set a reservation of approximately 10 to 20 percent of a single core's clock rate as a reservation and add approximately 20 percent to that value for a limit on the virtual machine. For example, with 3GHz CPUs in the host, each virtual machine would start with a 300 MHz reservation and a 350 MHz limit. This would ensure that the virtual machine would perform similarly on a lightly loaded ESX host, as it will when that host becomes more heavily loaded. Consider setting these values on the virtual machine that you use to create a template since these values will pass to any new virtual machines that were deployed from that template. Please note that this is only a starting point. It is possible to limit a virtual machine that really does need more CPU capabilities, and you should always actively monitor the virtual machines to determine if they are using all of the CPU you are providing them with.</p> <p>If the numbers seem low, feel free to increase them as needed. More important is the concept of setting expectations for virtual machine performance.</p> </cite> <div class="title"> <p>CPU Shares </p> </div> <p>In a manner similar to memory allocation, you can assign CPU share values to a virtual machine. The shares for CPU will determine how much CPU is provided to a virtual machine in the face of contention with other virtual machines needing CPU activity. All virtual machines, by default, start with an equal number of shares, which means that if there is competition for CPU cycles on an ESX host, each virtual machine gets serviced with equal priority. Keep in mind that this share value only affects CPU cycles that are above the reservation set for the virtual machine. In other words, the virtual machine is granted access to its reservation cycles regardless of what else is happening on the host, but if the virtual machine needs more — and there's competition — then the share values come into play.</p> <p>Several conditions have to be met for shares to even be considered for allocating CPU cycles. The best way to determine this is to consider several examples. For the examples to be covered, we will assume the following details about the environment:</p> <p>♦ The ESX Server host includes dual single-core, 3GHz CPUs.</p> <p>♦ The ESX Server host has one or more virtual machines.</p> <p> <strong>Scenario 1</strong>The ESX host has a single virtual machine running. The shares are set at default for the running virtual machines. Will the shares value have any effect in this scenario? No — there's no competition between virtual machines for CPU time.</p> <p> <strong>Scenario 2</strong>The ESX host has two idle virtual machines running. The shares are set at default for the running virtual machines. Will the shares values have any effect in this scenario? No — there's no competition between virtual machines for CPU time as both are idle.</p> <p> <strong>Scenario 3</strong> The ESX host has two equally busy virtual machines running (both requesting maximum CPU capabilities). The shares are set at default for the running virtual machines. Will the shares values have any effect in this scenario? No. Again, there's no competition between virtual machines for CPU time, this time because each virtual machine is serviced by a different core in the host.</p> <p> <strong>Scenario 4</strong> To force contention, both virtual machines are configured to use the same CPU by setting the CPU affinity, shown in Figure 9.12. The ESX host has two equally busy virtual machines running (both requesting maximum CPU capabilities). This ensures contention between the virtual machines.</p> <img src=#i_328.png" > <p> <strong>Figure 9.12</strong>CPU affinity can tie a virtual machine to physical CPU at the expense of eliminating VMotion capability.</p> <empty-line > <p>The shares are set at default for the running virtual machines. Will the shares values have any effect in this scenario? Yes! But in this case, since all virtual machines have equal share values, this ensures that each virtual machine has equal access to the host's CPU queue, so we don't see any effects from the share values.</p> <p> <strong>Scenario 5</strong> The ESX host has two equally busy virtual machines running (both requesting maximum CPU capabilities with CPU affinity set to the same core). The shares are set as follows: VM1 = 2000 CPU shares and VM2 is set to the default 1000 CPU shares. Will the shares values have any effect in this scenario? Yes. In this case, VM1 has double the number of shares that VM2 has. This means that for every clock cycle that <em>VM2</em> is assigned by the host, VM1 is assigned two clock cycles. Stated another way, out of every three clock cycles assigned to virtual machines by the ESX host: two are assigned to VM1 and one is assigned to VM2.</p> <cite> <div class="title">CPU Affinity Settings</div> <p>If the option for CPU affinity is not present on a virtual machine, then check if this virtual machine is being hosted by a DRS cluster. CPU affinity is one of the items that must not be set for VMotion to function, and DRS uses VMotion to perform load balancing across the cluster. If CPU affinity is required on a virtual machine, it cannot be hosted by a DRS cluster. In addition, if you have CPU affinity set on a virtual machine and you then enable DRS, it will remove those CPU affinity settings. The CPU affinity setting should be avoided at all costs. Even if a virtual machine is configured to use a single CPU (for example, CPU1), it does not guarantee that it will be the only virtual machine accessing that CPU unless every other virtual machine is configured not to use that CPU. At this point, VMotion capability will be unavailable for every virtual machine. In short, don't do it. It's not worth losing VMotion. Use shares, limits, and reservations as an alternative.</p> </cite> <p> <strong>Scenario 6</strong> The ESX host has three equally busy virtual machines running (each requesting maximum CPU capabilities with CPU affinity set to the same core). The shares are set as follows: VM1 = 2000 CPU shares and VM2 and VM3 are set to the default 1000 CPU shares. Will the shares values have any effect in this scenario? Yes. In this case, VM1 has double the number of shares that VM2and VM3 have assigned. This means that for every two clock cycles that VM1 is assigned by the host, VM2 and VM3 are each assigned a single clock cycle. Stated another way, out of every four clock cycles assigned to virtual machines by the ESX host: two cycles are assigned to VM1, one is assigned to VM2, and one is assigned to VM3. You can see that this has effectively watered down VM1's CPU capabilities. </p> <p> <strong>Scenario 7</strong> The ESX host has three virtual machines running. VM1 is idle while VM2 and VM3 are equally busy (each requesting maximum CPU capabilities, and all three virtual machines are set with the same CPU affinity). The shares are set as follows: VM1 = 2000 CPU shares and VM2 and VM3 are set to the default 1000 CPU shares. Will the shares values have any effect in this scenario? Yes. But in this case VM1 is idle, which means it isn't requesting any CPU cycles. This means that VM1's shares value is not considered when apportioning host CPU to the active virtual machines. In this case, VM2 and VM3 would equally share the host CPU cycles as their shares are set to an equal value.</p> <p>Given these scenarios, if we were to extrapolate to an eight-core host with 30 or so virtual machines it would be difficult to set share values on a virtual machine-by-virtual machine basis and to predict how the system will respond. Additionally, if the scenario were played out on a DRS cluster, where virtual machines can dynamically move from host to host based on available host resources, it would be even more difficult to predict how an individual virtual machine would get CPU resources based strictly on the share mechanisms. The question then becomes, “Are shares a useful tool?” The answer is yes, but in large enterprise environments, we need to examine resource pools and the ability to set share parameters along with reservations and limits on collections of virtual machines. And with that, let's introduce resource pools.</p> <div class="title"> <p>Resource Pools</p> </div> <p>The previously discussed settings for virtual machine resource allocation (memory and CPU reservations, limits, and shares) are methods used to designate the priority of an individual virtual machine compared to other virtual machines also seeking access to resources. In much the same way as we assign users to groups and then assign permissions to the groups, we can leverage resource pools to make the allocation of resources to collections of virtual machines a less tedious and more effective process.</p> <p>A resource pool is a special type of container object, much like a folder, in the Hosts & Clusters view of inventory. We can create a resource pool on a stand-alone host or as a management object in a DRS cluster (discussed later in this chapter). Figure 9.13 shows the creation of a resource pool.</p> <p>If you examine the properties of the resource pool, as shown in Figure 9.14, you'll see there are two sections: one for CPU settings (reservation, limit, and shares) and another section with similar settings for memory.</p> <img src=#i_329.png" > <p> <strong>Figure 9.13</strong>Resource pools can be created on individual hosts and within clusters. A resource pool provides a management and performance configuration layer in VirtualCenter inventory.</p> <empty-line > <img src=#i_330.png" > <p> <strong>Figure 9.14</strong>A resource pool is used for managing CPU and memory resources for multiple virtual machines contained within the resource pool.</p> <empty-line > <p>To describe the function of resource pools, consider the following example. A company has two main classifications of servers: production and development. The goal of resource allocation in this scenario is to ensure that if there's competition for a particular resource, the virtual machines in production should be assigned higher-priority access to that resource. In addition to that goal, we need to ensure that the virtual machines in development cannot consume more than 4GB of physical memory with their running virtual machines. We don't care how many virtual machines run concurrently as part of the development group as long as they don't collectively consume more than 4GB of RAM.</p> <p>The first step in creating the infrastructure to support the outlined goal is to create two resource pools: one called ProductionVMs and one called DevelopmentVMs, shown in Figure 9.15.</p> <img src=#i_331.png" > <p> <strong>Figure 9.15</strong>Two resource pools created on an ESX Server host</p> <empty-line > <p>We will then modify the resource pool settings for each resource pool to reflect the goals of the organization, as shown in Figures 9.16 and 9.17.</p> <img src=#i_332.png" > <p> <strong>Figure 9.16</strong>The ProductionVMs resource pool is configured to be able to consume more resources in the face of contention.</p> <empty-line > <p>As a final step in configuring the environment, the virtual machines must be moved into the appropriate resource pool by clicking on the virtual machine in the inventory panel and dragging it onto the appropriate resource pool. The result will be similar to that shown in Figure 9.18.</p> <p>Now that we've got an example to work with, let's examine what the settings on each of these resource pools will do for the virtual machines contained in each of the resource pools.</p> <p>In Figure 9.16, we set the ProductionVMs CPU shares to High (8000). In Figure 9.17, we set the DevelopmentVMs CPU shares to Low (2000). The effect of these two settings is similar to that of comparing two virtual machines' CPU share values — except in this case, if there is any competition for CPU resources between virtual machines in the ProductionVMs and the DevelopmentVMs resource pool, the ProductionVMs would have higher priority. To make this clearer, let's examine Figure 9.19 with the assumption that all the available virtual machines are competing for CPU cycles on the same physical CPU. Remember that share allocations only come into play when virtual machines are fighting one another for a resource. If an ESX Server host is only running four virtual machines on top of two dual-core processors, there won't be much contention to manage.</p> <p>If there are two or more virtual machines in a resource pool that require different priority access to resources, we can still set individual Shares values on the virtual machines, or if we have groupings of virtual machines within a resource pool, we can also build a resource pool in a resource pool. A resource pool within a resource pool is called a child resource pool, and it contains its own shares, limits, and reservations separate from the parent resource pool.</p> <img src=#i_333.png" > <p> <strong>Figure 9.17</strong>The DevelopmentVMs resource pool is configured not to be able to consume more resources in the face of contention.</p> <empty-line > <img src=#i_334.png" > <p> <strong>Figure 9.18</strong>Virtual machines assigned to a resource pool consume resources allocated to the resource pool.</p> <empty-line > <p>The next setting in the Resource Pool properties to evaluate is CPU Reservation (Figure 9.14). In the example, a CPU Reservation value of 1000 MHz has been set on the ProductionVMs resource pool. This will ensure that at least 1000 MHz of CPU time is available for all of the virtual machines located in that resource pool. This setting will have an additional effect: assuming that the ESX Server host has a total of 6000 MHz of total CPU, this means 5000 MHz of CPU time is available to other resource pools. If two more resource pools are created with a reservation value of 2500 MHz each, then the cumulative reservations on the system have reserved all available host CPU (1000+2500+2500). This essentially means the administrator will not be able to create additional resource pools with reservation values set.</p> <p>The third setting on the Resource Pool is the CPU Limit field. This is similar to the individual virtual machines CPU Limit field, except in this case all virtual machines in the resource pool combined can consume up to this value. The limit applies to the collective sum of the virtual machines within the resource pool. In the example, the ProductionVMs resource pool has been configured with a CPU limit of 3000 MHz. In this case, no matter how many virtual machines are running in this resource pool, they can only consume a maximum of 3000 MHz of host CPU cycles.</p> <img src=#i_335.png" > <p> <strong>Figure 9.19</strong>Two resource pools with different Shares values will be allocated resources proportional to their percentage of share ownership.</p> <empty-line > <p>Each resource pool also includes a setting to determine if the pool has an Expandable Reservation. The Expandable Reservation dictates whether a resource pool is allowed to ask the parent pool for more resources once it has consumed all its allocated resources. Consider a child who is given a weekly allowance of $10 by their parent. Suppose the child wants to make a purchase that costs $20. If the child's allowance is set to allow Expandable Reservations, then the child could ask the parent for the additional resource, and if the parent has the resource, it will be given. If the child's allowance is not set to allow Expandable Reservations, then they cannot ask the parent for additional resources.</p> <p>Therefore, if the intent is to limit the total amount of CPU available to virtual machines in a resource pool, then the Expandable Reservation check box should be left empty. If left selected, a new virtual machine with a reservation configured that exceeds the capacity of the resource pool will be powered on if the parent is able to provide the necessary resource. In this case, the pool has not provided a hard cap on the amount of reserved resources.</p> <p>Moving on to the Memory portion of the Resource Pool settings, the first setting is the Shares value. This setting works in much the same way as Memory Shares worked on individual virtual machines. It determines which pool of virtual machines will be the first to page in the face of contention. However, this setting is used to set a priority value for any virtual machine in the resource pool when competing for resources with virtual machines in other resource pools. Looking at the Memory Share settings in our example (ProductionVMs=Normal and DevelopmentVMs=Low), this would generally mean that if host memory was limited, virtual machines in the DevelopmentVMs area that need more memory than their reservation would use more pages in VMkernel swap than an equivalent virtual machine in the ProductionVMs resource pool.</p> <p>The Memory Reservation value will reserve this amount of host RAM for virtual machines in this resource pool to run, which effectively ensures that there is some actual RAM that the virtual machines in this resource pool are guaranteed.</p> <p>The Memory Limit value is an excellent way of setting a limit on how much host RAM a particular set of virtual machines can consume. If administrators have been given the “Create Virtual machines” permission in the DevelopmentVMs resource pool, then the Memory Limit value would prevent those administrators from running virtual machines that will consume more than that amount of actual host RAM. In our example, the Memory Limit value on the DevelopmentVMs resource pool is set to be 1024MB. How many virtual machines can administrators in Development create? They can create as many as they wish. But the number of virtual machines they will be able to run will be less. Unfortunately, this setting has nothing to do with the creation of virtual machines, but it will prevent administrators from running too many virtual machines at once. So how many can they run? The cap placed on memory use is not a per virtual machine setting but a cumulative setting. They might be able to run only one virtual machine with all the memory, or multiple virtual machines with lower memory configurations. Assuming that each virtual machine is created without an individual Memory Reservation value, the administrator can run as many virtual machines concurrently as she wants! The problem will be that once the virtual machines consume 1024MB of host RAM, anything above that amount will need to be provided by VMkernel swap. If she builds four virtual machines with 256MB as the initial memory amount, then all four virtual machines will consume 1024MB (assuming no overhead) and will run in real RAM. If she tries to run 20 of the same type of virtual machine, then all 20 virtual machines will share the 1024MB of RAM, even though their requirement is for 5120MB (20×256MB) — the remaining 4096MB would be provided by VMkernel swap. At this point performance might be noticeably slow.</p> <p>The Unlimited check box should be cleared to set a limit value. The Expandable Reservation check box functions in the same way as the equivalent CPU setting. If you truly want to limit the resource pool's memory, then clear this check box.</p> <ci