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


HyTrust Appliance 2.1 Available

Filed under: virtualization — Tags: , , , , , , , , , , , , — iben @ 14:36

HyTrust recently celebrated its 3-year birthday.  HyTrust was founded in October 2007 to bring secure access control and policy to virtual infrastructure, enabling wider adoption of virtualization throughout the enterprise — exactly the same focus that we have today.

It’s amazing to see what we have achieved in the last three years: great enterprise customers; solid partnerships with the major players in virtualization (VMware, Cisco, RSA, Intel and Symantec); numerous accolades, including Best of Show at VMworld; and, of course, several significant releases of HyTrust Appliance…

So we’re excited to let you know that HyTrust Appliance 2.1 is now generally available. It is chock-full of exciting new enterprise features, including protection for the control of Cisco Nexus 1000V, application-level high availability, and smart card support.  As always, we have also made 2.1 available in the Community Edition form, which can be downloaded for free here:

New HyTrust Appliance Capabilities At a Glance

  • Support for VMware vSphere 4.1
  • Integrated access control, policy and audit logging for Cisco Nexus 1000V CLI management (NX-OS command set)
  • Support for complex, multi-domain Active Directory environments
  • Single sign-on via Windows pass-through authentication with smart card integration
  • New ESX hardening templates including VMware Hardening Guide 4.0 and (Sarbanes Oxley) SOX hardening template
  • Application-level high availability (in addition to VMware HA/FT and federation)

If you would like to take a look at the new functionality, we have recorded demos of the new version available for your viewing pleasure.

