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

2010/03/26

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 http://www.vmware.com/support/pubs/). To control console output to one page at a time by adding the | more suffix to the commands. For example:
esxcfg-vswitch –l | more

 Reference: http://vmware.com/files/pdf/vsphere-vnetwork-ds-migration-configuration-wp.pdf 

(See page 8)

2010/03/19

Number of ports to use for standard and distributed virtual switches

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

VMware just updated their KB: Reserved or overhead ports for virtual switches (http://kb.vmware.com/kb/1008040) and we’ve run into this issue a number of times since upgrading to vSphere ESX 4. These new high memory hardware architectures allow an unprecedented number of virtual machine guests to be consolidated on a single ESX host.

By default a vswitch may not have enough ports to support the consolidation ratio your equipment can support. New ESX hosts can have 256 GB of RAM with 4 hex core processors and easily support 100 or more virtual machines. These virtual machines might have 1, 2, or more vNICs configured and each would need a port on the vswitch. One might imagine the need for 500 to 1000 ports needed per esx host. Why not just make it 2000 so we don’t have to worry about it later on?

Once you run out of vswitch ports you cannot power on any more vms on that host and even get errors about unplugged network cable.  Increasing the vSwitch port allocation seems easy enough, vmotion all workload off the host, put it in maintenance mode, change the vswitch config, reboot. Some system administrators run into this issue and decide to make the number of ports allocated to the vswitch really high to prevent this from ever being an issue. This can cause problems though.

There’s a limit of how many vswitch ports in total an ESX host has to hand out to it’s various vswitches. In addition, if security is a concern, you may start running firewall virtual appliances like vShield Zones or Catbird. WAN Accerators and Performance Monitoring tools like AppSpeed also require additional vSwitches to be created. Ports used on these vSwitches all take away from the total bucket of available ports.

Once 4096 ports are allocated to existing vSwitches you will not be able to add additional hosts to a vNetwork Distributed Switch either.

We also have the following Security Recommendation:

Only allocate vswitch ports to virtual machines on demand and as needed.

This will make it difficult if not impossible to “plug” a VM into the wrong network by accident. Testing for this can be done manually through the vSphere Client. If there are no ports available on a vSwitch then this is a positive test.

1. While connected to the vCenter Server Navigate to Home – Inventory – Networking in the vSphere Client and click on the vDS in question.
2. Click on the Ports Tab
3. If all of the ports in the list have a VM associated with it in the “connected”column then this is a positive test.

Deployment scenarios where a very large number of uplinks are teamed together on a single virtual switch might significantly impact the number of  ports on that virtual switch available for virtual machine use, and the overall size of the virtual switch might need to be adjusted accordingly.
 
The current port utilization data for virtual switches can be reviewed by using the esxcfg-vswitch –list command.
 
The current overhead utilization on a given virtual switch can be calculated by subtracting the Used Ports value for all PortGroups from the Used Ports value for that virtual switch.

Recommendation: Use VNDS vNetwork distributed Switches for all Virtual Machine traffic and limit the number of ports assigned to each standard vSwitch used for vmkernel and service console.

Standard vSwitch Procedure:

Note: A server reboot is required to apply the following configuration change.  Migrate the virtual machines off the ESX host to prevent any downtime.   On the vswitch there is an option to specify the number of ports the vswitch supports.  

To view this setting:

  1. Click the Configuration tab of the ESX host in the Virtual Infrastructure Client (VI Client).
  2. Click Networking.
  3. Click Properties.

  4. Click on vSwitch.
  5. Click Edit.

  6. On the General tab select the number of ports you want and click OK.

 

  • Reboot the ESX host for changes to take effect.

    • Reference Links

    Powered by WordPress