[email protected] www.xtravirt.com © 2009 | 1
Illustration 1-1: dvSwitch overview
white paper
New Networking Features in vSphere
Title: New Networking Features in vSphere
Author(s): Xtravirt (Peter Grant)
Target Audience: Technical - Intermediate
Current Revision: 1.0 (Jun 2009)
First Published: Jun 2009
Product(s): VMware ESX 4.0, vSphere
UID: XD10019
Content Overview:
• Summary of new networking features in vSphere and ESX 4.0
• Distributed Virtual Switch
• Cisco Nexus 1000V
1.0 IntroductionThis Xtravirt white paper gives an overview of the new
networking features included in vSphere. In addition
to the new VMware distributed virtual switch, it will
discuss the third party Cisco Nexus 1000V virtual switch.
This document assumes some existing knowledge of
virtual networking within a VMware environment.
2.0 OverviewVirtual Networking in ESX 4.0 has been improved with
the addition of two key features; the introduction of a
distributed virtual switch (dvSwitch), and the support
for optional third party virtual switches. The advantages
of the dvSwitch are that it permits policy-based
network configuration, as well as facilitating network
VMotion, where the state of the network connection is
maintained during a VM migration. It also provides some
enhanced functionality over the standard Virtual Switch.
Optionally, a third party vSwitch is now available from
Cisco who have developed a software-based vSwitch
in the form of the Nexus 1000V. This provides advanced
switching functionality and is a separately purchased
feature only available for sale (but not included by
default) with the Enterprise Plus version.
3.0 Distributed Virtual SwitchAs mentioned, within vSphere there is now the choice
of two different virtual switches. The first is the standard
vSwitch, as in ESX3.5, and the second is the distributed
vSwitch, or dvSwitch.
Note: The Distributed Virtual Switch is only available with the
Enterprise Plus version
Just like a standard vSwitch, the dvSwitch acts as a
logical network switch which can pass traffic internally
between VMs on the same host or externally via the
physical NICs.
[email protected] www.xtravirt.com © 2009 | 2
visit www.xtravirt.com for the latest version of this document
Unlike the standard vSwitch however, a single dvSwitch
can span multiple ESX 4.0 hosts, allowing a common
virtual networking configuration across multiple hosts.
This saves time by not having to configure identical
vSwitches across many hosts and reduces the chance
of problems caused by human error.
Another benefit of a dvSwitch is that the network
state now follows a VM during a vMotion event. In
ESX 3.5 if a VM was migrated using vMotion from one
host to another, the network state, including network
statistics, were lost. This made it difficult for network
administrators, who may have been troubleshooting
VM network connections or gathering network
statistics, as this data would have been reset. With ESX
4.0, the dvSwitch port follows a VM during a vMotion; as
a result the network state is maintained.
3.1 Distributed Virtual Switch – Architecture OverviewIllustration 1-1, from the previous page, represents one
complete dvSwitch, however multiple dvSwitches can
be configured if required. It shows the key components
of the distributed virtual switch, as well as a sample
configuration.
Note: This is for illustration purposes only and does not
necessarily represent a recommended design configuration
Perhaps the easiest way to understand it for someone
who is familiar with a standard ESX 3.5 vSwitch is to
first ignore the top physical NIC’s layer and think of
the dvNIC’s as the physical NIC’s in the Host. In this way
the bottom 3 layers from the dvPortGroup -> dvNIC’s
fit together the same as a standard vSwitch. Each
dvPortgroup is associated with one of more dvNIC’s and
just like a standard vSwitch these can be configured in
an Active/Standby/Unused state.
As these dvNIC’s represent virtual NIC’s (not to be
confused with Virtual Machine vNIC’s) which can span
multiple ESX Hosts, they must be bound somehow with
each individual Hosts physical NICs. This is represented
by the top layer. The dvUplinks can be bound in any
order however one physical NIC can only be bound
to one dvUplink, but one dvUplink can have multiple
physical NIC’s bound to it.
Below is an example of what a dvSwitch looks like from
the vSphere client:
3.2 New Features in the Distributed Virtual Switch• Inbound and outbound traffic shaping –
Previous versions of ESX allowed traffic shaping on
outbound packets only.
• Private vLANs – A private vLAN allows isolation of
network devices within the same IP subnet.
• Live port moving – This allows ports to be moved
whilst they are in use
• Network vMotion – Network statistic information
will now follow the virtual machine during a
vMotion. This provides enhanced security and
monitoring capabilities
3.3 Distributed Virtual Switch – PoliciesThe policies settings are similar to the standard vSwitch
policies with the addition of the new features listed in
section 3.2.
These policies can be applied at the Port Group objects
or the dvSwitch-Uplinks object within vCenter.
‘VReady’ Online Capacity Planning ServicesXtravirt VReady is a FREE virtualization readiness assessment service for VDI and Server Consolidation projects. Simply download the free-to-use agent-less Explorer tool and start collecting performance and hardware information for any number of servers or desktops in your organization for up to 14 days.
Register to start your FREE assessment today
[email protected] www.xtravirt.com © 2009 | 3
3.4 Distributed Virtual Switch – Example ConfigurationThe following is an example of how to create a single
dvSwitch configuration across two ESX 4.0 Hosts with
the following configuration:
• Hosts = 2
• Physical NICs available per Host = 3
• Distributed Virtual Uplinks = 4
• 2 Distributed Virtual Port Groups vPortGroup and
“dvPortGroup_Test and Dev”
Step 1a: Create a Distributed Virtual Switch
To configure a dvSwitch, within the vSphere client go
to Home -> Inventory -> Networking, right-click on
your Datacenter object and select New vNetwork
Distributed Switch.
Step 1b: Name dvSwitch and select dvUplinks
Give the dvSwitch a name and select the amount of
distributed virtual NICs to use.
Step 1c: Associate Hosts and Physical Adapters to
this dvSwitch
Select the Hosts that this dvSwitch will span and the
physical uplinks that this will use.
Step 1d: Confirm creation of default virtual machine
port group
By default a dvPortGroup called dvPortGroup will be
created. This can be renamed later.
Step 2: Create / modify Port Groups
To add a new port group right-click on the dvSwitch
and select New Port Group...
To modify the port group settings right-click on the port
group and select Edit Settings.... This will bring up the
configuration window as shown below. In this example
the “Test and Dev” port group have been assigned
dvUplinks3 and dvUplink4 as the Active (virtual) Uplinks
visit www.xtravirt.com for the latest version of this document
[email protected] www.xtravirt.com © 2009 | 4
Step 3: Modify dvUplink to Physical adapter
association
In order to modify which physical adapters on each
Host are associated with each virtual dvUplink go to
Home -> Inventory -> Hosts and Cluster, select
Networking and Manager Physical Adapters...
Add or Remove the Hosts’ physical uplinks (vmnics) to
the dvUplinks. This is done on a Host by Host basis.
Step 4a: Add Service Console and VMkernel Ports
In order to create a Service Console or VMkernel virtual
adapter for each Host go to Home -> Inventory ->
Hosts and Cluster, select Networking and Manager
Virtual Adapters...
Step 4b: Select the type of virtual adapter
Step 4c: Select the dvPort Group that this virtual
adapter should be a member of.
4.0 Third Party Virtual SwitchesVMware have exposed the ESX virtual networking
platform with ESX 4.0, allowing third party vendors to
produce their own virtual switches.
Cisco are the first to release a virtual switch for ESX 4.0 in
the form of the Nexus 1000V. This is a purely software-
based switch which replaces the VMware dvSwitch.
This offers all the features of the VMware vSwitch with
a number of advanced switching features commonly
found on Cisco and other standards based switches. It is
important to note thatthe Nexus 1000V does not come
standard with ESX 4.0 and is an additional purchase.
4.1 Cisco Command Line InterfaceThe Nexus 1000V provides the standard Cisco CLI which
allows network administrators who may not be involved
in the management of ESX to still maintain control and
visibility of the entire switching infrastructure using
familiar command line tools.
4.2 Nexus 1000V feature summarySome of the Nexus 1000V capabilities are listed below: • Cisco Command Line Interface – Allows (non-
VMware) network administrators to manage virtual switches just like their physical switches
• Policy based configuration via Cisco Virtual Supervisor Modules
• Network vMotion – Network statistic information will now follow the virtual machine during a vMotion
• Integration with ESX 4.0 and ESXi 4.0• SNMP management• Stateful supervisor failover• Role Based Access Control• Quality of Service (QoS)• Security: Private (vLAN, ACLs)• Monitoring: SPAN, NetFlow, ERSPAN• Advanced Layer 2 switching features• Private vLANs – A private vLAN allows isolation of
network devices within the same IP subnet
visit www.xtravirt.com for the latest version of this document
References1. ESX 4.0 Configuration Guide
2. Cisco Nexus 1000V Virtual Switch http://www.cisco.com/en/
US/prod/collateral/switches/ps9441/ps9902/data_sheet_c78-
492971.html
Useful Links1. Cisco Nexus 100V Virtual Switch, http://www.cisco.com/en/
US/products/ps9902/products_data_sheets_list.html
Tags
VMware, VMware Infrastructure, ESX, ESXi, VM, Virtual Machine,
Distributed Virtual Switch, Port Group, vSphere, Networking, Network
www.xtravirt.com © 2009 | 5
visit www.xtravirt.com for the latest version of this document
For a complete specification of the Cisco Nexus 1000V
visit the following URL:
http://www.cisco.com/en/US/products/ps9902/
products_data_sheets_list.html
This concludes the white paper.
About XtravirtXtravirt is a knowledge-based company that delivers its expertise in virtualization online and in person. We have developed a reputation for astute
leadership and expertise through our work with an impressive array of organisations. It is this real-world experience that drives our ability to provide
independent, current and free advice online.
We work with organisations whose IT staff are frustrated with how hard it is to find detailed information and skills around virtualisation. We help our clients
deliver the true benefits of virtualization, resulting in cost and time savings.
For more information contact:
Dorset House, Regent Park
297 Kingston Road, Leatherhead
Surrey KT22 7PL
t +44 (0) 1372 824 296
f +44 (0) 1372 824 576
w www.xtravirt.com
© Copyright 2009 Xtravirt Ltd. All rights reserved. The information contained herein is subject to change without notice. Xtravirt Ltd shall not be liable for technical or editorial errors or omissions contained herein. Xtravirt and the Xtravirt logo are registered trademarks of Xtravirt Ltd. The names of actual companies and products mentioned herein may be the trademarks or registered trademarks of their respective owners.