For those of you currently evaluating HyTrust Appliance, we’d like to extend an added incentive to make your purchase in Q4: for a limited time, HyTrust is offering a free “jump-start” professional services package to help you get up and running quickly. Contact sales ( for more information.


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


vSphere Network Isolation Addresses

Filed under: virtualization — Tags: , , , , , , — iben @ 14:45

Network Isolation Addresses

A network isolation address is an IP address that is pinged to determine if a host is isolated from the network. This address is pinged only when a host has stopped receiving heartbeats from all other hosts in the cluster. If a host can ping its network isolation address, the host is not network isolated, and the other hosts in the cluster have failed. However, if the host cannot ping its isolation address, it is likely that the host has become isolated from the network and no failover action is taken.

By default, the network isolation address is the default gateway for the host. There is only one default gateway specified, regardless of how many service console networks have been defined, so you should use the das.isolationaddress[…] advanced attribute to add isolation addresses for additional networks. For example,  das.isolationAddress2 to add an isolation address for your second network, das.isolationAddress3 for the third, up to a maximum of das.isolationAddress9 for the ninth.

When you specify additional isolation address, VMware recommends that you increase the setting for the das.failuredetectiontime advanced attribute to 20000 milliseconds (20 seconds) or greater. A node that is isolated from the network needs time to release its virtual machine’s VMFS locks if the host isolation response is to fail over the virtual machines (not to leave them powered on.) This must happen before the other nodes declare the node as failed, so that they can power on the virtual machines, without getting an error that the virtual machines are still locked by the isolated node.

For more information on VMware HA advanced attributes, see “Customizing VMware HA Behavior,” on page 26.

Sets the address to ping to determine if a host is isolated from the network. This address is pinged only when heartbeats are not received from any other host in the cluster. If not specified, the default gateway of the console network is used. This default gateway has to be a reliable address that is available, so that the host can determine if it is isolated from the network. You can specify multiple isolation addresses (up to 10) for the cluster: das.isolationaddressX, where X = 1-10. Typically you should specify one per service console. Specifying too many addresses makes isolation detection take too long and can affect VMware HA behavior.

By default, VMware HA uses the default gateway of the console network as an isolation address. This attribute specifies whether or not this default is used (true|false).


VMware ESX High Availability – Tips and Tricks

VMware HA doesn’t work.

  1. Verify that host name is lowercase: hostname; hostname -s
  2. Verify that host name in /etc/hosts is lowercase
  3. Verify that search domain in /etc/resolv.conf is in lowercase
  4. Verify that host name in /etc/sysconfig/network is fqdn, all lowercase
  5. Verify that the host name in esx.conf is fqdn, all lowercase
  6. Verify that host name in DNS is lowercase: nslookup; <short hostname> (should properly resolve fqdn of host, all lowercase)
  7. Verify that all primary service consoles have the same name.
  8. Verify that all primary service consoles are in the same IP subnet.
  9. If VMotion vmkernel port is on same vSwitch as primary service console, use das.allowVmotionNetworks=1
  10. If host has multiple service consoles, use KB 1006541 and the das.allowNetwork0 HA option to ensure that only the primary service console is allowed.
  11. Verify that customer has appropriate licensing for HA, and has available licenses:  In LM Tools, perform a status inquiry, verify that cu is licensed for VC_DAS
  12. Once you have met all of the above criteria, enable HA.
  13. If, after you have verified all the above, and HA still won’t configure:
  1. On the host, stop vpxa: service vmware-vpxa stop
  2. The host will show not responding in VC after a while
  3. Disconnect the host from VC
  4. Re-connect the host to VC
  5. This will force the VPXA package to re-deploy, as well as the HA packages to re-deploy.
  6. Re-configure the hosts for HA.

Many thanks to: Kevin Riley []

See also:
As of VirtualCenter 2.5 Update 2 configuration of VMware High Availability fails.
An error similar to the following appears in the Tasks and Events detail:

HA agent on <esxhostname> in cluster <clustername> in <datacenter> has an error Incompatible HA Networks:

Cluster has network(s) missing on host: x.x.x.x

Consider using the Advanced Cluster Settings das.allowNetwork to control network usage.
– Allows for a NIC that is used for VMotion networks to be considered
for VMware HA usage. This parameter enables a host that has only one
NIC configured for management and VMotion combined to be used in VMware
High Availability communication. By default, any VMotion network is
das.allowNetwork[…] – Allows the use of port group names
to control the networks used for VMware HA. The value is set as the
name of the portgroup, for example, Service Console or Management
Network . When configured, the VMware HA cluster only uses the
specified networks for VMware HA communication.

To configure VMware HA to use the new settings:
Log in to VirtualCenter with the VI Client as an administrator.
Edit the settings of the cluster and deselect Enable VMware HA.
Click OK, and wait for the servers to unconfigure for VMware HA.
ESX Server > Configuration > Networking on each of the ESX hosts
in the cluster and note the portgroups that are common between the
Edit the settings of the cluster, and select Enable VMware HA.
Click VMware HA.
Click Advanced Options.
Add the das.allowNetworkX option with a value of the portgroup name, where X is a number between 1 and 10,

IR: Wednesday, June 24, 2009


New vSphere product names from VMware

Filed under: virtualization — Tags: , , , , — iben @ 14:22

Old Name –> New Name

VMware VirtualCenter –> VMware vCenter Server

VMware Lifecycle Manager –> VMware vCenter Lifecycle Manager

VMware Converter –> VMware vCenter Converter
(for the version integrated into vCenter)

–> VMware vCenter Converter Standalone
(for the separately downloadable version)

VMware Lab Manager –> VMware vCenter Lab Manager

VMware Stage Manager –> VMware vCenter Stage Manager

VMware Update Manager –> VMware vCenter Update Manager

VMware Site Recovery Manager –> VMware vCenter Site Recovery Manager

VirtualCenter Foundation –> vCenter Server Foundation

VMFS –> VMware vStorage VMFS

VMware Virtual Desktop Infrastructure –> VMware View

Virtual Desktop Manager (VDM) –> VMware View Manager

VMware Administrator Interface –> VMware View Administrator

VDM Agent –> VMware View Manager Agent

VDM Web Access –> VMware View Portal

VDM Client for Windows –> VMware View Client for Windows

VDM Client for Linux –> VMware View Client for Linux

Powered by WordPress