An Ethernet adapter that is directly shared by multiple VMs
has two options for where the virtual Ethernet bridging
function is performed: at the server or in the external network.
Enterprise use cases exist for both of these options. An
example use case for performing VM-to-VM virtual switching
at the server, either in the Hypervisor or adapter, is High
Performance virtualized Computing. This use case provides
very low overheads VMs residing in the same physical server
to communicate, which becomes more and more important as
the number of cores per server, and hence number of VMs per
server, increases. An example for performing VM-toVM
virtual switching in the network is multi-tier enterprise
environments that want to take advantage of state of the art
network access and QoS controls. This paper will describe a
server virtual switching approach that satisfies both of these
use cases.
An additional problem that must be addressed is the
complexity associated with provisioning and orchestrating a
VM’s network identity. In today’s VM models, the MAC
Address is used to associate a VM to a specific port profile.
Without orchestration between the VM manager and the fabric
manager, there is no way for the fabric to distinguish between
a re-incarnated
A
and a migrated
B
MAC Address. As a result
the MAC Address alone provides insufficient information for
the fabric to determine which port profile to use, because a re-
incarnated MAC Address may have a different port profile
than its use on a previous VM. An automated, orchestration
solution to this problem is needed.
The following sections will describe options for solving
these problem areas.
I. VM
AUTOMATION AND OPTIMIZATION
Today’s server virtualization infrastructure (e.g. a
Hypervisor) associates a server side (e.g. Hypervisor or
adapter) Virtual Ethernet Bridge (VEB) port profile to each
A
A re-incarnated MAC Address is one that was previously in use by a
recently destroyed VM and is now in use by a different VM.
B
A migrated MAC Address is one that is associated with a VM that has
been migrated across two physical servers in the fabric.
Ethernet MAC Address used by a VM to access the network
through a VEB port. Examples of the a VEB’s port profile
attributes, includes: the types of frames allowed on the port
(e.g. all frames, Only Virtual LAN tagged frames or untagged
frames), the Virtual LAN identifiers that are allowed to be
used on egress, and rate limiting attributes (e.g. port or access
control based rate limiting). In today’s server virtualization
infrastructure, if the VM is migrated from one physical server
to another, the VEB’s port profile migrates with it. In other
words, today’s server virtualization infrastructure provides
automated port profile migration of the server’s VEB port(s)
that are associated with a VM.
For environments where the server’s virtualization
infrastructure provides sufficient controls, today’s automated
port profile migration approaches are fine. An example of
such an environment is a high performance cluster that uses a
layer-2 network which is isolated from external networks
through firewalls and security appliances.
However, Today there is a gap between the access and
Quality of Service (QoS) controls supported in external layer
2 switches and server virtualization infrastructure. That is,
external layer 2 switches have more advanced controls
compared to server VEB implementations. Server
virtualization infrastructure is continually adding these
controls, but we expect the gap will continue for several
reasons, including: deployment of directly shared IO adapters,
which cannot provide all the access controls available on
external switches due to PCIe adapter power/cost constraints;
and many network administrators prefer using common
controls, but many controls implemented in external switches
are proprietary.
Some environments prefer the more advanced controls
provided by external network switches. An example of such
an environment is a multi-tier data center that has several
types of applications, each with differing advanced network
controls, running over the same layer-2 network. In this type
of environment the network administrator often prefers the use
of advanced access controls available in external switches.
The following sections will explore alternatives for providing
these advanced controls and for maintaining port profile
associations when a VM migrates across physical servers.
Automated Port Profile Migration
Renato Recio
资源评论
