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.


Host Profiles N1KV VDS

Filed under: virtualization — Tags: , , , , , , , , , , , — iben @ 06:21

Background to Using Host Profiles

The vDS UI also allows a phased migration of vmnics from vSS to vDS without disruption to an operational environment. VMs can be migrated from a vSS to a vDS on the fly so long as the vDS and vSS have connectivity to the same network at the same time and the origin Port Group on the vSS and destination DV Port Group on the vDS are configured to the same VLAN.

Host Profiles provide a way to migrate multiple hosts at one time. Host Profiles use a golden profile from a migrated host to propagate a configuration to a number of other hosts.

When applying a Host Profile to a host, the host must be in Maintenance Mode. This requires VMs to be either powered down or migrated to another host.

Host Profiles are most appropriate for new installations of similarly configured hosts (i.e. same number of vmnics, same vmnic to physical switch configuration, no active VMS).

The table below summarizes the deployment situations and suggested methods for migration from vSS to vDS. Note: These are suggestions only; both methods will work within the guidelines mentioned above.

Summary of Migration Methods

Table 1 – Summary of vSS to vDS Migration Methods

DeploymentSituation SuggestedMethod Details
New servers, same vmnic config, no active VMs vDS UI + HP Migrate first host with vDS UI. Take host profile and apply to remaining hosts
<5 Existing Servers, no active VMs vDS UI Small number of servers. Can use host profiles, but possibly easier to continue with vDS UI
>5 Existing servers, same vmnic configs, no active VMs vDS UI + HP Larger number of servers with similar vmnic configuration. No active VMs so can enter maintenance mode and use Host Profiles
Existing Servers, active/operational VMs vDS UI Cannot use Maintenance Mode as VMs active. Phased vmnic migration suggested to ensurecontinuity of VM communications
 Existing Servers, dissimilar vmnic configurations vDS UI Enables per host tailoring of vmnic to dvUplink PortGroup mapping
Ongoing Compliance Checking HP Non-disruptively check network settings are compliant with approved “golden” configuration

Note: vDS UI = Use vDS UI; HP = use Host Profiles; vDS + HP = use vDS UI to deploy first host and Host Profiles for remaining hosts.

Applying NIC Teaming Policies to DV Port Groups With a vSS, NIC teaming policies are defined on the virtual switch with an optional override on each Port Group definition.  With vDS, NIC teaming policies are only defined on the DV Port Groups and apply to dvUplinks, not vmnics.  The vmnics are mapped to the dvUplinks on a per host basis.  This enables each host to have a different vmnic to physical host configuration and yet use the same NIC teaming policy over all hosts spanned by the vDS.

Monitoring Hash vmnic Selection in NIC Teams

The esxtop command from the ESX console can reveal the physical NIC (vmnic) used by virtual port or VM within a NIC team.

Use esxtop to see the following information:

  • PORT-ID represents an internal port number on the virtual switch
  • USED-BY column shows what that port number is used by (e.g. VMkernel, VM, etc)
  • TEAM-PNIC column shows what physical nic (vmnic) is being used for traffic from that virtual port (the result of the hash within the NIC team)
  • The remaining columns indicate the Receive and Transmit traffic rates on those ports.

To use esxtop, type esxtop from the ESX console and then type n.

A list of commands for the ESX command line interface is published in Chapter 6 of the ESX 4.0 Configuration Guide (available at To control console output to one page at a time by adding the | more suffix to the commands. For example:
esxcfg-vswitch –l | more


(See page 8)

Powered by WordPress