Virtualization Adapted Adapting Business Processes for Virtual Infrastrcuture (and vice-versa)


Hypervisor Density

Filed under: Uncategorized — Tags: , , , — iben @ 22:17

Testing using a workload that mimics real world SQL Server workloads better than ever before, suggests that ESX today has a VM density ratio well in excess of 1.5:1.

VMware’s ESXi 4.1 continues to lead the pack, delivering a density advantage of at least 2:1 and up to almost 3:1 versus Hyper-V R2 and between 1.7:1 and 2.3:1 vs. KVM.

XenServer has closed the density gap in terms of number of concurrent VMs that can be run on a given host, coming to par with ESXi, but that this comes with a significant and unacceptable performance penalty. XenServer consistently delivers far less performance across the board (penalty ranging from 25% to 69%), and in our view gives ESXi as much as a 2:1 density advantage over XenServer, once we consider the ability of the hypervisor to access the full performance of the underlying hardware.


vsphere security best practices

Filed under: Uncategorized — Tags: , , , , , , — iben @ 07:54

VMware ESX 4.1 and vCenter Server 4.1


Follow the security principles of:
– separation of duties
– least privilege

Harden the hypervisor: upgrade to vSphere ESXi 4.1

Give the LAN back to the Network Team

Implement the Cisco Nexus 1000v and only assign ports to active systems.

Audit and control access

Use a tool like HyTrust to eliminate configuration drift and track and control system access.

Using Roles to Assign Privileges

A role is a predefined set of privileges. Privileges define individual rights that a user requires to perform actions and read properties.
When you assign a user or group permissions, you pair the user or group with a role and associate that pairing with an inventory object. A single user might have different roles for different objects in the inventory. For example, if you have two resource pools in your inventory, Pool A and Pool B, you might assign a particular user the Virtual Machine User role on Pool A and the Read Only role on Pool B. These assignments would allow that user to turn on virtual machines in Pool A, but not those in Pool B. The user would still be able to view the status of the virtual machines in Pool B.
The roles created on an ESX/ESXi host are separate from the roles created on a vCenter Server system. When you manage a host using vCenter Server, the roles created through vCenter Server are available. If you connect directly to the host using the vSphere Client, the roles created directly on the host are available.
vCenter Server and ESX/ESXi hosts provide default roles:

  • System roles
    • System roles are permanent. You cannot edit the privileges associated with these roles.
  • Sample roles
    • VMware provides sample roles for convenience as guidelines and suggestions. You can modify or remove these roles.

You can also create roles.
All roles permit the user to schedule tasks by default. Users can schedule only tasks they have permission to perform at the time the tasks are created.
Note: Changes to permissions and roles take effect immediately, even if the users involved are logged in. The exception is searches, where permission changes take effect after the user has logged out and logged back in.


Best Practices for vCenter Roles and Permissions

Use best practices for roles and permissions to maximize the security and manageability of your vCenter Server environment.
VMware recommends the following best practices when configuring roles and permissions in your vCenter Server environment:

  • Use folders to group objects to correspond to the differing permissions you want to grant for them.
  • Grant permissions to groups rather than individual users.
  • Grant permissions only where needed. Using the minimum number of permissions makes it easier to understand and manage your permissions structure.
  • If you assign a restrictive role to a group, check that the group does not contain the Administrator user or other users with administrative privileges. Otherwise, you could unintentionally restrict administrators’ privileges in parts of the inventory hierarchy where you have assigned that group the restrictive role.
  • Use caution when granting a permission at the root vCenter Server level. Users with permissions at the root level have access to global data on vCenter Server, such as roles, custom attributes, vCenter Server settings, and licenses. Changes to licenses and roles propagate to all vCenter Server systems in a Linked Mode group, even if the user does not have permissions on all of the vCenter Server systems in the group.
  • In most cases, enable propagation on permissions. This ensures that when new objects are inserted in to the inventory hierarchy, they inherit permissions and are accessible to users.
  • Use the No Access role to masks specific areas of the hierarchy that you don’t want particular users to have access to.

Use Host Profiles to Apply Permissions to Hosts

When you join a host to an Active Directory domain, you must define roles on the host for a user or group in that domain. Otherwise, the host is not accessible to Active Directory users or groups. You can use host profiles to set a required role for a user or group and to apply the change to one or more hosts.
It is recommended that you follow this procedure for System Administrators (Admin) and Auditors (ReadOnly).


You must have an existing host profile. See Creating a Host Profile.
Verify that the hosts to which you apply a profile are in maintenance mode.


  1. Using the vSphere Client, select View > Management > Host Profiles.
  2. Right-click an existing host profile and select Edit Profile.
  3. Expand the profile tree, and then expand Security configuration.
  4. Right-click the Permission rules folder and select Add Profile.
  5. Expand Permission rules and select Permission.
  6. On the Configuration Details tab in the right pane, click the Configure a permission drop-down menu and select Require a Permission Rule.
  7. Enter the name of the group that should have the role assigned to it.
    1. Use the format DOMAIN\name, where DOMAIN is the name of the Active Directory domain and name is the user name or group name.
  8. Select the Name refers to a group of users check box.
  9. Enter the assigned role name for the user or group (usually Admin or ReadOnly).
    1. The role name is case-sensitive. If this is a system role, you must use the nonlocalized role name. For example, for the Administrator role, enter Admin. For the Read-only role, enter ReadOnly.
  10. Select the Propagate permission check box and click OK.


vSphere Datacenter Administration Guide : Setting Up Your Virtual Infrastructure : Managing Users, Groups, Roles, and Permissions : Best Practices for Roles and Permissions


VMworld 2010 Fun Facts

Filed under: Uncategorized — Tags: , — iben @ 20:46
  • set an all time high with 21,000 unique visitors on August 30
  • Over 29,000 tweets on VMworld over 5 days
  • 5,670 attendees came through registration during the first 3 hours of the show on Monday August 30
  • 21,643 pieces of candy consumed at the VMworld Roadside Stop (How many M&Ms in a bag?)
  • 101,470 sodas and 4,852 coffees consumed over 4 days (How many beers?)
  • In 1 day 4,954 granola bars, 3,500 bags trail mix consumed!
  • 718 people who enjoyed the Bungee and Hamster Ball activities at the VMworld Party (I missed this fun.)
  • Just under 11 miles of CAT 5 cable used for the Labs
  • 13,188 attendees used the WiFi (does this mean unique MAC addresses?)
  • 160 VMware spokespeople trained on ITaaS story  (What are the qualifications of a “Spokesperson”?)
  • Announced six products, services and two acquisitions globally (Integrien and TriCipher)
  • LabCloud delivered 15,344 labs compared to 4,500 labs in 2009
  • Delivered Over 21,000 lab hours
  • Deployed a total of 145,097 VMs
  • Every hour LabCloud was creating and destroying approximately 4,000 Virtual Machines

Powered by WordPress