Lab Scenario
As part of VMware vSphere4 implementation, you are set to assign physical adapter to an existing vSwitch.
According to the plan given to you by Network analyst, you need to assign a physical adapter to an existing
vSwitch for extra bandwidth and as part of a backup plan in case anyone of the physical adapter fails to send or
receive traffic.
Lab Objectives
• Using your personal lab, assign a physical adapter to an existing vSwitch
Lab Solution
Assign a physical adapter to an existing vSwitch:
Log on the ESX server using VMware vSphere client.
Choose the host from inventory panel and click Configuration
www.certifyme.com
Choose Networking from the configuration panel.
Select an existing vSwitch and click Properties.
113
www.certifyme.com
vSwitch Properties window appears. Select ‘Network Adapters’ tab
114
www.certifyme.com
Click ‘Add’ button at the bottom. The ‘Add Adapter wizard’ appears.
www.certifyme.com
Select unclaimed adapter and click Next
www.certifyme.com
You can pick the new adapter as an active adapter and the already assigned adapter as standby adapter by
clicking the ‘Move Down’ button. It is recommended to leave the already active adapter and assign standby
status to the new adapter. Click Next.
Review the adapter to added to the vSwitch and click Finish
www.certifyme.com
Now you can view the newly assigned adapter in the vSwitch properties. Click Close
www.certifyme.com
You can also view the newly assigned adapter in the vSwitch networking area.
Exam Objective: Assign Physical Adapters
Contents
• Introduction
• Technology Background
• Lab Scenario
• Lab Objectives
• Lab Solution
www.certifyme.com
Introduction
Physical Ethernet adapters serve as bridges between virtual and physical networks. In VMware vSphere, they
are called uplinks, and the virtual ports connected to them are called uplink ports. A single host may have a
maximum of 32uplinks, which may be on one switch or distributed among a number of switches.
In order for a virtual switch to provide access to more than one VLAN, the physical switch ports to which its
uplinks are connected must be in trunking mode. It is important to prune the VLANs, keeping only those that
are required for the virtual switch. Failure to do so can cause unnecessary overhead on the ESX Server host
because it must process broadcast traffic for all VLANs trunked to it.
Technology Background
You should prune VLANs at the physical switch level, but pruning at the physical switch cannot be quite as
aggressive as pruning at the uplink because the virtual switch knows which virtual machines are actually
powered on. As a result, the virtual switch may be able to prune VLANs that are needed but are not in use at the
time you are pruning.
You can specify different teaming behavior for different groups of virtual machines that share the same team of
physical adapters. For example, you can vary the active/standby status of each adapter in the team across port
groups to get both good link aggregation and failover behavior.
Teaming state — which physical Ethernet adapters are actually transporting data — is maintained for each
port group. Teaming state transitions are mostly transparent to virtual Ethernet adapters. Virtual machines
cannot tell when a failover has occurred or which physical adapter is carrying any given frame. When the
transition removes or restores actual access to a physical network — that is, when the last link goes down or
the first link comes up — the network visibility change is apparent to guests.
Uplinks are not required for a virtual switch to forward traffic locally. Virtual Ethernet adapters on the same
virtual switch can communicate with each other even if no uplinks are present. If uplinks are present, they are
not used for local communications within a virtual switch.
When VLANs are configured, ports must be on the same VLAN in order to communicate with each other. The
virtual switch does not allow traffic to pass from one VLAN to another. Communication between VLANs is
treated the same as communication between virtual switches — it is not allowed. If you do want
communication between two VLANs or two virtual switches, you must configure an external bridge or router to
forward the frames.
A virtual switch (vSwitch) can have multiple physical nics/vmnics/uplinks linked to it, but each “physical
nic”/vmnic/uplink can only be connected to a single vSwitch at a given time.
Keep in mind that if you want to connect a virtual machine’s “virtual nic” to the outside world, you do not
connect the “virtual nic” to a vSwitch. You connect a virtual machine’s “virtual nic” to a “Virtual Machine Port
Group”, and then you associate the “Virtual Machine Port Group” to a vSwitch. Along these lines, if two virtual
machines are connected to either the same “Virtual Machine Port Group”, or are connected to “Virtual Machine
Port Groups” on the same vSwitch, any network communication between the two will not flow through a
“physical uplink adapter”, it will remain “internal” to vSwitch/ESX server. This is why you don’t even have to
have any “physical uplink adapters” connected to a vSwitch. A vSwitch that is not connected to any “physical
www.certifyme.com
uplink adapters” is referred to as an “internal-only virtual switch”.
Keep thinking of the physical uplink adapters as “dumb bridge ports”. They do not have an IP address, their
“physical” MAC address will not appear on the network or anything like that. It is just a port through which
packets flow.
