XS 60 Design Network - Advanced PDF

Citrrix Xe
enSerrver Design
D n:
Dessigninng XeenSerrver N
Netwo
ork
Connfigurration
ns
ww
ww.citrix.com
m
Contents
About ....................................................................................................................................................................... 5
nce ............................................................................................................................................................. 5
Audien
Purposse of the Guide ....................................................................................................................................... 6
ons ............................................................................................................... 6
Findingg Configuratiion Instructio
Visual Legend
L .................................................................................................................................................... 7
Additio ology ................................................................................................................................... 8

onal Termino
Chapter 1: on ....................................................................................................................................... 9
1 Introductio
Chapter 2: working Conccepts ..................................................................................... 11

2 Basic XenSServer Netw
Introduuction to Xen working .....................................................................................................11

nServer Netw
o Networks ................................................................................................12
Conneccting Virtual Machines to
Networrking Configguration afterr Installation......................

. .......................................................................14
Impactt of Pools on
n XenServer Networking
N ......................
. .......................................................................15
Sequen orking Configguration Taskks .........................................................................................18

nce of Netwo
Cabliing Configurration for XenServer .....................................................................................................18
Conn
necting XenSServer to Phyysical Switchees .........................................................................................21
Chapter 3:
3 Sample Neetworking Sccenario ....................................................................................................... 22
Examp
ple: Adding Virtual
V Machiines to a Nettwork ...................................................................................22
Creatting Networkk Resiliency through

t Bon
nds........................................................................................23
Conn
necting a VM
M to a Netwo
ork using Virttual Interfacees....................................................................25
Segreegating VM Traffic
T nt and Storagge Traffic........................................................27
from Managemen
Scenaario 1: Segreggating Traffic .................................................................................................................28
Scenaario 2: Usingg the Manageement Netwo

ork for VM T
Traffic ............................................................29
Scenaario 3: Isolatting VM Trafffic on a Privvate Networkk ......................................................................30
Scenaario 4: Conn
necting VMs to
t Multiple Linked
L VLAN
Ns ..................................................................34
Page 2
Chapter 4: nts ........................................................................................ 40
4 Specifyingg Networkingg Requiremen
Overview ..........................................................................................................................................................40
Introduuction .....................................................................................................................................................41
XenSerrver Networkking Supportt and Requireements ................................................................................42
Definin
ng Your Netw
working Reqquirements .................................................................................................43
Conssidering Worrkload Comm

munication Requirements
R .......................................................................43
work Configguration ...............................................................................45

Evaluuating Your Current Netw
Deteermining Hosst Networkin

ng Requiremeents ......................................................................................46
n against Nettworking Reqquirements ....................................................47

Revieewing Initial Pool Design
mber of Physsical NICs peer Host ........ .......................................................................49

Calculaating the Num
ments .........................................................................................................50
Calculaating Bandwidth Requirem
Chapter 5:
5 Designing XenServer Networks
N ................................................................................................... 52
Overview ..........................................................................................................................................................52
Decidin d Virtual Switch .......................................................................................53

ng to Use thee Distributed
ning Networkk Redundancy .................................................................................................................56

Design
Consid
dering NIC Bonding
B .............................................................................................................................56
Seleccting a Type of ding ............................................................................................................58

o NIC Bond
Undeerstanding Active-Active
A ng .........................................................................................58
NIC Bondin
Undeerstanding Active-Passive
A e NIC Bondiing........................................................................................60
Bond
ding Managem C Addressingg .....................................................................62
ment Interfaaces and MAC
Best Practices forr Bonded Intterfaces ......................................................................................................62
Design mance ........................................................................................................63

ning Networkks for Perform
Testiing XenServeer Network Performance

P ............................................................................................65
Limitting Bandwid
dth Consump Workloads ....................................................66
ption for Higgh Demand W
Additio
onal Consideerations .............................................................................................................................68
Enab
bling Promisccuous Mode for Traffic Monitoring
M ... .......................................................................68
Page 3
Chapter 6:
6 Designing Your Storagge Network Configuration
C n..................................................................... 70
Overview ..........................................................................................................................................................70
Creatin
ng a Separate Storage Nettwork..........................................................................................................71
Assiggning IP Add
dresses to NIICs (Managem
ment Interfaaces) ...............................................................73
Configuuring Redundancy for Sto

orage Trafficc ...........................................................................................75
Choo
osing to Enab
ble Multipath
hing Supportt or Bond NIICs .................................................................75
Suggesttions for Imp

proving Storage Networkk Performancce ...................................................................77
iSCSII Storage................................................................................................................................................77
Conffiguring Netw
works with Juumbo Framees ..........................................................................................78
Chapter 7:
7 Considerin
ng Network Performance
P e for PVS – X
XenServer D
Deployments ........................... 81
Virtualiizing the Pro

ovisioning Seervices Serverr ...........................................................................................81
IP Add
dressing Requuirements .........................................................................................................................83
Isolatin
ng the Provissioning Servicces Streamin
ng Service ............................................................................83
Disabliing the Spann

ning Tree Protocol ........................................................................................................83
Best Prractice Configurations .........................................................................................................................83
Chapter 8:
8 Verifying Your
Y XenSerrver Networkking Configuuration ........................................................... 85
Verifyin
ng XenServeer Networkin
ng on a Pool ......................
. .......................................................................85
Veriffying your Ph
hysical Confiiguration ....................................................................................................85
Veriffying your XeenServer Nettworking Setttings and Coonfiguration ..................................................87
Resolviing Issues ..............................................................................................................................................88
Revisio
on History ..............................................................................................................................................90
Page 4
Abo
out
This guid
de helps you understand
u design
d your XenServer
X neetworking annd design a neetworking
configuraation for Xen
nServer envirronments. It includes the following toopics:
 Best
B practice information
i about the primary managgement interfface, NIC bo
onding, jumb
bo
frrames, and sttorage netwo
orks
 High-level
H infformation about features you may wannt to enable as part of yo
our networkin
ng
co
onfiguration,, such as the Distributed Virtual Switcch solution
 The
T correct seequence in which
w to conffigure XenServer networkking, includin
ng guidance aabout
caabling XenSeerver hosts an
nd connectin
ng them to phhysical switcches
 Checklists
C to help
h you gath
her requirem
ments for youur XenServer networking configuration
Audie
ence
Before reeading this guuide, you sho
ould have a basic
b knowleddge of netwoorking. This gguide has sevveral
audiencess:
 Syystems Arch
hitects. Systeems architectts who are deesigning a virrtualized envvironment.
 In
nfrastructurre Engineerss and Netw work Adminiistrators. Neetworking and storage
professionals who configuure storage orr manage thee Layer 2 netw
work infrastrructure in theeir
organizations..
 Application
A Administrat
A tors. XenApp p and XenD esktop adminnistrators wh ho are
im
mplementingg a virtualizatiion solution to virtualize Citrix produucts, IT infrastructure, or
other applicattions they maanage.
Page 5
This guid de assumes th
hat you are faamiliar with basic
b XenSerrver conceptss, including X
XenServer
installatio
on, XenCenteer, resource pools,
p and th
he pool masteer.
Purpo
ose of the
t Guide
This guid
de is meant to
o provide youu with the beest-practice innformation yyou need to ddesign your
XenServeer networks.
To providde you with the

t foundatio on you need to understannd the recom
mmendations,, the first hallf of
the guide provides an explanation of XenServeer networkinng concepts uusing a scenarrio-based
approachh.
The secon
nd half of th
he guide provvides you with
h informatioon to help youu select betw
ween various
XenServeer networkingg options and informatioon about the bbest ways to configure thhem.
Because this
t is a desiggn guide, it geenerally doess not providee configuratioon instructio
ons except as
needed too clarify conccepts. As the most comm mon way of m managing XennServer and X XenServer pools
is throughh XenCenterr, this guide mainly
m refers to XenCentter and XenC Center help, uunless specifi
fied
differentlly.
Finding Con
nfigurattion Ins
structio
ons
You can find networkking configurration instrucctions in the following loccations:
 XenCenter
X Help.
H The XeenCenter helpp provides UUI-based stepp-by-step insttructions usin
ng
XenCenter,
X th
he XenServerr UI-based ad
dministrationn console. Ussers who are not comforttable
with
w the XenSServer xe commmands, mayy prefer this option.
 XenServer
X Ad dministrator’s Guide. The
T XenServerr Administratoor’s Guide pro ovides comm mand-
lin
ne based insttructions for performing networking ttasks. For integrators, it aalso providess
in
nformation about XenSerrver networkking from thee object-moddel perspectivve.
Page 6
Visua
al Legend
This guid
de relies heavvily on diagrams to explain
n key conceppts. These diaagrams use th
he followingg
icons:
Icon Meaaning
Virtu
ual Machinee. A virtual ccomputer thaat runs on thee XenServer host.
Virtu ual Interfacee. On a VM,, there is a loogical interfacce that appeaars

and functions
f like a NIC; thiss interface is known as a virtual interfacce. A
virtuual interface lets VMs send and receivee network traaffic. Some
prod duct literaturee refers to virrtual interfacces as VIFs aand virtual NIICs.
Netw work. A netwwork is the vvirtual networrk switching fabric built iinto
XenSServer that leets you netwoork your virttual machiness. It links thee
physsical NICs to the virtual innterfaces andd connects th
he virtual
interrfaces togetheer.
Hosst. A XenServver host is thhe physical seerver on whicch the XenSeerver

hypeervisor is running.
NIC
C. The physiccal network ccard (NIC) inn your host.
Pooll. A XenServver resource ppool or “poool” is a conneected group o

of
hostss which provvides a platfoorm on whichh virtual macchines run.
To jo
oin hosts to a pool, they rrequire broaddly compatib
ble hardware and
mustt be running the same XeenServer verssion and patcches.
Poolls comprise a pool masterr and suborddinate serverss known as ppool

mem
mbers (sometiimes also refferred to as ""slaves"). Thee pool master
Page 7
provvides a single point of conntact for all thhe servers in
n the pool and the
mastter will forwaard commandds to individuual pool mem mbers as
necessary.
Physsical Switch
h. The devicee on a physicaal network th
hat connects
netw
work segmentts together.
This guide may present

p physiical switches either as a th
hree-dimensional
physsical box or as
a a one-dimeensional paneel with ports.
NIC
C Bond. In th
his guide, encclosing NICss in green rep
presents a bo
ond.
A NIIC bond is a pair of NIC s configuredd so they logically function

n as
one network
n cardd. NIC bondding is also knnown as NIC C teaming.
Addittional Termino
T ology
These terrms appear in
n the sections that follow
w:
Primary Managemeent Interfacee. The primarry managemeent interface is a NIC asssigned an IP

address th
hat XenServeer uses for its managemennt network, iincluding, buut not limitedd to, traffic
between hosts,
h between a host and d Workload Balancing
B annd for live miigration.
VM trafffic. VM traffi
fic refers to network
n traffiic that originnates or termiinates from a virtual macchine.
This is so
ometimes refferred to as guuest traffic or
o VM/guest traffic.
Page 8
C
Chapte
er 1: Introduction
This docuumentation explains

e basicc networkingg concepts annd their appliication by ussing a series o
of
scenarios to illustrate the conceptss. The scenarrios begin im
mmediately affter installatio
on and end wwith
ng a VM to a network.
connectin
These sam mple scenarioos focus on three

t differen
nt types of nnetworks: Extternal Netwo orks, VLANss, and
single-serrver private networks.
n If you
y configurred the scenaarios demonsstrated in thiss guide, by thhe
time you finished, youu would create a deploym ment that lookked like the ffollowing illuustration.
This illustrration shows hoow virtual macchines connect too three differentt types of netwoorks: an externnal network, a
VLAN network,
n and a single-server private network..
Page 9
This guid
de explains th
hese types off networks byy providing thhe followingg information
n:
Chapter 2 introducess XenServer networking

n and
a explains how to preppare for XenSServer netwo orking
configuraation by conffiguring the physical
p infraastructure andd hardware layers in yourr environmennt,
includingg the correct sequence forr physically configuring nnetworking. T The chapter aalso discusses the
effect poo oling XenSerrver hosts haas on networkking and desscribes the neetworking coonfiguration aafter
installatio
on.
If you waant to read a list of XenSeerver networking definitioons before reeading this in
nformation, ssee
the Visuaal Legend on page 7. Otherwise, the definitions
d aree provided inn chapter 2 aas you read th
he
sections.
Chapter 3 provides several samplle scenarios that t illustrate how to add virtual mach hines to a
network. The first sceenario guidess you through h the processs of segregatiing different types of trafffic,
includingg storage and managemen nt traffic. Thee second scennario gives yoou an alternaative to dediccating
NICs to specific
s typess of traffic; itt shows an exxample of ussing the manaagement netw work for
managem ment and VM M traffic. The third scenariio shows an example of hhow to segregate traffic b by
creating a single-serveer private nettwork on a host.
Chapter 4 provides guidance

g abouut how to deetermine whaat networkingg configuratiions and
hardwaree your XenSeerver deploym ment will requuire. The chaapter includees tables with
h references tto
relevant information
i to
t help you jump to key information
i aabout how too define yourr NIC
configuraation, calculatte bandwidth
h requiremennts, and otherr topics.
Chapter 5 provides innformation about

a key dessign choices you will makke when creaating your
XenServeer networks, including wh
hether to usee the Distribuuted Virtual SSwitch, how to configuree
XenServeer network reedundancy (N
NIC bondingg), and how tto design XennServer netw works for
performaance.
Chapter 6 provides in nformation about

a how to
o create a sepparate physicaal network fo
or storage traaffic,
set an IP address on a NIC, configgure iSCSI multipathing,
m and configurre support foor jumbo fram mes.
This chappter also incluudes suggesttions for imp
proving storagge network pperformance and best
practices..
Chapter 7 provides innformation about

a how to o virtualize a Provisioningg Services serrver on
XenServeer using SR-IIOV. This chhapter also prrovides somee references tto best practtices for
XenServeer-Provisioniing Services deployments
d .
Chapter 8 provides in nformation about

a how too verify your XenServer nnetworking configuration n after
you physiically configuured it. This chapter provvides a proce ss for verifyiing networkin
ng on a hostt and
on pools as well as infformation ab bout resolvin
ng issues.
Page 10
Chapte
er 2: Ba
asic Xen
nServer Netwo
orking Concepts
This chap
pter includes the followin
ng topics:
 An
A introductio
on to XenServer networkking
 The
T network settings creatted during in
nstallation
Introd
duction
n to Xen
nServer Netwo
orking
XenServeer provides virtual
v networrking featurees that let youu build netwoorks for yourr virtual machines
the same way you build networks for physical machines.
The VMs connect to threee different typees of networks: an office netwoork, an internaal private netwoork, and a VL
LAN.
Page 11
You can connect virtuual machiness to your prod
duction netw work like youu connect phyysical machinnes
or build private
p netwo
orks within a host or poo
ol for testing, developmennt, or securityy purposes. Y
You
can connect virtual machines
m to yo
our VLAN networks
n usinng standard V
VLAN configurations.
The mostt important networking

n components
c XenServer
X leets you configgure are virtuual interfaces an
nd
networks:
 Virtual
V interffaces. Virtuaal machines connect
c to neetworks usingg virtual NIC
Cs, known ass
viirtual interfacces. Virtual in
nterfaces let VMs send annd receive neetwork traffic. You can assign
eaach virtual in
nterface its ow wn IP addresss and MAC address. Som me product liiterature refeers to
viirtual interfacces as VIFs and
a virtual NICs.
NI
 Networks.
N XenServer
X hass an internal virtual
v switchh, known as a network, th
hat lets virtual
machines
m on a XenServer host commuunicate with eeach other ussing the same networkingg
protocols thatt are used on
n physical nettworks.
A network is the t logical neetwork switch hing fabric bbuilt into XennServer that lets you netwwork
yoour virtual machines.
m It liinks the physsical NICs too the virtual iinterfaces andd connects th
he
viirtual interfacces together. These netwo orks are virtuual switches that behave as regular L22
leearning switches. Some veendors’ virtuualization prooducts refer tto networks aas virtual switcches
or bridges.
Conn
necting Virtuall Machiines to Networks
When youu are configuuring network connectivitty on XenSerrver hosts, yoour ultimate goal is to
connect the
t VMs to a network. To o do this:
1. Connect
C the host
h to a phyysical networkk. (For VMs without exteernal networkk connectivitty,
yo
ou would con
nfigure a privvate networkk instead.)
2. Connect
C the VM
V by creatin ng a Virtual Interface
I forr it and connecting the Viirtual Interfaace to
a network. Ass shown in th
he illustration
n on page 11,, the virtual iinterfaces on the VMs
co
onnect to networks in a host
h and then n connect to a physical neetwork throuugh the host’’s
NIC.
N
One way to think abo out these taskks is that youu need to connfigure conneectivity at both the hardw
ware
and virtuaal layers as sh
hown in the illustration th hat follows.
Page 12
This illustrration shows thhe order in whicch you should configure
c netwo rking in your vvirtual environmment: (1) Start
rt on
the physicaal infrastructuree layer, which means
m connectinng NICs to swi
witches; (2) conffigure the hardw
ware layer, whiich
means connnecting hosts to networks and configuring theese networks; (3(3) configure thee virtual layer, which means
attaching VMs
V to networrks through virrtual interfaces.
Importan nt: Configuriing networkiing in the ord der listed desscribed in “Seequence of N Networking
Configuraation Tasks”” on page 18 is critical. If you vary from m this sequeence, the primmary manageement
interface may not be configured
c coorrectly on each
e host. If tthis occurs, aall VMs in th
he pool may sstart
on the poool master an
nd not their home
h or optiimal servers.
Page 13
Netw
working Config
guration
n after IInstalla
ation
After insttallation, the XenServer host
h has all thee informationn it needs to connect to aat least one o
of
your exteernal networkks. This is because you deefine the folloowing netwoorking option
ns while instaalling
XenServeer:
 IP
P Address Configuratio
C on and Otheer Settings. Y You set the hhost’s initial XenServer
networking coonfiguration when you firrst install XennServer on thhe physical ccomputer.
XenServer
X Settup configurees options, suuch as the IP
P address connfiguration (D DHCP/static),
based on the values
v you prrovide duringg installationn.
 Network
N Connnectivity. XenServer
X in
nstallation preepares each N
NIC connectted to a switcch
fo
or network connectivity by b creating on ne network ffor each NICC. This mean
ns that if the h
host
has, for exampple, three NIICs, XenServver creates thhree networks: Network 00, Network 1,
Network
N 2. Fo
or a visual exxplanation, seee page 15.
 Primary
P Man nagement In nterface and d the Manag gement Nettwork. Durin ng XenServerr
Seetup, you speecify an IP ad
ddress for onne NIC. XennServer uses tthat NIC to connect to yyour
organization’ss network and d to carry maanagement trraffic for funnctions like communicatin ng
with
w other hosts in a pool,, XenCenter, Workload B Balancing, annd other commponents. Thiis
NIC
N is known n as the primaary managemennt interface. Thhis is the onlyy NIC that Seetup configuures
with
w an IP add dress.
The illustration th
hat follows sh
hows a regulaar (unconfiguured) NIC annd a NIC con
nfigured as a
primaary managem ment interfacee.
This illustrration contrastss a regular NIC

C with one conf
nfigured as the pprimary managgement interfacce. The primaryy
managemennt interface hass an IP addresss, subnet mask,k, and gateway assigned to it.
Page 14
During in
nstallation, XenServer
X also
o creates a seeparate netw
work for eachh NIC it deteccts on the ho
ost.
Unless yo
ou change thiis set up, XennServer uses the additionnal NICs on tthe host for VM traffic o only.
The illusttration that fo

ollows shows an examplee of XenServver’s initial neetwork configguration
followingg installation.
This illustrration shows hoow, during insttallation, XenS

Server lets you cchoose a NIC as the primaryy management
interface. In
I this case, the administratorr selected NIC00. XenServer uuses the other N
NICs for VM traffic.
Most envvironments reequire additioonal configurrations to theese basic nettwork settinggs. These can
n
range from creating pools
p to integgrating additio
onal networkks, connectinng your VMs to those
networks, and configuuring a separrate storage network.
n Thee scenarios inn the followinng chapter
provide examples
e of these
t tasks.
Note: If you plug anyy NICs into switches

s after installing XXenServer, if you cannot ssee the NICss in
XenCenteer or xsconsoole, you migh
ht need to eitther a) run xxe pif-list or xe pif-plug in the CLI o
or
reboot th
he XenServerr host.
Impact of Po
ools on
n XenSe
erver N
Network
king
Networkiing is a pool--level featuree in XenServeer. When youu change netw
tworking on tthe pool masster,
XenServeer synchronizzes all hosts ini a pool to use
u the samee network setttings.
As a resuult, for XenSeerver to operrate correctly, you must ennsure that neetwork settin
ngs match acrross
all hosts in
i the pool, including:
i
 Which
W NICs are
a bonded
 Which
W NICs are
a configureed as the prim
mary manageement interfaace
 Which
W NICs connect
c to sttorage
Page 15
The netw
works to whicch NICs conn
nect must bee the same onn the correspponding NIC
Cs on each ho
ost in
the pool.
This illustrration shows tw

wo hosts joined together in a pool
p before any networking connfiguration is pperformed on thhem.
Ideally, yoou should ad

dd all desired hosts to thee pool beforee configuringg any networkk settings.
Pooling the
t hosts befofore configuriing networkiing creates clleaner recordds in XenServver’s internall
networkin ng-configuraation database.
Page 16
These two illustrations shhow how XenSeerver replicates the network seettings created oon the pool maaster on all otheer
hosts in thee pool. In the top
to illustration, NICs 3 and 6 on both hosts ts use Network ks 3 and 6. In tthe bottom
illustrationn, after reconfiguuring NIC 3 on
o the pool masster to use Netw
twork 12 and N NIC 6 to use NNetwork 18,
XenCenterr automaticallyy configures the other host in thhe pool to use tthose settings.
After creaating a new pool

p or joininng a host to an
a existing ppool, XenServver automaticcally replicates
the netwoork settings on
o the master to the joiniing hosts.
When youu use XenCeenter to makee networkingg changes, XeenCenter chaanges the oth
her hosts to
match thee newly mod
dified host. When
W you usee the CLI to cchange netw
work settings, you must either:
 Change
C each host
h manuallly to match th
he modified host’s settinggs
 Make
M the chan
nge on the pool master an
nd restart alll the memberr hosts in thee pool
XenServeer requires neetwork settin

ngs to match across the p ool because of features th hat use live
migration
n, such as XeenMotion, Hiigh Availabiliity, and Worrkload Balanccing. These ffeatures enab ble
the physical server ho t change at any time, andd possibly auutomatically w
osting a VM to without yourr
interventiion. Therefore, the VMs must be ablee to access allll of their targget networkss regardless o
of
which hoost XenServerr moves them m on to.
Page 17
For this reason,
r it is critical
c to havve and maintaiin an identicaal physical caabling, NIC, aand switch
configuraation for eachh host acrosss the pool. Liikewise, Citriix strongly reecommends cchanging thee
physical configuration
c n on all hostss in a pool beefore changinng network ssettings on th he pool.
Importan nt: After join

ning the hostts to the pooll, check the pprimary mannagement inteerface on eacch
member host
h to makee sure that it has its own unique
u IP adddress and/or set the corrrect static IP
address.
Sequ
uence of
o Netwo
orking Configuration
n Tasks
s
Citrix reccommends peerforming yo our initial nettworking connfiguration inn the sequencce that follow
ws to
help ensuure XenServeer stores yourr networkingg configuratioon correctly:
1. Cablee the hosts byy plugging alll NICs into the

t appropriaate switches,, as describedd in “Cablingg
Confi
figuration forr XenServer”” on page 18.
2. Confi
figure the swiitches. See “C
Connecting XenServer
X too Physical Sw
witches” on p
page 21.
3. Installl XenServer on the hostss. Citrix recom mmends thaat you ensure your networrking
configguration is seet up correcttly before creeating a resouurce pool, sinnce it is usuallly easier to
recovver from a baad configurattion in a non--pooled statee. To verify nnetworking iss set up correectly,
see “C
Chapter 8: Verifying
V Youur XenServer Networkingg Configuratiion.”
4. Creatte a pool of the hosts, if you

y want to pool
p them. Seee “Impact oof Pools on X
XenServer
Netw
working” on page
p 15.
5. Confi
figure NIC bo
onds and nettworks. For more
m inform
mation, see thee scenarios in
n “Chapter 33:
Samp
ple Networkin
ng Scenario.””
Importan nt: Do not configure the XenServer HighH Availabbility feature uuntil after yo
ou complete yyour
networkinng configurations. Netwo orking configguration can iinterrupt thee High Availaability heartb
beat
and causee hosts to shuut themselvees down. Connsequently, thhe hosts probbably will no
ot reboot correctly
and will need
n the host-emergenccyha-disablee command tto recover.
Cabling
g Configuration for XenServe
er
Citrix reccommends pllugging the physical
p Etheernet cables innto all the NNICs and the appropriate
switches before installling XenServver. The ideaal process is aas follows:
1. Iff you did nott cable your hosts

h before installation, pplug all the N
NICs in each
h host in the pool
in
nto the approopriate switchh ports.
2. Connect
C the correspondin
c ng NICs on each
e host in tthe pool to thhe same physical switch ((that
iss, the same suubnet).
The
T term correesponding referrs to the NIC
C of the samee number onn another hosst. For example,
NIC
N 3 on Host 1, NIC 3 on o Host 2, NIC
N 3 on Hosst 3. This meeans that each h individual N
NIC
Page 18
on every host must connecct to the sam
me physical neetwork as the NIC in thee same positio
on
on all other ho
osts in the po
ool.
The follo
owing figure is
i a visual exaample of thiss configuratioon in an enteerprise enviro
onment.
This illustrration shows hoow each correspponding NIC on must physically connect to the ssame network. Each
o both hosts m
switch reprresents a separaate physical netw
work. Each member host’s N
NICs must be cconnected to thee same physicall
a the corresponnding NICs on the pool masteer.
networks as
Ensuringg the cabling on each hostt in the pool is correct is critical. As shhown in the previous
illustratio
on, all NICs must
m connectt to the samee physical nettworks (show wn as separatte switches) aas the
NICs in thet same possition on all hosts
h across the
t pool.
In an envvironment wiith only one logical

l switch
h (for exampple, one that hhas a hierarcchy of switch
hes
that form
m one large ph
hysical netwo
ork), you onlly need to coonnect the NIICs to switch hes on that
t have thee same physiccal or logical (VLAN) connnectivity. T
network that The example tthat follows
shows hoow you mightt cable such an
a environm ment.
Page 19
This illustrration shows tw
wo switches thatt are connectedd across a backpplane and are oon the same phy
hysical network..
These switcches function log
ogically as one unit.
u Because thhere are no VL LANs configuured on any of tthe ports and all
ports have the same conneectivity, the NIICs can be plugg gged into any poort on these tw
wo switches.
XenServeer cannot dettect if you make any errorrs while settiing up the phhysical netwo ork. For exam
mple,
if a XenServer host exxpects to be able to contaact a specific gateway usinng a certain N NIC, XenSerrver
cannot in orrect. If you receive errorrs, they mighht not indicatte network
ndicate the caabling is inco
configuraation as the cause.
c
Ensuringg that the corrresponding NIC

N on each h host has thee same netwoork configuraation is whatt
ensures th
hat a host’s VM
V attached to, for exam mple, Networrk 1, can commmunicate wiith a VM attaached
to Netwoork 1 on anotther host. Thhis ensures thhat if you miggrate a VM too a new hostt, the VM rettains
the same physical connnectivity afteer migration..
Note: Wh hen you configure netwo NICs plugged in to switches,

orking, if youu do not havee all of your N
you mustt have, at a minimum,
m thee NIC(s) for the
t primary m managementt interface on n all hosts in your
pool pluggged into youur network. Otherwise,
O th
he pool masteer cannot synnchronize itss network setttings
to the meember hosts. Likewise, if you are usingg a dedicatedd NIC for stoorage, you m
must also conn nect
the cabless for that NIIC on each hoost.
Page 20
Connec
cting XenServer to Physical Switchess
When youu are conneccting a XenSeerver host to a switch, coonfigure the sswitch’s ports differently than
you woulld when connnecting a worrkstation to a switch. Theere are speciffic, critical guuidelines abo
out
the Spann
ning Tree Prootocol (STP)) and enablin
ng PortFast.
For moree information

n, see CTX1223158 -- Conssiderations for X
XenServer Sw
witch Ports.
Page 21
Cha
apter 3: Samplle Netw
working
g Scena
ario
This chap
pter providess a scenario-b
based example of how to connect virttual machines to a physical
network. This includees the followiing:
 Seegregating traffic
 Using
U the man
nagement neetwork for traaffic in a veryy small envirronment
Exam
mple: Ad
dding Virtual
V Machin
nes to a Netwo
ork
This sectiion provides a sample sceenario of a siimple networrking configuuration that iincludes
connectin
ng VMs to neetworks, creaating redundaancy, and connfiguring NIICs.
Designingg a XenServeer networking deploymen nt may requirre several tasks, includingg, for examplle,
configurinng redundanncy for netwo ork availabilitty, configurinng NICs, andd, ultimately, connecting V
VMs
to the dessired networkks. During th
his process, you
y might alsso separate ddifferent typees of traffic fo
or
security or
o performan nce reasons (ffor example, separating trraffic for maanaging the X XenServer
platform from VM traaffic).
Before co
onfiguring neetworking onn a pool, you should knoww to which nnetworks youur VMs will n
need
to connecct. A standarrd network co
onfiguration process migh
ght require:
1. Configuring
C reedundancy fo
or network availability.
a
2. Creating
C separrate storage or
o managemeent networkss (used to sepparate managgement or sto
orage
trraffic from VM
V traffic).
3. Creating
C VMss and connecting them to the desired X
XenServer nnetwork(s).
This sectiion provides you with an example of that process.. This sectionn describes th he different
configuraation optionss and steps reequired to puut your virtuaal machines oon the netwo
ork by using a
Page 22
sample sccenario. Whille the scenariio might not directly applly to your ennvironment, iit is designedd to
put XenSServer’s netw
working featurres into conttext.
Creatin
ng Networrk Resilien
ncy throug
gh Bonds
After joinning all hostss to your poo
ol, you may want
w to ensurre that any crritical serverss have high
availabilitty access to th
he network. One way XeenServer lets you achieve high networrk availabilityy is to
create reddundancy thrrough NIC boonding.
NIC bonding is a tech

hnique for in
ncreasing resiiliency and/oor bandwidthh in which ann administratoor
configurees two NICs together so they
t logicallyy function as one networkk card. Both NICs have tthe
same MAAC address annd, in the casse of manageement interfaaces, have onne IP addresss.
XenServeer supports bonding

b two NICs
N togetherr on a host. IIf one NIC inn the bond ffails, XenServver
automaticcally redirects traffic to th
he second NIIC. NIC bonnding is also ssometimes kknown as NIC C
teaming.
You can use

u XenCentter or the xe CLI to creatte NIC bondds. If XenCennter is managging a pool,
XenServeer automaticaally replicatess the bondingg configuratiion across alll hosts in thee pool.
In the illuustration thatt follows, thee primary maanagement innterface is boonded with a NIC so that it
forms a bonded
b pair of
o NICs. Xen nServer will use
u this bondd for manageement trafficc.
This illustrration shows thhree pairs of bonded NICs, inncluding the priimary managem
ment interface. E
Excluding the
Primary Management
M Intterface bond, XenServer
X uses the other two NNIC bonds andd the two un-bonded NICs fo for
VM traffiic.
Page 23
Ensuring
g Resiliencee through Redundant
R Switches
S
When VM M networks use

u bonded NICs,
N traffic is sent over both NICs. If you conneect one of the
NICs in a bond to a second
s (redunndant switch h) and a singlle NIC or sw
witch fails, thee virtual macchines
remain on
n the networrk since their traffic fails over
o to the oother NIC/sw witch.
Provided you enable bonding

b on NICs
N carryin
ng only guest traffic, bothh links are acttive and NIC
C
bonding can
c balance each
e VM’s trraffic between NICs. Likeewise, bondinng the primaary managem ment
interface NIC to a seccond NIC alsso provides resilience.
r Hoowever, onlyy one link (NIIC) in the bo
ond is
active and
d the other reemains unused unless traaffic fails oveer to it.
If you bo
ond a manageement interfaace, a single IP
I address is assigned to the bond. Th
hat is, each N
NIC
does not have its own
n IP address; XenServer treats
t the twoo NICs as onne logical con
nnection.
Note: Wh hile NIC bon

nding can provide load balancing for traffic from multiple VM
Ms, it cannot
provide a single VM with
w the thro oughput of tw
wo NICs.

ollows shows how the caables and netw
work configuuration for th
he bonded N
NICs
have to match.
m
This illustrration shows hoow two NICs in

i a bonded paair use the samee network settinngs, as represennted by the netw
works
in each hosst. The NICs ini the bonds connnect to differennt switches for redundancy.
Note: Fo
or more inforrmation abouut bonds, seee “Considerinng NIC Bondding” on pagge 56.
Page 24
Connec
cting a VM
M to a Nettwork usin
ng Virtual Interface
es
Virtual machines
m conn nect to a netwwork througgh a virtual innterface on thhat particularr network.
XenServeer sends the VM’s
V traffic through the target netwoork’s associatted NIC. By default, when n you
create a VM
V in XenCeenter, XenSeerver creates a virtual inteerface conneccting the VM M to Networkk 0.
This conffiguration letts VMs connect to an external networrk through thhe NIC attach hed to Netwwork
0.
You needd a virtual intterface on a VM

V for each separate phyysical networrk to which yyou want to
connect it.
i In environ nments that connect
c to on
nly one physiical network,, the virtual iinterface
XenCenteer creates byy default when n you create a VM may bbe sufficient ffor your needds. Howeverr, if
you need a VM to con nnect to mulltiple physicaal networks, yyou must creeate a virtual interface forr each
one of th
hose networkks.
This illustrration shows hoow VMs requiire a virtual intterface for each physical netwoork to which thhey need to connnect.
Page 25
Some add
ditional pointts about virtuual interfacess:
 Most,
M ne virtual inteerface. (If an administrato
but nott all, VMs havve at least on or accesses a VM
only through XenCenter,
X the
t VM doess not need a vvirtual interfface.)
 Each
E virtual in
nterface musst have a “virrtual” MAC aaddress. Youu can configuure XenServeer to
geenerate thesee automaticallly for you (reecommendedd) or specifyy them manuaally.
 When
W you creeate a networrk in XenCennter, you can specify if yoou want XenC
Center to creeate a
new virtual interface for th
hat network automatically
a y, whenever yyou create a VM.
 Unlike
U for thee physical and
d infrastructuure layers, thhe networkingg configuratiions on VMs do
not need to match
m other VMs
V in the po ool.
Notee: To determiine which VM M is associateed with a virrtual interfacee, see CTX1222520 -- How
w to
Find which
w Virtual Network Interrface is Assigned to a Virtuaal Machine in X
XenServer.
Understtanding Vir
irtual MAC
C Addressin
ng
Just like NICs

N in the physical
p worlld, each virtuual interface m
must have itss own (virtuaal) MAC adddress.
When youu create a virrtual interface, you can either specify a MAC addrress manuallyy or let XenServer
generate one for you.
When XeenServer generates MAC addresses auutomatically, it generates llocally adminisstered addressess.
Locally ad dministered addresses
a aree addresses assigned
a to deevices by a uuser, which tyypically lack
manufactturer-specificc encoding. As A a result, thhey do not coontain a mannufacturer-specific
Organizatiionally Uniquee Identifier (OU UI). Typicallyy, manufactuurers “burn-iin” MAC adddresses in wh hich
the first three
t octets in
ndicate which company manufactured
m d the device.
This meaans that the MAC

M addressses XenServeer generates w
will not clashh with addressses from harrdware
devices on
o your netwo ork.
XenServeer generates a MAC addreesses at random based onn the random m seed in the VM.other-
config:mac--seed parameter of the VM
M and the devvice number of the virtuaal interface (aa sequence
number forf the VIF: 0…6).
0
A particuular combinattion of a MA AC seed and device

d numbber always ressults in the saame MAC
address. Consequently
C y, if you remove a virtual interface froom a VM andd recreate it llater, the new
w
virtual intterface typicaally gets the same
s MAC asa before.
XenServeer preserves MAC

M addresses when miigrating VMss. However, w when you copy or clone V
VMs,
the VM receives
r a new
w random MAC
M address seed and thee virtual interrfaces get new
w MAC addrresses
based on that seed.
Tip: To obtain
o the MAC
M address of a XenServver VM in X
XenCenter, seelect the VM’’s Network ttab,
select thee virtual interrface, and clicck Propertiees.
Page 26
Segreg
gating VM Traffic fro
om Management a
and Storag
ge Traffic
You can separate each h type of trafffic –VM, sto
orage, and maanagement trraffic – onto
o its own netw
work
for eitherr security or performance
p e reasons.
For mostt environmen nts, Citrix reccommends seegregating VM traffic froom managem ment traffic ass the
best practice. Not onlly does it incrrease the seccurity of the m
managementt network, it can improvee
performaance by reduccing competiition between n traffic types for networrk resources, reducing
potential collisions, an
nd reducing thet load on the
t primary m management interface.
There aree a variety off ways in whicch you can seeparate traffiic, including::
 Seeparating all types of trafffic from each

h other. For example, puutting the virttual machines on
a network nott used for sto orage or man nagement trafffic.
 Seeparating thee managemen

nt traffic from
m the VM annd storage traaffic.
Howeverr, VMs will only use a NIC

C for VM traaffic if they hhave a virtuall interface on
n the same
network as
a the NIC. The
T illustration that follows shows thhe best practicce example o of how you m
might
separate traffic.
t
This illustrration shows hoow NICs that are not designaated for managgement or storagge traffic only ccarry VM traffffic.
While sepparating trafffic is a best practice in largger environm

ments, it is noot an absolutte requiremen
nt for
all enviro
onments. In smaller
s enviro
onments, youu may want tto configure VMs to sendd their trafficc on
the manaagement netw work. Howevver, Citrix reccommends evvaluating thee performancce of this
configuraation regularlly.
Page 27
The scenarios that folllow illustratee both of theese concepts:: separating ttraffic and sending traffic over
NICs shaared by multiiple networkss.
Scenarrio 1: Segregating Traffic

T
In this scenario, an ad
dministrator wants
w a dediccated networrk for managgement and sstorage trafficc. To
do this, th
he administraator:
 Attached
A the network
n cablles coming frrom the NIC Cs to a switchh for a netwo
ork to be useed for
VM
V traffic, whhich is physiccally isolated
d from the stoorage and maanagement n networks
 Created
C virtuaal interfaces on
o the same networks as the NICs
ollows shows these segreegated networrks.

This logicaal illustration shhows segregatedd guest, storage,, and managem

ment networks. In this scenariio, all the VM Ms
using netwoork 2 can comm municate with each other becaause they are coonfigured to usee the same (corrresponding) NIIC
bond on thheir respective hosts and that bond
b connects too the same physsical network. L Likewise, the ttwo VMs connnected
to network 3 can communnicate with eachh since the corre responding NIC C 7 on each host connects to tthe same physiccal
switch.
As shownn in previouss illustration, not all NICss have virtuall interfaces aassociated witth them. If yyou
do not co
onfigure a virrtual interfacee connectingg to the manaagement netw work, the maanagement N NIC
becomes dedicated foor managemeent traffic. Fo or example, inn the previouus illustration
n there are N
NICs
Page 28
connected d to the man
nagement and
d storage nettworks that ddo not have ccorrespondin
ng virtual
interfacess.
Note: Cittrix does nott recommendd assigning IP

P addresses ((that is, creatting managem
ment interfacces)
for each NIC
N on yourr host. Ideallyy, Citrix doess not recomm
mend using aany NICs witth IP addressses
assigned to
t them for VMV traffic.
Scenarrio 2: Usin
ng the Managemen
nt Networkk for VM T
Traffic
In enviro
onments withh minimal seccurity requireements, you ccan configuree VMs to shaare the
managem ment or storagge networks.
In this exxample, the organization
o uses
u the man
nagement nettwork for tw
wo purposes:
 XenCenter
X can connect to
o the management networrk through thhe primary m management
in
nterface on th
he pool mastter. This is beecause of thee IP address on that NIC. Likewise, h
hosts
an
nd other commponents, suuch as Worklo oad Balancinng, can use thhe connection
n to
co
ommunicate with XenSerrver.
Note:
N XenCenter only commmunicates with
w the poool master andd not any member serverss.
Sp
pecifically, XenCenter
X on
nly connects to the IP adddress of the m
master’s prim
mary management
in
nterface.
 VM
V traffic is also
a sent on this
t managem ment networrk. This is thee default con nfiguration an
nd
reequires no ch
hanges. To reevert to this configuration
c n, create a virrtual interfacce on the VM
M and
sppecify the VM
M network th hat is sharingg the manageement networrk.
This conffiguration letts (1) XenSerrver use the NIC

N configurred as the prrimary managgement interfface
to communicate with other hosts and (2) VMss transparentlly forward guuest traffic onto that netw
work
and back.
Howeverr, this configuuration has security implications. Worrkstations hoosting XenCeenter and
XenServeer hosts usingg this managgement netwo ork can comm municate witth each otherr because theey are
on the same network. This makes the managem ment networrk, which ultiimately manaages the harddware
layer and controls thee hypervisors themselves, vulnerable to any attackss originating from the VM Ms.
For exammple, if the VMMs host Web b servers, anyy successful attacks originnating from outside the
organizattion can poteentially penetrate your enttire virtual innfrastructure – or all infraastructure on the
targeted pool.
p
In contraast, scenario 1 on page 28 separates th network, which

he VM trafficc from the management n
confines any successfuful external atttacks to the guest network.
The follo
owing illustration shows some VMs seending their V
VM traffic ovver the manaagement netw
work.
Page 29
This logicaal illustration shhows how the administrator
a coonfigured the vi
virtual interfacees on VM 1 annd VM 3 to seend
their trafficc across the maanagement netw
work.
Note: Virtual interfacces appear differently in Linux

L and Wi
Windows VMss:
 n a Windowss VM, the iniitial Windows installationn has an emullated network device thatt uses
In
a built-in driveer.
 In
n a Linux VM
M, the NIC appears
a as a standard
s Linuux network ddevice and usses the high-
sp
peed Xen parravirtualized network drivver.
After youu install the XenServer

X To
ools (for Win
ndows guestss), Windows also uses higgh-speed
paravirtuaalized network drivers.
Scenarrio 3: Isola
ating VM Traffic
T on a Private
e Networkk
You migh ht have speciific types of workloads
w th
hat require isoolation. For eexample, in eenvironmentts
with tech
hnically savvyy workers, yoou might not want serverss with confiddential emplo oyee data on the
same netw work as reguular VM traffi
fic. XenServeer lets you seggregate traffiic by creatingg two types o
of
private neetworks: singgle-server priivate networkks and cross--server privatte networks.
Private neetworks do not

n have an uplink
u or a ph
hysical NIC. Private netw works connecct VMs on thhe
same Xen nServer host or the same resource poo
ol. In a privaate network, V
VMs can onlly communiccate
with VMss on the samme switch on the
t same hosst. In the case of cross-seerver private networks, V
VMs
can only communicatte with VMs on the same vSwitch.
Page 30
Essentiallly, a private network
n funcctions like an
n isolated local area netwoork that is local to either a
host or a group of hosts (pool). Th his results in higher speedd networks ssince responsses between V VMs
are based
d on the storaage speed and d not limitedd by the netwwork bandwiddth or bottlen necks.
Due to th
he speed, lab machines an
nd test enviro
onments are a good use ccase for privaate networks..
Creating private netw
works might also
a be desiraable for thesee reasons:
 Security. Singgle-server and d cross-serveer private nettworks can leet you isolatee VMs from o other
network traffiic (almost like creating a virtual
v “stovee pipe”). Privvate networkks and cross-
seerver private networks are completelyy isolated from m regular neetwork trafficc. VMs outsidde of
he private network canno
th ot sniff or injeect traffic intto the netwoork, even if booth sets of V
VMs
arre on the samme physical server and thee virtual interrfaces on both sets of VM Ms transmit
trraffic across virtual
v interfa
faces connectted to a netw work on the ssame underlyying NIC.
 Faster
F trafficc for connections betweeen VMs on the same h host. Becausee VMs do not
need to interaact with regullar network and
a switches,, they can traansmit trafficc faster to eacch
other.
Private neetworks provvide connectiivity only bettween VMs oon a given X XenServer host and do no ot
have a co
onnection to the outside world.
w Netwo orks with a NNIC (PIF) association aree considered
external: they providee a bridge bettween virtuall interfaces annd the NIC cconnected to
o the networkk,
enabling connectivity to resourcess available thrrough the NIIC.
Note: In previous XeenServer releaases, single-sserver privatee networks w

were known aas internal
networks.
Scenario
io A: Isolatiing VM Trraffic on On
ne Host
If you havve some VM Ms on one host that you dod not want oon your organnization’s neetwork, you ccan
create a siingle-server privvate network. This
T is an intternal networrk that has no association
n with a physsical
network interface.
i It only
o connectts the virtual machines onn the host annd has no con nnection to tthe
outside world.
w

ollows shows a private neetwork confiigured on onne host.
Page 31
This illustrration shows hoow the virtual interfaces
i on thhe VMs are onn the single-servver private netw
work. This netw
work
does not haave any connectt to any NICs since all trafficc is sent inside tthe XenServer host.
To createe a single-servver private network that is

i isolated froom the exterrnal network,, you
1. Create
C a singlee-server private network in XenCenteer.
In
n XenCenterr, select the host
h in the Reesource panee. Click the N
Network tab. Click Add
Network
N and
d then select Single-Serve
S er Private N
Network.
Unlike
U when you
y create exxternal netwo
orks, XenCennter does nott prompt youu to specify a
NIC
N when you create privvate networkss. This is beccause private networks do
o not require a
NIC
N for conn nectivity.
2. Create
C a virtuaal interface on
o each VM that
t specifiess the new priivate networkk.
Iff you want to

o isolate the VMs’
V traffic completely, iif necessary, remove any virtual interffaces
on the VMs th hat are on ann external nettwork.
Note: To o create crosss-server privaate networks, see CTX1330423 - Citrixx XenServer 6..0 vSwitch
Controller User Guide.
Scenario
io B: Isolati
ting VM Trraffic on Crross-serverr Private Ne
Networks
Cross-serrver private networks

n are similar to sin
ngle-server pprivate netwoork except cro
oss-server prrivate
networks let VMs on different hossts communiicate with eacch other. Crooss-server prrivate networrks
combine the isolationn properties of nal ability to span
o a single-serrver private nnetwork withh the addition
Page 32
hosts acro
oss a resourcce pool. This combination
n allows the uuse of VM aagility featurees, such as
XenMotion (live migrration) and Workload
W Ballancing (WLB B), for VMs connected to o those netwworks.

n are completely isolated.
i VMMs that are noot connected to this type o
of
private neetwork canno ot sniff or inject traffic in
nto the netwoork, even whhen the VMs share a host that
has virtuaal interfaces connected
c to
o two differen nt networks that use the same NIC.
While VLLANs provid de similar fun

nctionality, crross-server prrivate netwoorks provide iisolation with
hout
requiring physical-swiitch configurration.

n pro
ovide the follo
owing benefi
fits:
• The
T isolation properties off single-serveer private nettworks
• The
T ability to span a resouurce pool, enaabling VMs cconnected too a private neetwork to livee on
multiple
m hostss within the same
s pool
Because cross-server
c private
p networks require a NIC with aan IP addresss, to configuure these
networks you must crreate a managgement interface. Cross-sserver privatee networks can use any
managem ment interfacee as the undeerlying netwo
ork transportt. However, iif you choosee to put crosss-
server-priivate network traffic on a second mannagement intterface, this ssecond manaagement interrface
must be on
o a separatee subnet.
To createe a cross-servver private neetwork, the following

f reqquirements m
must be met:
• All
A hosts in th
he pool must be using XeenServer 5.6 F
Feature Packk 1 or greaterr
• All
A hosts in th
he pool must be using thee vSwitch forr networkingg
• The
T pool musst have a vSw
witch Controlller configureed
• The
T cross-servver private network
n mustt be created oon IP-enableed NICs (thatt is, a
management
m interface)
i
To create a cross-seerver privatee network ussing XenCen nter

1. Inn XenCenterr, select the pool
p where yo ou want to crreate the netw
twork in the R
Resources paane.
2. On
O the first page of the New
N Networrk wizard, sellect Cross-Seerver Private Network aand
cllick Next.
3. Enter
E a name and descripttion for the new
n networkk, and click N Next.
4. Do
D one or mo ore of the folllowing:
 To automatically add
a the new network
n to anny new virtuual machines created usingg the
New VM
V wizard, select
s the cheeck box.
 To usee jumbo fram mes, set the Maximum
M Trransmission U Unit (MTU) to a value
between 1500 to 9216.
9
5. Click
C Finish to
t create the new networkk.
Page 33
Scenarrio 4: Connecting VMs
V to Mu
ultiple Linkked VLAN
Ns
Many orgganizations to
oday configuure VLANs to o logically seeparate their pphysical netw
works for eith
her
performaance or securrity reasons. If
I your organ
nization has VVLANs, youu might want to connect yyour
VMs to one
o or more VLANsV on your
y networkk.
To conneect a VM to a VLAN, youu must createe a network ffor the VLAN N and then cconnect the V
VM
to that neetwork. To perform
p this configuration
c n, you create a separate exxternal netwo
ork for each
VLAN an nd then creatte a virtual in
nterface on th
he VM for eaach of these nnetworks.
This illustrration shows hoow VMs requiire a separate virtual

v interfacee for each netwoork to which yoou want to connnect
them, incluuding VLANs Ns. In this exam
mple, VM 2 coonnects to Netwwork 0 throughh Virtual Interf rface 2 and to
VLAN 58 5 through Virrtual Interface 3. As shown by VM1 and N NIC1, multiplle networks cann connect out thhrough
one NIC.
While truunk lines from

m the physicaal switch can
n contain mulltiple 802.1q VLANs, XeenServer does not
let you coombine multiiple VLANs in one XenSServer networrk. This meaans that to lett a VM connnect
to multip
ple VLANs yo ou must either (a) create a separate neetwork in XeenServer for each VLAN or
(b) createe a XenServerr network fo
or a VLAN th hat can accesss all of the ddesired VLAN
Ns.
Page 34
In the illuustration thatt follows, thee VMs conneect to a VLAN
N through a trunked switch port.
This illustrration shows hoow VMs on thhe host connect to an external network that tthe administrattor configured tto
connect to VLAN
V 485 and VLAN 234. 2 To achievve this, the adm ministrator creaated an externaal network thatt uses
NIC 5 to connect to a truunked switch port
p that includdes VLAN 4885 and a seconnd external netw work that also uses
NIC 5 to connect to VL LAN 234. The administratorr ran a cable frfrom the VLA AN trunk port to NIC 5.
Connecting a VM to a VLAN requuires that youu:
1. Create
C a physiical connection between the
t correspoonding NIC oon each host and the VLA
AN
trrunk port forr that VLAN on the switcch.
For
F example, if you conneect NIC 7 on n the XenServver pool masster to a VLA
AN trunk porrt on
th
he switch witth access to VLAN
V 485, you
y must runn a cable fromm NIC 7 on all other hossts in
th
he pool to a similarly
s configured VLAAN trunk porrt on the sam
me switch, whhich can acceess
VLAN
V 485.
Page 35
2. Enable
E XenSeerver to conn nect to a speccific VLAN oon the switchh by creatingg an external
network speciifying that VL
LAN tag.
This
T means crreating an extternal network on the XeenServer poool master andd specifying tthe
VLAN
V tag wh
hen you creatte the networrk.
Inn XenCenterr, select the pool

p (<your-poool-name>) inn the Resource pane, click the Netwo ork
taab, and click the Add Neetwork butto on. In the Neew Network w wizard, selecct External
Network.
N Onn the Locatioon page, speccify the NIC
C you physicaally connectedd to the switch
annd enter the VLAN tag forfo the VLAN N in the VLA AN box.
In
n the XenSerrver CLI, youu can use thee pool-vlan-ccreate xe commmand to crreate the VLA AN
on all hosts in
n a resource pool.
p For moore informatiion, see the X
XenServer Adm
ministrator’s G
Guide.
After
A you creaate the netwo
ork for the VLAN
V on thee pool masterr, XenServerr configures tthe
NICs
N on all th
he other hostts so that thee correspondiing NIC on eeach host
Note:
N The nuumbers of VL
LAN tags muust be betweeen 0 to 4094.
3. Connecting
C th
he appropriatte VMs to th
he VLAN by configuring a virtual inteerface that po
oints
to
o that networrk on each VM
V you want to be able too connect to the VLAN.
Inn XenCenterr, this is donee by selectingg the VM in tthe Resourcee pane, clickin
ng the Netw
work
taab, and clickiing Add Inteerface and th hen specifyinng the VLAN
N network wh hen you creatte the
in
nterface.
Again, beecause netwoorking is a po

ool-level featuure, if you coonnect one hhost to a VLA
AN, you musst
connect all
a hosts in th
he pool to the VLAN. Th his means thaat you must pphysically connnect the
corresponnding NIC on
o each host to the VLAN N port on thee switch.
In the illuustration thatt follows the VMs on muultiple hosts inn a pool connnect to a VL
LAN through
ha
trunked switch
s port.
Page 36
This illustrration shows hoow, because XeenServer autom
matically synchrronizes the netwwork settings inn pools so that they
match, NIIC 7 on all hossts in the pool will
w be configurered with the samme network andd VLAN setttings as NIC 7 on
the pool maaster. However,r, for the VMs on the memberr servers to be aable to connect to the VLAN N, the administtrator
must also physically
p conneect NIC 7 on each
e host to a trunk
t port on tthe switch thatt can access VLLAN 485.
Before co
onfiguring a VLAN,
V ensuure the switch
h on your VL
LAN networkk is configurred as followss:
 The port
p on the sw
witch conneccted to each XenServer hhost must be configured aas trunk portt.
 The port
p on the sw
witch must be
b configured
d for 802.1q encapsulatioon.
 Port security
s cann
not be set on the trunk po
ort.
 The port
p designatted as trunk should
s be asssigned a nativve VLAN; use 1 as defauult.
XenServeer lets you create multiplee networks an

nd VLAN neetworks on thhe same NIC C. XenServerr
does not limit the num
mber of VLA ANs you can connect to V
VMs. Insteadd, the limit co
omes from thhe
Page 37
802.1q standard is 40996. You add an external network
n for eeach VLAN to the host aand then con
nnect
the VMs to the VLAN Ns by specifyying that netw
work in the VVM’s virtual interface.
Note: If a Native VL
LAN is used on
o the switch
h trunk port, then you cannnot assign tthat VLAN
number to
t a VM on the
t XenServeer.
For an exxample of a tested

t workin
ng model of a VLAN connfiguration, ssee CTX1234489 -- XenSerrver
VLAN Networking.
N For more infoormation aboout configurinng VLANs oon your switcch and 802.1qq
support, see the documentation foor your switcches.
Tip: To verify
v that yo
ou have confi
figured the XenServer
X hosst to commuunicate acrosss the correct
network, you can use the packet sn
niffing softw
ware includedd with your N
NICs to captuure and displlay
the VLANN tags that are
a transmitteed across the switch to thhe XenServerr.
Note: Although the 802.1q

8 standaard limits thee number of V
VLANs XennServer supports, XenSerrver
does not limit the num
mber of XenServer netwo orks you can configure foor a NIC.
Understtanding the
he Impact of
o Numerou
us Networkks in a Poool
Having numerous
n connnections to VLANs (forr example, 1000s) configurred on a hostt creates an
additionaal load on thee Control Doomain, which
h frequently rresults in redduced networrk performannce as
describedd.
Having numerous
n VL
LANS can alsso impact youur host, pooll, and VMs pperformance in the follow
wing
ways:
 VM
V performaance may deggrade.
 VM
V network service
s may degrade.
d How
wever, this caan be due to many factorrs.
 Numerous
N VLLANs can slo
ow down cerrtain host (XeenAPI) operrations, such as adding an
nd
reemoving netw
works.
In additio
on, various management
m and
a administtration functiions can become slower w when there aare
numerous networks on o pools. Forr example, acctions like thee following m may take longger: joining a new
host to a pool, rebootting a host; reendering chaarts in the Peerformance taab in XenCennter.
Creating
g VLANs on
o Bonded
d Networks
XenServeer supports connecting

c to
o VLANs fro
om bonded N
NICs. To do so, do the fo
ollowing:
1. Bond
B the two NICs togeth C bond appeaars as a bonded
her. After you have done so, the NIC
network in XeenCenter.
2. In
n XenCenterr, for examplee, create an External
E Neetwork speciifying the folllowing:
a) The VLAN’s
V tag
b) The NIC
N bond as the NIC
Page 38
You mighht want to nam
me this exterrnal networkk the same naame as the VL
LAN (for
example, VLAN
V 25).
3. When
W you creeate the virtual interface for
f the VM, sspecify the exxternal netwo
ork with the
VLAN
V tag as the network.
Creating
g VLANs on
o the Prim
mary Manag
gement Int
nterface
You can have

h a singlee VLAN on thet primary management
m interface, annd this VLANN can be on an
access po
ort. If you waant to use a trrunk, either you
y define a default VLA AN on that trrunk and the
managem ment interfacee can use thaat or you makke the port a full access pport.
XenServeer does not support havin
ng a VLAN trunk
t port onn the primaryy managemen
nt interface.
Page 39
Chapter 4: Specify
S ing Nettworkin
ng Requ
uirements
This chap
pter providess information
n about the following:
f
 XenServer
X nettworking reqquirements an
nd support
 A suggested process
p for deefining your communicattion and harddware requireements
Overv
view
This chappter helps you map your existing
e netw
working requiirements ontto XenServerr features andd
includes principles
p to note while defining
d yourr XenServer nnetworking rrequirementss. It also provvides
informatiion about XeenServer netwworking requuirements andd supported configuratio
ons.
This chap pter includes tables that map

m common n requiremennts and confiiguration scennarios onto
XenServeer features annd indicate what
w topics to o read for moore informatiion. The topiics covered iin the
tables incclude guidancce about defiining basic reequirements aat the VM leevel and at th
he host level.
The tablees are structuured so that you

y begin youur evaluationn by considerring your exissting workloaads
(for exam
mple, in your physical envvironment) sinnce this will indicate yourr VM’s conn
nectivity
requiremeents. After determining
d your
y VM’s co
ommunicatioon requiremennts, define how you wantt to
group VMMs together and a the host’’s networkingg hardware.
The follo
owing illustration shows a suggested seequence or ““direction” inn which to co
onsider
networkinng requiremeents: from th
he physical en
nvironment ddown to the llayers of the virtual
environm
ment.
Page 40
This diagra
ram presents a possible
p way off defining netwoorking requiremments for a XennServer pool. It suggests that yyou
begin by ex
xamining your physical
p environment and thenn consider yourr networking reequirements by beginning at thhe
VM work kload level, definning networks required at thee host level, andd then defining yyour physical iinfrastructure
requiremennts, such as NIIC and switch configuration.
c
Introd
duction
n
The prim
mary factor th
hat drives youur networkingg requiremennts is the connnectivity neeeds of the po
ool’s
VMs and their worklooads. In some cases, you may
m choose to group VM Ms in pools aaccording to tthe
networkin
ng requiremeents of their workloads.
w This
T could eitther be due tto the:
 Workloads’
W neetworking haardware requuirements sincce all hosts inn a pool musst use the sam
me
networking haardware
Page 41
 Workloads’
W neetworking co
onfiguration since
s sometim mes you migght want to create pools b
based
on common networking
n reequirements so as to reduuce the amouunt of netwo
orking
co
onfiguration you must peerform
As a resuult, it helps to
o know the workloads
w youu want to virrtualize and thheir networkking requirem
ments
before yoou begin conffiguring netwworking. Likeewise, you shhould know tthe approxim mate the size of
your pool (that is, thee number of hosts).
h
Ideally, alll networkingg configuratio

on is perform
med before yyou put a poool into produuction. Howeever,
you do no ot need to co
onfigure all of
o the pools in your virtuaal environmeent when youu begin
configurin ng networkin ng. Rather, yo
ou can configure one poool at a time. AAlthough configuring
networkin ng before puutting a pool into producttion is a best practice, youu can add ho
osts and makee
networkin ng changes ata any time.
XenS
Server Network
N king Su
upport and Re
equirem
ments
This sectiion provides informationn about the physical and loogical netwoorking configgurations
XenServeer supports, such
s as the number
n of NICs or netwoorks supportted. It also prrovides
informatiion about whhere to find a list of suppo
orted networrking hardwaare.
When youu are defininng networkingg requiremen nts for a poo l, it is importtant to note tthat all pooleed
hosts sho
ould have thee same numb ber and modeel of NICs, saame XenServver networkss, and physical
cabling co
onfiguration.. Because XeenServer assuumes all netw
work settings in a pool maatch, it
automaticcally propagaates any chan
nges you makke to networkk settings onn one host to all other hossts in
the pool.
XenServer Supporteed Configuraations
XenServeer supports th
he followingg networking configuratioons:
 Up
U to 16 physsical networkk interfaces (o nterfaces) per
or up to 8 paairs of bondeed network in
XenServer
X host.
 Up
U to 7 virtuaal interfaces per
p VM.
 Active-active
A and active-paassive bondin
ng modes aree supported. DMP and R
RDAC MPP
multipath
m hanndlers are also
o supported.
 Four
F differentt types of nettworks: exterrnal, cross-seerver private,, single-serveer private, andd
VLANs.
V
o There is no Citrix--imposed preeset limit on tthe number oof VLANs.
 SR
R-IOV provvided the NIC C used meetss the supportt requiremennts in the Citrrix XenServer
Hardware
H Comppatibility List.
Page 42
XenServer Networking Hardwaare Requirem
ments
Citrix Tecchnical Supp

port only provvides supporrt for hardwaare, includingg NICs, on th he Citrix
XenServerr Hardware Coompatibility Liist. While it may
m be possibble to use diffferent hardw ware, it is nott
recommeended. If youu do not see youry hardwarre on the list,, you can usee the self-cerrtification kitss at
the Citrix
x XenServer Hardware
H Comppatibility List web
w page andd certify it yoourself by run nning the kitt and
submittinng your resultts.
Importan nt: Do not configure anyy networking settings untiil you have addded all the h hosts to the pool
and you finish
f physicaally connectin
ng each hostt to the approopriate switcch ports. Theen, proceed too
configuree your XenSeerver networkk settings by starting withh (and configguring only) tthe pool masster.
Defin
ning Your Netw
working
g Requiremen
nts
Defining network reqquirements fo or your XenSServer enviroonment is a mmulti-stage prrocess. Two
factors siggnificantly in
nfluence yourr network deesign and reqquirements:
1. Certain
C workloads may havve specific network
n connnectivity or pperformance rrequirementss.
2. While
W VMs in
n a pool can connect
c to diifferent netw
works, the nettwork configgurations andd
hardware on each
e host in a pool must match.
As a resuult, you mightt find it easieer to define your workloadds’ network rrequirementss before you
determinee in which seervers and po ools to host your
y VMs.
This sectiion provides guidance ab bout how to begin

b determ
mining the commmunication n requiremen
nts
for your workloads,
w how
h to evaluaate your existting networkking configurration, and ho
ow to review
w your
initial poo
ol design agaainst the netw
work requirem
ments of its w
workloads.
Consid
dering Workload Co
ommunica
ation Requ
uirementss
To determ mine a host’ss networkingg configuratio
on, start evaluuating requirrements at th
he lowest leveel
(that is, th
he VM/workkload) and th hen work youur way up to your organizzation’s physical network. The
networkin ng requiremeents for yourr workloads can
c ultimatelyy impact youur pool design n and which
workload ds you decidee to group toggether.
To conneect a VM to an
a external network,
n suchh as a VLAN N, you might determine th he VM’s
networkin
ng requiremeents by usingg a process likke the one inn the followinng illustration
n.
Page 43
This diagra
ram illustrates a general processs you might usse when defining
ng networking rrequirements att the workload level.
Determinne the worklo oad’s commuunication reqquirements (fo

for example, does a domaain controllerr
need acceess to a speciific VLAN orr a database server need aaccess to a sppecific storagge device?). T
To do
so, consid
der the factors listed in th
he following table:
Factor Action, Notes

N
Determin ne if the workkload has anyy Some wo orkloads mighht require specific NICs ddue to
specific performance
p requirements performaance requirem ments.
that mighht change its host’s
hardwaree design. An option n for optimizzing virtualizzed Provision
ning Servicess
servers is SR-IOV – ssee “Virtualizzing the Provvisioning Servvices
Server” on
o page 81.
See the XenServer

X Harrdware Compattibility List forr supported
NICs.
Consider the redundaancy For inforrmation abouut NIC bondding, see “Designing Netw
work
Page 44
N
requiremeents for the workload.

w Is Redundan
ncy” on pagee 56.
the worklload missionn critical?
For redunndancy, you can also lookk at solutionss by Citrix
partners, such as Marrathon, whichh provide muulti-CPU full-
compute failure fault tolerance.
Evaluating Your Current Network

N Configurat
C tion
When designing your XenServer network
n conffiguration, coonsider the foollowing aspects of your
current physical netwo
orking configguration:
Factor More infformation
Security and Isolatio

on
Consider your worklo oad’s VMs connnect to netw

works using vvirtual interfaaces as descriibed
communiication requirrements and in “Chapter 3: Samplee Networkingg Scenario.”
how you will connect its VM to
the devices and/or neetwork If your VM
V must connnect to a speecific VLAN that is part o of a
locations in your external trunk porrt, you must create a speccific external network
network. associated
d with the VL LAN. For mmore information, see
“Scenarioo 3: Isolatingg VM Traffic on a Privatee Network” o
on
page 32.
Does the workload neeed to be Configure either a:

isolated from
f other trraffic?
VLAN suubnet or a truunk port
or a
Cross-serrver private nnetwork as deescribed on p

page 32.
 Addittionally, you can use the D Distributed V

Virtual Switcch
contrroller to isolaate VMs by bblocking speccific machinees or
IP ad
ddresses from m communicaating with eaach other.
 Crosss-Server privvate network as describedd in “Scenario

o 3:
Page 45
Isolatting VM Trafffic on a Privvate Networkk” on page 30.
Will you need

n to perfo
orm live For poolss with VMs tthat use largee amounts off memory or pools
migration
n for this worrkload? that will have
h frequennt migrations, consider ussing the prim mary
managem ment physicall interface jusst for live miggration and
managem ment tasks. Inn this scenario, all VM, stoorage, and otther
traffic sho
ould be placeed on separaate physical innterfaces. Seee
“Segregatting VM Tra ffic from Maanagement an nd Storage
Traffic” on
o page 27.
Live migrration requirees shared stoorage.
Configurration
Does thiss workload reequire you See “Enaabling Promisscuous Modee for Traffic Monitoring”” on
enable prromiscuous mode?
m page 68.
Do you want
w XenServver to Citrix gen
nerally recom
mmends lettinng XenServerr automaticaally
automaticcally generatee MAC generate MAC
M addressses. See “Unnderstandingg Virtual MAC
C
addressess for the VM hosting this Addressinng” on page 26.
workloadd or do you want
w to assign n
the VM a static IP add dress?
Determ
mining Hos
st Networking Requ
uirementss
Does the workload neeed all of thee Set a quallity of servicee (QoS) restrriction on thee virtual interface
bandwidtth available or
o should it for the VM.
V See “Lim miting Bandw width Consum mption for H High
be deprio
oritized in favvor of other Demand Workloads” on page 66.
workloadds?
Storage Requiremen
R nts
Does the storage deviice require an

n This requuires configurring a (storagge) managem
ment interfacee so
IP addresss on the hosst? you can assign
a an IP aaddress to thhe NIC. For m
more informmation,
see “Segrregating VM Traffic from m Managemen nt and Storagge
Page 46
Traffic” on
o page 27 annd “Chapterr 6: Designingg Your Storaage
Network Configuratioon” on page 70.
Are you planning

p to use
u an iSCSI For a list of supportedd HBAs, see the Citrix X
XenServer Harddware
Host Buss Adapter (HBA)? Compatibiility List.
Would th
he storage traaffic benefit Currentlyy, jumbo fram
mes are only supported fo
or storage
from con
nfiguring jum
mbo frame networks with iSCSI H HBAs and thhe vSwitch co
onfigured as the
support? networkinng bridge. Thhis means:
1. If youu want to connfigure jumbbo frames forr your storagge

trafficc, you must uuse a storagee device that can use an H
HBA,
such as an iSCSI hhardware SA AN or a Fibree Channel SA AN.
2. You must
m configuure the vSwittch as the nettworking briddge.
You can
c choose tto configure tthe Distributted Virtual Sw witch
solutiion or just coonfigure the vvSwitch as th
he bridge. Seee
“Decciding to Use the Distribuuted Virtual SSwitch” on p page
53.
3. You must
m configuure end-to-ennd support fo or your jumbbo
framees, including switches andd NICs that aare compatib
ble
with them.
t For m
more informattion, see “Co
onfiguring
Netwworks with Juumbo Framess” on page 78.
Do you need
n to changge duplex See CTX117568 -- Ho
How to Modify N
Network Speedd and Duplexiing.
settings on
o the host?
Review
wing Initiall Pool Des
sign again
nst Netwo
orking Req
quirementts
After youu have determmined a possiible pool dessign for a grooup of workloads, consider if any of tthe
followingg will cause problems:
p

N
Will the network

n hard
dware If a subseet of workloaads require m
more expensivve NICs, succh as
requiremeents for these workloads ones thatt support jum
mbo frames oor 10 gigabit Ethernet, do o you
clash? Haardware in po
ools should want to purchase
p thatt networkingg hardware on
nly for the seervers
Page 47
N
match. hosting th
hose workloaads? If so, yoou should grooup these
workloadds in the samee pool(s). Seee “Impact off Pools on
XenServeer Networkinng” on page 15.
Cons
sidering
g Addre
essing Requirrements
s
This sectiion discussess IP addressin
ng consideraations.

N
How do you
y want to configure IP P Unless co
onfigured as a managemeent interface, only the prim mary
addressin
ng for the primary and managemment interfacee requires ann IP address: by default, alll
(storage) managementt interfaces? other NIC
Cs do not haave an IP adddresses.
You can assign static IP addressess to each NIC

C in the hostt
through XenCenter
X oor the xsconsole.
You speccify the IP adddress for thee primary maanagement

interface during XenSServer Setup.. You can speecify that
XenServeer uses eitherr static or dynnamic IP adddresses. How wever,
assigningg hosts static IP addressess is generally preferred. For
more info ormation, seee “Networkinng Configuraation after
Installatio
on” on page 14.
IP-based storage requuires configurring a (storagge) managem

ment
interface so you can aassign an IP aaddress to th
he NIC. For m
more
informatiion, see “Seggregating VMM Traffic fromm Managemeent
and Storaage Traffic” oon page 27 aand “Chapterr 6: Designing
Your Storage Networrk Configurattion” on pagge 70
For inforrmation abouut setting a sttatic IP addreess after Setuup, see

CTX1163372 -- How too Assign a Staatic IP Addresss to a XenServver
Host..
Page 48
Calcu
ulating the Number of
o Phys
sical NIC
Cs per Host
All XenServer hosts in n a pool shouuld have the same numbeer of NICs; hhowever, thiss requiremen
nt is
not strictlly enforced when
w a XenSServer host jo
oins a pool.
Having thhe same physsical networkking configurration for XeenServer hostts within a po
ool is importtant
because all
a hosts in a pool share a common sett of XenServver networks. The NICs o on each hostt
connect to
t pool-wide networks baased on devicce name. Forr example, alll XenServer hosts in a po ool
with an eth0 NIC willl have a correesponding NIC
N plugged iinto the pooll-wide Network 0 networrk.
The samee will be true for hosts wiith eth1 NIC
Cs and Netwoork 1, as welll as other NICs present inn at
least one XenServer host
h in the po ool.
If one XeenServer host has a differrent number of NICs thann other hostts in the pooll, issues can o occur
because not
n all pool networks
n willl be valid for all pool hostts. For exam
mple, if host1 and host2 arre in
the same pool and hoost1 has four NICs while host2 only hhas two, only the networkks connected to
NICs corrresponding to
t eth0 and eth1
e are valid
d on host2. V
VMs on host11 with virtuaal interfaces
connectedd to networkks correspond ding to eth2 and eth3 willl not be ablee to migrate tto host2.
The nummber of physiccal NICs youu want on eacch host (and,, consequenttly, the pool) depends on your
required resiliency
r andd connectivitty. For an exaample of a reeason you m
might want to use addition
nal
NICs to separate
s trafffic, see “Segrregating VM Traffic from
m Managemennt and Storagge Traffic” oon
page 27.
Although
h XenServer can
c be run with
w only onee NIC on thee host, Citrix recommends having at leeast
two NICs on the hostt: one for VM
M traffic and one for mannagement traaffic. Other eexamples of h
how
you could
d use NICs in
nclude:
 A best practicce is to bond the NICs for the primaryy managemennt interface aand the one ffor
VM
V traffic, wh hich means deploying
d at least
l four NIICs per host.. If you are uusing IP-baseed
sttorage, you might
m want siix NICs.
 You
Y may wan nt to provide additional baandwidth forr VM traffic by adding addditional NIC
Cs to
th
he host.
 Iff you are goin ng to have sh hared storagee, consider deedicating a pphysical netw
work for yourr
sttorage trafficc. In this casee, consider haaving at leastt one NIC orr HBA, or ideeally two in a
bonded or muultipathed configuration, dedicated to the storage traffic.
 Iff you are usin

ng Provisioniing Services to stream dissk images to VMs, you m may want to
dedicate a bon nd dedicated for the Provvisioning Servvices server oon the XenSServer host.
Consider the factors in

i the followiing table to help
h determinne the numbber of NICs yyou want in yyour
hosts:
Page 49
N
Do you want
w to optim mize your  The beest practice is to configurre two NICs or iSCSI HB
BAs
IP-based storage or provide for sto
orage traffic iin a bonded oor multipath
h setup.
redundan
ncy?
 For bo
onding, see:
o “Creating N
Network Ressiliency throuugh Bonds” o
on
page 23.
o “Consideriing NIC Bonnding” on pagge 56.
 For multipathing,
m ssee:
o CTX1213664 -- Multipatth Implementattions in XenSeerver.
o CTX1187991 -- Multipatthing Overview ffor XenServerr 5.0.

This articlee provides a ggood, albeit ssomewhat daated,
overview oof the UI-bassed multipath hing configurration
process.
For inforrmation abouut adding add ditional NICss to XenServver, see CTX1121615 -- Hoow to Add
Additionall Physical NIC
Cs to XenServeer.
For an exxample of hoow to calculatte the numbeer of NICs foor XenDeskttop-XenServver deploymeents,
see the 222 February 2011 Citrix bllog post, “XeenServer for XenDesktopp - How manny network cards
do I needd?”
Calcu
ulating Bandw
width Re
equirem
ments
Estimatin
ng how muchh network baandwidth youur virtualizedd environmennt will need is a key part o
of
ensuring good VM peerformance. Because
B all VMs
V on a hosst share the hhost’s bandw width, providiing
the host with
w enough bandwidth is critical. Facctors that afffect bandwiddth requiremeents include:
Factor Action
n, Notes
Number of VMs  Serrvers hostingg more VMs may require more bandwwidth, dependding
on
n the type of workload.
w Seee “Designinng Networks for Performaance”
on
n page 63.
Type of workload
w and
d  Some server rooles require m more bandwiddth. For exam mple, serverss
traffic sen
nding a lot off traffic to sttorage devicees or that havve a lot of baack up
Page 50
Factor Action
n, Notes
traaffic.
 Some operatingg systems havve a lower im

mpact on nettwork
perrformance. See
S “Designinng Networkss for Perform mance” on paage
63.
Workloadd-specific  In some cases, you might nneed to consttrain VMs to ensure sufficcient
bandwidtth requiremen
nts banndwidth. Forr example, yoou might wannt to configuure QoS policcies
on
n the NIC to specify a ratee limit. See ““Limiting Ban
ndwidth
Coonsumption for
f High Dem mand Workloads” on pagge 66.
Provision
ning Services  A key
k concern in a Provisiooning Servicees deploymen nt, especially for
largge XenDeskttop implemeentations, is tthe IOPS reqquired for serrvers
andd target devicces when thee VMs boot. See CTX1288645 -- Design gn
Considerations for Virtualizingg Provisioning SServices.
For inforrmation abouut testing Xen

nServer netw
work perform
mance, see “T
Testing XenServer Netwo
ork
Performaance” on pagge 65.
Page 51
Chaptter 5: Designin
ng XenS
Server Networrks
This chap
pter providess an overview
w of the decissions you neeed to make wwhen designiing your
XenServeer networkingg configuratiion and contaains informaation about thhe following::
 Deciding
D wheether or not to
t implementt Distributedd Virtual Swittching
 Designing
D youur XenServerr networkingg configuratioon for redunddancy
 Issolating traffi
fic
 Designing
D forr performancce
 Hardware
H and
d NIC specifi
fic configurattions
Overv
view
At a high
h level, most XenServer
X network desiggn decisions sstem from a combination n of three maajor
design go
oals: the need
d for redundaancy, perform
mance, or isoolation. For m
many organizzations, thesee
goals mayy overlap and
d are not neccessarily mutuually exclusivve.
While con nsidering theese goals, keeep in mind th

hat the physiccal network cconfiguration
ns you createe for
one host should matcch those on all a other hosts in the pooll. Consequenntly, it helps tto understandd
similaritiees between networking
n reequirements for
f different workloads bbefore you grroup workloaads
together ini hosts and,, ultimately, pools.
p
When designing your overall netw work configurration, you m must determinne your bondding and
managem ment-interfacee requiremen nts; internal, external,
e andd storage netw
working requuirements; an
nd
VLAN co onfiguration.. You must alsoa consider your IP addrressing and D DNS configuuration. In
addition, you should consider
c youur NIC hardw ware configurration and otther NIC setttings, such as
quality off service restrrictions.
Page 52
The sections that follo
ow consider these decisioon points as tthey relate too the three prrimary design
n
goals of redundancy,
r performance
p e, and isolatio
on.
Decid
ding to Use the Distrributed Virtual Switch
h
As of Xen nServer 6.0, the new Xen
nServer vSwittch componeent is the deffault networkking
configuraation. Howevver, you can still
s use the Linux
L bridge,, which was tthe default n
networking
configuraation prior to
o XenServer 6.0,
6 by runniing an XE coommand to cchange your n networking
configuraation.
Citrix reccommends th hat customers creating neew XenServerr pools use thhe XenServeer vSwitch
componeent for netwo d for future rreconfiguratiion. As of XenServer 6.0,
orking to prevvent the need
Citrix is discontinuing
d g active devellopment on the
t Linux brridge and mayy discontinuee support forr the
Linux briidge in futuree releases.
This illustrration shows hoow the vSwitch Controller cann display whichh VLANs aree used by whichh virtual machiines
and let youu display these VLANs from m one central usser interface.
Page 53
The Distrributed Virtuual Switch solution provid
des:
 Issolation through features such as Cross-Server Priivate Networrks.
 Quality
Q of Serrvice (QoS) policies.
p
 Juumbo frame support.
 Fine-grained
F security
s policcies. You cann create accesss control listts by using th
he vSwitch
Controller
C and
d restrict certtain types off traffic to speecific VMs.
 A central mannagement con nsole to man

nage finer graained featuress and monito
or traffic. Forr the
sw
witch port asssociated with
h each VM, you
y can see tthe packets trraversing thaat switch porrt.
 Visibility
V into XenServer networking
n th
hrough standdard tools annd protocols, such as RSP
PAN
an
nd NetFlow.
 Siimplified adm
ministration of
o virtualized
d networkingg environmennts.
How doees it work?
The Distrributed Virtuual Switch is a solution baased on the O

Open vSwitchh, an open-source projecct.
The Distrributed Virtuual Switch co
omprises two networking componentss:
 XenServer
X Open vSwitch h. The XenServer Open vvSwitch, or ““vSwitch,” iss the actual
networking co omponent ruunning on eacch XenServeer host. The X XenServer O Open vSwitch
h is a
viirtualization--aware switch
h. This switch
h is referred to as an Openn vSwitch.
 Distributed
D vSwitch
v Conntroller. Thee Distributedd vSwitch Conntroller is co
onsole on a
ceentralized serrver, which is distributed as an appliannce, that mannages and cooordinates th he
behavior of eaach individuaal Open vSwi witch to proviide the appeaarance of a siingle distribuuted
viirtual switch.. If you wantt to manage all
a the vSwitcches on your hosts centraally and have
th
hem function n as a single switch,
s you must
m downlo ad the Distriibuted vSwitcch Controlleer
ap
ppliance.
From a conceptual peerspective, th he vSwitch fuunctions the ssame way as the existing Linux bridgee.
Regardlesss of whetherr or not you use the Distrributed Virtuual Switch orr the Linux b bridge, you caan
still use th
he same netw
working featuures in XenC Center and thhe same xe neetworking co ommands listted in
place the existing
the XenSeerver Administtrator’s Guide. In the diagrams throughhout this guidde, if you rep
“networkk” icons, whicch represent the Linux brridge, with a vSwitch, thee concepts reemain the sam me.
Because networking
n is a pool-leveel feature, if you
y want to uuse the Distrributed Virtual Switch
solution, you must co
onfigure all hoosts in the poool to do so..
Configurring the Disstributed Virrtual Switch

h Solution
Citrix reccommends seetting up the networking configurationn you want ((vSwitch or L Linux bridge))
before yoou put your pool
p into pro oduction. Thee vSwitch is tthe default nnetworking co
onfiguration,, but
Page 54
the Distriibuted Virtuaal Switch soluution, which includes thee vSwitch Coontroller Virtuual Appliancce, is
not confiigured by deffault.
To ensure that XenSeervers can alw ways reach ann active vSwiitch Controlller, we recommmend the uuse of
Citrix Higgh Availabilitty for the vSw witch Contro
oller VM. Reefer to the XeenServer Adm ministrator's
Guide forr instructions on enablingg high availab bility. Becausse continuouus operation o
of the DVS
Controlleer is critical to
o the operatiion of networking for all virtual machhines, the vSw
witch Controoller
VM restaart-priority sh hould be set to
t 1 and ha-aalwaysrun sshould be sett to true.
Configuriing the Distrributed Virtual Switch sollution requirees that you ddownload thee vSwitch
Controlleer Virtual Appliance fromm My Citrix.com. The vSw witch Controoller Virtual A
Appliance lets
mplementatioon. For information abouut using the
you manaage your Disttributed Virttual Switch im
controllerr, see CTX1330423 - Citrix
x XenServer 6.0
6 vSwitch Co ntroller User GGuide.
Note: Th he Distributeed Virtual Sw

witch Controlller is availablle in Citrix X
XenServer Addvanced Edittion
or higherr.
Revertin
ng to the Lin
nux Network
king Config
guration
If you waant to revert to the legacyy Linux netwo

orking bridgee, run the folllowing command on eacch
host in th
he pool:
xe
e switch-n
network-bac
ckend brid
dge
Reboot th
he host after running thiss command.
Warnning: The Lin

nux networkk stack is not open flow ennabled and ddoes not suppport Cross Server
Private Networks, and cannot be managed d by the XenSServer vSwitcch Controlleer.
Impo ortant: Beforre switching networking configuration
c ns, shut downn all the VM
Ms on the hosst
first.
Considerrations:
 Iff you want to

o change the networking configurationn, you must run the xe-switch-netwo ork-
backend com mmand on each host in thhe pool separrately. The xee-switch-network-back kend
coommand is not
n a pool-wiide command d. This comm mand can also be used to
o revert to thee
default vSwitcch networkin
ng bridge by using
u this synntax: xe-swiitch-networrk-backend
op penvswitch.
 All
A hosts in thhe pool must use the same networkingg backend. D Do not configgure some ho
osts
n the pool to use the Linuux bridge and
in d others to u se the vSwitcch bridge.
 When
W you aree changing yo
our hosts to use
u a differennt network configuration n, you do nott need
to
o put the hossts into Main
ntenance mod de. You just nneed to run tthe xe-switcch-network--
backend com mmand on each host and reboot the hhosts.
Notee: After changging the netw

working conffiguration, chheck to makee sure that yo
our bonds aree still
enablled.
Page 55
Desig
gning Network
N k Redundancy
y
As pressuure on organiizations to en nsure networrk connectiviity and availaability for corrporate resouurces
increases,, it is becomiing importan nt to improvee network ressiliency by ennsuring redun ndancy at all
network infrastructur
i e levels. Citriix recommen
nds that you consider thee following neetwork failurre
points whhen considering redundan ncy:
1. Network
N card
d.
2. Network
N cable (for examp
ple, if it is disconnected orr damaged).
3. Sw
witch (for exxample, if thee power supp
ply fails). Youu also might need to takee switches offfline
fo
or planned ouutages, such as firmware upgrades.
N bonding to provide nnetwork reduundancy.

XenServeer provides suupport for NIC
Cons
sidering
g NIC Bonding
B g
As previo
ously discusseed in “Creatiing Network Resiliency thhrough Bondds,” XenServver lets you b
bond
any combbination of tw
wo NICs, inccluding the ones
o that perfform the folllowing functiions:
 Primary
P man
nagement in nterfaces. Yoou can bond a primary m management interface to
an
nother NIC so that the seecond NIC provides
p failoover for mannagement trafffic. Howeveer,
NIC
N bonding does not pro ovide load baalancing for mmanagementt traffic.
 NICs
N (non-m
managemen nt). You can bond
b NICs tthat XenServver is using so olely for VM
M
trraffic. Bondin
ng these NIC
Cs not only provides
p resilliency, but dooing so also b
balances the
trraffic from multiple
m VMs between thee NICs.
 Other
O manag gement inteerfaces. You can bond N ICs that youu have configgured as
management
m interfaces
i (fo
or example, for
f storage). H However, for most iSCSII software
in
nitiator storagge, Citrix reccommends co onfiguring m
multipathing innstead of NIIC bonding ssince
bonding manaagement inteerfaces only provides
p failoover without load balanciing.
Itt should be noted

n that cerrtain iSCSI sttorage arrayss, such as Deell EqualLogiic, require using
bonds.
When con nsidering whhether or nott to bond NICs, weigh yoour requiremeent for redun ndancy and looad
balancingg against the number of seeparate subn nets and VLA ANs each poool requires. A
Although youu can
configuree XenServer with
w sixteen physical NIC Cs per serverr bonding NIICs reduces tthe number oof
physical networks
n youu can connecct into a host by half. XennServer suppports a maxim
mum of eightt
bonds.
Page 56
ollows shows the differen
nces betweenn the three diifferent typess of interfacees
that you can
c bond.
This illustrration shows hoow, when configgured in Activee-active mode, tthe links that aare active in boonds vary accordding to
traffic type.. In the top piccture of a manag
agement network k, NIC 1 is aactive and NIC C 2 is passive. F For the VM trraffic,
both NICss in the bond are a active. For the
t storage traffffic, only NIC 3 is active andd NIC 4 is passsive.
Page 57
Selecting a Type
e of NIC Bonding
B
When youu configure XenServer
X to
o route VM traffic
t over bbonded NICss, by default, XenServer
balances the load betw
ween the twoo NICs. How wever, XenSeerver does noot require youu to configurre
NIC bonds with load balancing (aactive-active).. You can coonfigure eitheer:
 Active-active
A e bonding mode.
m XenSeerver sends nnetwork trafffic over both NICs in a lo
oad-
balanced
b man nner. Active-active bondin ng mode is ththe default boonding modee and withouut any
additional
a con
nfiguration itt is the one XenServer
X usses.
 Active-passiv
A ve bonding mode. XenSServer only seends traffic oover one NIC C in the bonded
pair. If that NIC
N loses connnectivity, thee traffic fails over to the N
NIC that is n
not being useed.
The best mode for yoour environm

ment varies acccording to yyour environm
ment’s goals,, budget, andd
switch peerformance. The
T sections for each mo ode discuss thhese considerrations.
Note: Cittrix strongly recommends bonding th he primary mmanagement innterface if th

he XenServerr
High Avaailability featuure is enabled
d as well as configuring
c m
multipathing or NIC bon nding for the
heartbeatt SR.
Unders
standing Active-Act
A tive NIC Bonding
B
When youu bond NICs used for guuest traffic in
n the default aactive-active mode, XenSServer sends
network traffic
t over both
b NICs in
n the bonded pair to ensuure that it doees not overlo
oad any one N
NIC
with trafffic.
XenServeer does this byb tracking thhe quantity of

o data sent frrom each VM M’s virtual in
nterfaces and
rebalancin ng the data streams everyy 10 seconds.. For examplle, if three virrtual interfacces (A, B, C) are
sending traffic to one bond and on ne virtual intterface (Virtuual Interface B) sends mo ore VM guestt
traffic thaan the other two, XenSerrver balances the load by sending trafffic from Virttual Interfacee B to
one NIC and sendingg traffic from m the other tw wo interfaces to the otherr NIC.
Importan nt: When creeating bonds, always wait until the bonnd is finishedd being creatted before
performinng any other tasks on thee pool. To deetermine if X
XenServer hass finished creeating the bo
ond,
check thee XenCenter logs.
The series of illustratiions that follo

ow show how
w XenServerr redistributees VM traffic according to
o
load every ten second ds.
Page 58
In this illuustration, VM 3 is sending thhe most data (330 megabytes peer second) acrosss the network,, so XenServerr sends
its traffic across
a NIC 2. VM 1 and VM V 2 have the lowest amounts ts of data, so X
XenServer sendss their traffic ovver
NIC 1.
The next illustration shows

s how XenServer
X reeevaluates thee load across the bonded pair after ten
n
seconds.
This illustrration shows hoow after ten secconds, XenServver reevaluates tthe amount of traffic the VM
Ms are sending. When
it discoverss that VM 2 iss now sending thet most traffic,, XenServer reedirects VM 2’s traffic to NIIC 2 and sendss VM
3’s traffic across
a NIC 1 instead.
i
XenServeer continues to evaluate trraffic every ten

t seconds, so it is possiible that the V
VM sending
traffic acrross NIC 2 in
n the illustrattions could change
c again at the twenty
ty second inteerval.
Traffic frrom a single virtual

v interfaace is never split
s betweenn two NICs.
Page 59
The load balancing alggorithm XennServer uses for
f active-acttive mode coonfigurationss is its own
proprietaary algorithm known as So
ource Level Balancing
B LB) NIC bonnding. SLB is based on th
(SL he
open-souurce Linux Ad daptive Load
d Balancing (ALB)
( mode..
Because SLB
S bondingg is an active--active modee configuratioon, XenServeer routes trafffic over bothh
NICs simmultaneously. XenServer does d not load
d balance maanagement annd IP-based storage traffiic.
For thesee traffic typess, configuringg NIC bondiing only provvides failoverr even when the bond is iin
active-acttive mode.
Note: XeenServer NIC

C bonding do
oes not requiire any switchh configuratiion.
Unders
standing Active-Pas
A ssive NIC
C Bonding
When XeenServer is ruunning NIC bonds
b in an active-passivve configuratition, XenServver routes traaffic
across onne NIC in thee bond only: this NIC is the
t only activve NIC. XennServer does not send traffic
over the other
o NIC in o that NIC iss passive, waitiing for XenSServer to rediirect traffic to it if
n the bond so
the activee NIC fails.
To configgure XenServver to route traffic

t on a bond
b in activee-passive moode, you can use XenCen nter
and select Active-passsive as the bond
b mode when
w you creeate the bondd. You can allso use the C
CLI to
set a paraameter on thee master bon
nd PIF (xe boond-create mmode=active-bbackup), as described in the
XenServerr Administrator’s Guide.
Note: oth
her-config:b
bond-mode=
=active-backuup is still suppported for bbackwards co
ompatibility.
When designing any network

n conffiguration, it is best to strrive for simpllicity by reduucing components
and featuures to the miinimum requuired to meett your busineess goals. Bassed on this prrinciple, consider
configurinng active-passsive NIC bo
onding in situuations such as the follow wing:
 When
W you aree connecting one NIC to a switch thatt does not woork well with
h active-activve
bonding.
For
F example, if the switch does not wo ork well withh active-activee bonding, yo
ou might seee
syymptoms likee packet loss, an incorrecct ARP table on the switch, the switch h would not
uppdate the AR
RP table corrrectly, and/orr the switch wwould have iincorrect settings on the ports
(yyou might co
onfigure aggreegation for thhe ports andd it would not work).
 When
W you do not need loaad balancing or when youu only intendd to send trafffic on one NNIC.
For
F example, if the redund dant path usees a cheaper ttechnology ((for example,, a lower-
performing sw witch or exterrnal up-link) and that resuults in sloweer performance, configuree
acctive-passive bonding insstead.
Notee: As of XenSServer 6.0, thhe vSwitch no ow supports active-passivve NIC bondding. If you aare
usingg the vSwitch as your netw working conffiguration, yoou can set thee bonding m
mode to activee-
passivve (also know
wn as active-baackup) using the XenCentter or the CLLI.
Page 60
Ensurin
ng Resilie
ence throu
ugh Redun
ndant Switches
When youu bond NICs, you can co onnect the lin
nks to either the same or separate swiitches, depennding
on your redundancy
r requirements
r . If you conn
nect one of thhe links to a second, reduundant switch
h
and a NICC or switch fails,
f traffic fails
f over to thet other linkk.
Adding a second switch helps in th

he followingg ways:
 When
W you bon nd NICs useed exclusivelyy for VM trafffic, traffic iss sent over bo
oth NICs. Iff you
co
onnect a linkk to a second
d switch and the t NIC or sswitch fails, tthe virtual maachines remaain
on the networrk since theirr traffic fails over
o to the oother NIC/sw witch.
 When
W you con nnect one off the links in a bonded priimary managgement interfface to a seco ond
sw
witch, it prevvents a singlee point of faillure for yourr pool. If the switch fails, the managem
ment
network still remains
r onlinne and the ho osts can still communicatte with each o other.
When youu attach bon nded NICs to

o two switchees, the switchhes must be rrunning in a stacked
configuratioon. (That is, the nfigured to fuunction as a ssingle switch that is seen as a
t switches must be con
single dom main – for exxample, when multiple raack-mountedd switches aree connected across the
backplanee.) Switches must m be in a stacked configuration beecause the M MAC addressees of VMs wiill be
changing between swiitches quite often
o while trraffic is reballanced across the two NIICs.
The switcches do not require

r any additional connfiguration. T
The illustratioon that follows shows ho
ow
the cabless and networrk configurattion for the bonded
b NICss have to maatch.
This illustrration shows hoow two NICs in

i a bonded paair use the samee network settinngs, as represennted by the netw
works
in each hosst. The NICs ini the bonds connnect to differennt switches for redundancy.
Page 61
Bondin
ng Manage
ement Interfaces and MAC A
Addressin
ng
Because bonds
b function as one loggical unit, bo
oth NICs, reggardless of wwhether the b
bond is activee-
active or active-passivve, only have one MAC ad ddress betweeen the two oof them. Thaat is, unless
otherwisee specified, th
he bonded paair uses the MAC
M addresss of the first NIC in the b
bond.
You can determine

d th
he first NIC in
i the bond as
a follows:
 In
n XenCenterr, the first NIIC in the bon
nd is the NIC
C assigned thhe lowest num
mber. For
exxample, for a bonded NIC named “Bond 2+3,” thhe first NIC in the bond is NIC 2.
 When
W creatingg a bond usinng the xe bonnd-create coommand, thee first PIF lissted in the piff-uuids
parameter is th
he first NIC in the bond..
When creeating a bondd, make sure that the IP address

a of thhe managemeent interface b before and aafter
creating the
t bond is th he same. Wh hen using DH HCP, make suure that the M MAC addresss of the
managem ment interfacee before creaating the bond (that is, thee address of one of the tw
wo NICs) is the
same as the MAC of thet bond afteer it is created.
From XenServer 6.0 onwards,

o if th
he MAC add dress is not sppecified (usinng the mac pparameter wh hen
bonding from
f the CLLI), the bond uses the MA AC address o f the primaryy managemen nt interface iif the
primary management
m interface is one
o of the interfaces in thhe bond. If aanother manaagement interrface
(non-prim
mary) is in the bond (and the the prim mary managem ment interfacce is not), thee bond uses tthe
MAC add dress and IP address from m that non-prrimary manaagement interrface. Otherw wise, if none of
the NICss in the bondd is a managem ment interfacce, the bond uses the MA AC address o of the first naamed
NIC.
Note: Affter a pool is up and runn

ning, Citrix reecommends uusing cautionn when bondding the prim
mary
managem
ment interfacee.
For moree information

n about the xe
x bond-creaate commandd, see the XeenServer Admiinistrator’s Guuide.
Best Prractices fo
or Bonded
d Interface
es
Citrix stro
ongly recomm mends configguring NIC bonding
b on tthe pool masster after youu join all mem
mber
servers to
o the pool an
nd before youu create VMss. While it is ttechnically ppossible to ch
hange NIC
bonding afterwards,
a itt can create issues.
i
Immportant: Do D not join a host that alrready has a b ond configurred on it to a pool withouut
fiirst deleting the
t bond.
Ideally, fo
or maximumm performancce, configure NIC bonds for VM trafffic and isolatee management
traffic on
n its own netw
work. Howevver, note the following:
Page 62
 Separrating managgement, storaage and VM traffic
t across different NIICs helps preevent conten
ntion
for neetwork resouurces between n the manageement, VM, and storage nnetworks. However, unleess
you bond
b interfacces, they do not
n provide redundancy.
r
 Usingg the same bo onded interfaace rather than two separrate NICs forr managemen nt and storagge
trafficc can decreasse performan
nce, as all trafffic will go thhrough the saame NIC.
 Alwayys create bon

nds before crreating virtuaal interfaces oon VMs.
Warnning: Do nott attempt to bond

b NICs while
w the Higgh Availabilitty feature is eenabled. Creaating
bonds can interruupt the in-pro
ogress High Availability
A hheartbeat andd cause hosts to self-fencee
(shut themselves down).
d Conssequently, thee hosts probaably will not reboot correectly and willl
need the host-em
mergency-haa-disable com mmand to reecover.
Cs in the bon
Both NIC nd must havee the same frame size (MT TU). You cann edit the fraame size in
XenCenteer when you create the bo
ond. For add
ditional inforrmation, see ““Configuringg Networks w with
Jumbo Frrames” on paage 78.
Network card failuress are rarely th

he reason nettwork connecctions fail. Sw
witch failuress, network
outages, and
a performaance issues on o one subneet are more ccommon. Connsider makin ng bonded
interfacess more reliab
ble by:
 Confi
figuring two different
d netw
work up linkks (subnets) ffor each NICC in the bondd. Not only iss this
a requuirement, it helps
h ensure a network coonnection if there are issuues (unrelateed to hardwarre or
switchhes) on one subnet.
 Connnecting NICss bonded for managemen

nt, storage, annd guest trafffic to differen
nt redundantt
switch
hes.
 In an active-passivve configurattion, Citrix reecommends connecting tthe passive N NICs in each

bond into one swiitch and the active NICs in each bondd into a sepaarate switch. IIf one of thee
switch
hes fails, youu still do not have a singlee point of faiilure becausee the failover NIC goes in
nto
anoth
her switch.
Where boonding requirrements varyy by workloadd type, consiider groupingg workloads with matchin ng
bonding requirements
r s and NIC co onfigurationss in the samee pool. Citrixx makes this ssuggestion
because XenServer
X auutomatically configures
c id
dentical netwworking configgurations acrross all hostss on
the pool.
Desig
gning Network
N ks for Perform
P mance
If perform
mance is a go
oal for your XenServer
X neetworking coonfiguration, consider youur I/O and
performaance requiremments.
The I/O requirementts of the workloads you are virtualizinng determine how you sho
ould configuure
the physical NICs in each
e server (and, by exten
nsion, each ppool).
Page 63
Analyzingg the traffic levels
l of the workloads
w may
m show, forr example, thhat traffic levvels let some
hosts shaare a common n external neetwork while other worklooads may reqquire access tto dedicated
NICs to support
s theirr requiremennts. To impro
ove throughpput, you can iimplement N NIC bondingg:
XenServeer uses Sourcce Load Balan ncing (SLB) to share loadd across bondded NICs.
It should be noted, hoowever, that bonding hass the potential to increase tthroughput o
only when VM M
traffic is not
n balanced
d between NIICs. If VM trraffic is alreaady balanced between sep parate NICs,
bonding will
w not increease throughput.
One of th he most impo ortant factorrs for network performannce is CPU uttilization. Th
he CPU utilizzation
of your workloads
w hass a significan
nt impact on network throoughput. As the CPU dem mands of
workload ds increase, th
he effective network
n perfformance maay degrade. T
The impact off CPU utilizaation
is discusssed throughoout this sectio
on.
Review thhe negative and

a beneficiaal impact secttions that folllow for ideass of ways youu can optimize
the performance of yoour XenServver network configuration
c n.
Negativee Impact
 Many
M VLAN Ns in a Pool. If you have a lot of VLA ANs starting one or moree hosts in a p
pool
will
w be slower. Likewise, jo
oining a hostt to a pool wiill be slower. However, h
having many
VLANs
V will not
n affect nettwork througghput.
 Load
L on NIC Cs. Some mo work cards require firmwaare upgrades from the ven
odels of netw ndor
to
o work reliabbly under loadd, or when ceertain optimiizations are tturned on. Iff you are seeing
coorrupted trafffic to VMs, you
y should first
f try to obbtain the latesst recommen nded firmwarre
frrom your venndor and app ply a BIOS up pdate. If thiss does not resolve your isssue, contact
Citrix
C Techniccal Support.
Potentiaally Beneficial
 NIC
N Bonding. By bondin ng two NICss together, yoou can increaase the total aamount of
th
hroughput avvailable by beetter balancin
ng the traffic. While bondding NICs do oes not affecct the
to
otal bandwidth available --
- the bandw width availablee is the samee as the comb
bined bandwwidth
of the two ind
dividual NICs – bonding can make beetter use of avvailable resources.
 Upgrading
U thhe NIC. Proovided infrasttructure that can supportt such interfaaces is in placce,
up
pgrading thee NIC (for exxample, from
m a 1 gigabit N
NIC to a 10 ggigabit NIC can improvee
performance)..
 Im
mplementin ng jumbo fraame supportt can improvve performannce for storagge traffic. Forr
more
m informaation about using
u jumbo frames
f with sstorage, see ““Chapter 6: D
Designing Yo
our
Sttorage Network Configurration” on paage 70.
Page 64
 Im
mplementin ng SR-IOV forf Provision ning Servicess server traffiic. As of Xen
nServer 5.6
Feature
F Pack 1, XenServerr supports SRR-IOV. For m more inform mation, see “VVirtualizing th
he
Provisioning
P Services
S Servver” on page 81.
Testing
g XenServ
ver Netwo
ork Performance
You can observe a ho
ost’s networkk performancce in several w
ways, includiing using the XenCenter
Performaance tab, Xeen command ds like xentop
p and xenmoon, and netw working testinng tools, such
h as
Iperf.
The XenC Center Perfo

ormance tab
b displays thee number of M Mbps each N
NIC sends an nd receives an
nd
the load on
o the Contrrol Domain, and
a the utilizzation for eacch CPU on tthe host. By cclicking
Configurre Graphs, you
y can also change the Data
D Source tto see netwoork send and receive errorrs.
Before yo
ou begin testiing the perfo
ormance of your
y XenServver network cconfiguration
n, you shouldd
understan
nd what perfformance youur hardware can
c theoreticcally support..
To test th
he performan
nce of your XenServer
X neetwork configguration on a specific XeenServer hostt:
1. Start by using a neetwork testin

ng tool (such as Iperf).
2. Exammine the throughput of yo our network, as your netwwork testing tool recordedd it.
Comp pare the recoorded throughput level wiith what youur hardware ccan theoreticaally support.
For example,
e if yo
ou know thatt your NIC supports 1 giggabit of throughput, thenn you should be
gettin
ng a number close to that as your netw work throughhput keepingg in mind it iss not possiblee to
achievve the limit since
s there is always somee overhead.
3. If youu are not gettting this leveel of throughp

put, do one oor more of thhe following to find out m
more
informmation:
 In XenCenter, select th
he host, and use the Perfformance tabb in XenCen
nter to check the
following::
Make suree that VMs do

d not have a CPU, memoory, or disk bbottleneck beecause this
prevents the
t VMs from f throughpput. The mosst common cause of reduced
m receiving full
throughpuut is high CP
PU utilization
n by guests.
 Run the xentop

x comm mand. The xeentop comm mand shows yyou how mucch CPU each h VM
uses, netw
work traffic to
o and from th
he VM, and disk traffic oon the Contro
ol Domain. F
For
more infoormation about this comm mand, enter x
xentop –h help at the command
prompt on n your host.
 Run the xenmon

x commmand. The xenmon
x commmand can hhelp identify which domaains
and VMs are creating the
t highest I/O or proceessing loads oon a host. Fo
or more
on about thiss command, enter xenmo
informatio on.py –he elp at the ccommand pro
ompt
on your host.
Page 65
What to do next?
1. Experiment with the number of processingg threads (vss. the availablle virtual CPU
Us) on the V
VMs.
2. Reconnsider your VM
V to host ratio.
r You maay need to reeduce the num mber of VM
Ms on a host, o
or
host a different mixture
m of wo
orkloads, to obtain
o the neetwork perforrmance you w
want.
3. Makee sure there are

a no other VMs
V sendingg or receivingg a lot of netw twork traffic. Consider
changging the homme servers VM Ms are assign ned to so theyy are balanceed across diffferent hosts
accorrding to theirr network utillization. Youu may also waant to considder configurin ng Workloadd
Balan
ncing to makee balancing recommenda
r tions or autoomatically baalance VMs aaccording to rreads
and writes.
w
4. Ensure VM trafficc is evenly diistributed acrross physical CPUs. For m more inform
mation, see
CTX127970 -- Diistributing Gueest Traffic Overr Physical CPU
Us in XenServver.
5. Load balance your network traaffic across NICs.

N Make ssure that no one NIC hass an excessivve
numb ber of VMs pointed
p to it and/or
a that these
t VMs arre not sendinng an excessiive amount o
of
trafficc.
6. Separrate the manaagement, storage, and VM

M traffic, as ddescribed in tthroughout tthis guide, to
o see
if thiss improves performance.
7. If youu have a mixed environmment, considerr putting a m

mixture of Linnux and Win ndows VMs o on
that host.
h When virtualized,
v th
he Linux opeerating system
m usually putts less stress o
on the Contrrol
Dom main and CPU U resources.
Citrix reccommends ruunning these tests on a piilot environm ment before ffinalizing youur hardware
requiremeents and oveerall design. These
T tests may
m indicate tthat you needd additional n network
connectio ons, to rearraange workloaad groupings,, to purchasee more NICss, purchase NNICs that sup pport
different configurations than you originally inttended (for exxample, jumbo frames orr SR-IOV) an nd so
on.
Limiting
g Bandwid
dth Consu
umption fo
or High Demand W
Workloads
In enviro
onments where the worklo oads send a lot
l of data annd can potenntially consum
me a lot of
network bandwidth,
b you
y might waant to limit thhe amount o f data these wworkloads caan send and slow
down thee transmission rate. This helps
h ensure other VMs oon the host rreceive adequuate networkk
transfer rates.
r
To limit data
d transfer speeds, you can specify a maximum ttransfer rate in kilobytes p per second ((or
p second in the CLI) wh
kilobits per hen you creatte the VM’s vvirtual interfa
face(s) or at a later time. W
When
you limit the transfer rate, you aree doing so forr all the data that VM sennds over the virtual interfface
ociated netwo
to its asso ork link. If th
hat VM uses multiple nettwork links aand you wantt to limit the
transfer rate
r for all off them, you must
m create a QoS limit inn each virtuall interface fo or each netwo ork
link.
Page 66
Setting lim
mits can be particularly
p useful when different
d orgaanizations ow
wn different V
VMs on the same
host sincee it helps enssure each VM
M gets a fair share
s of netw
work bandwiddth.
If you waant to limit data transmisssion on moree than one viirtual interfacce on a VM, you must
configuree each virtuall interface to have a QoS limit.
To configgure a QoS liimit for VM output, you have several options:
 n XenCenteer. Select the VM, click th

In he Network tab, and clickk either Add
d Interface o
or
Properties.
P
 In
n the vSwitcch Controlleer. For pools using the vSSwitch and thhe Distributeed Virtual
Sw
witching soluution, configgure the QoS setting in vSSwitch Contrroller.
 Using
U the viff-param-set xe comman nd. For exam
mple, to limit a virtual inteerface to a
maximum
m trannsfer rate of 100 kilobits per second ((kbps), use thhe commandd:
xe
e vif-para
am-set uuid
d=<vif_uui
id> qos_alg
gorithm_ty
ype=ratelim
mit
xe
e vif-para
am-set uuid
d=<vif_uui
id> qos_alg
gorithm_pa
arams:kbps=
=100
You do not
n need to create a QoS limit for all virtual
v interfaaces/VMs thhat use that n
network link. You
only need
d to set limitss on the VMss you want to
o constrain.
Examplee: Calculatin
ng Bandwid
dth Limits
You can determine

d baandwidth lim
mits using a fo
ormula like thhe followingg:
Max Raate Transfer per VIF = (NIC speed in kilobitss per second/num
mber of VIFs)**desired network
k utilization % ((e.g.,
70%)
An examp
ple of the ap
pplication of this
t formula is as followss:
You havee five VMs on a host with

h one virtual interface on each VM. T
The virtual intterfaces all use
the same 10 gigabit Ethernet
E NIC. You want tot limit bandwwidth consumption for aall five VMs aand
their virtuual interfacess.
Assumingg a desired network utilizzation of 70%%, you can thheoretically limmit each virttual interface
bandwidtth to 1,468,0006 kilobits peer second (orr 183,500 kiloobytes per seecond).
To obtain
n this numbeer, we used th
he following calculations::
1. A 10Gigabit NIC
N = 10,4885,760 kilobitts per secondd
2. 100,485,760/5 virtual interffaces = 2,0977,152 kilobitss per second (per virtual iinterface)
3. 2,,097,152 * 700% = 1,468,0006 kilobits per
p second m maximum trannsfer rate (peer virtual
in
nterface)
4. 1,,468,006 kilo
obits per secoond/8=183,5500 kilobytess per second. XenCenter rrequires you
en
nter the rate limit in kilob
bytes per seco
ond.
Page 67
After determining thee maximum transfer
t rate per
p virtual innterface, you can then inccrease or decrrease
this valuee on each VM
M according to
t its bandwiidth needs.
The best practice is no a the network utilization, but rather m

ot to guess at measure the aactual througghput
from the NIC and divvide it by the number of VMs V using thhat NIC. If, ffor example, you are
achievingg 8,074,035 kilobits
k per seecond divide that by the nnumber of V
VMs with a viirtual interfacce
configureed to use thatt NIC. For exxample, 8,0774,035/8 VM Ms = an averaage throughp
put of 1,009,2254
kilobits per
p second avvailable for eaach VM.
You mighht decide to limit

l some VMs
V to far lesss than this vvalue (for exaample, 800,0000 kilobits peer
second) and
a others to o more (for example, 1,2000,000 kilobitts per secondd) dependingg on the
bandwidtth requiremennts and busin
ness priority of the worklloads.
Howeverr, be careful not

n to exceed d the total am
mount of throoughput achiievable. If yo
ou do exceedd it,
the limitss you set mayy not be reach
hed.
In generaal, if you havee not measurred the throuughput, it is bbetter to set tthe maximum
m transfer ratte
slightly lo
ower than wh hat you expecct your NICss can realisticcally achieve.
Note: Th he virtual inteerface QoS rate limit settiing is differennt than the vvirtual disk Q
QoS disk prio ority
setting. The
T virtual disk QoS settin ng is a storagge configurattion that lets you assign p priorities to vvirtual
disks so that
t disks witth higher prio ority are acceessed faster tthan other disks. The XennServer
Administrrator’s Guide describes
d both
h of these seettings in morre depth.
Addittional Conside
C erations
This sectiion discussess an additional considerattion for yourr networking configuratio
on.
Enablin
ng Promis
scuous Mo
ode for Trraffic Mon
nitoring
XenServeer supports promiscuous
p mode, an Etthernet confiiguration for NICs in wh hich the NIC
receives all
a traffic on its
i link insteaad of only the frames adddressed to thaat NIC’s MA AC address.
Organizaations may usse promiscuo ous mode forr a variety of reasons, succh as requirem ments from
transpareent proxies orr specialized traffic monittoring, securi
rity, and troubbleshooting applications.
You can enable prom miscuous modde at both thee VM and XeenServer hosst (physical server) levels.. That
is, you caan configure promiscuous
p s mode for both the virtuual interfaces and physicall NICs.
When youu enable promiscuous mo ode on virtuaal interface oor physical N

NIC, the modde lets you seee all
the trafficc on a virtuall switch. Youu might wantt to enable prromiscuous m mode when yyou want to:
 Run
R software (for examplee, software fo or a switch) oor integrate aan appliance that requiress
viisibility into all
a traffic passsing across the
t physical N NIC to which it is connected. For
co
onfiguration instructions,, see CTX116493 -- How to Enable Proomiscuous Modde on a Physicaal
Network
N Card.
Page 68
 Seee all traffic going
g across the networkk (specificallyy, the virtual switch) betwween the NIC
C
(P
PIF) and a VM’s
V virtual in
nterface. Insttructions for implementinng this configguration app
pear
in
n CTX121729 -- How to Configure
C a Proomiscuous Virttual Machine iin XenServer.
If your go
oal is to see all
a traffic VM
Ms send acrosss a specific nnetwork acrooss a pool, yo
ou may need to
configuree promiscuouus mode on a virtual interrface on a VM M in every host in the poool.
When dettermining if you

y want to enable prom miscuous modde, consider tthe CPU load on the
XenServeer host. When n XenServerr runs in prommiscuous moode, the kernnel receives alll network traaffic
and the CPU
C utilizatio
on on the ho
ost increases. Because thiss can slow doown responsees to networrk
packets, this
t in turn can also increease network latency.
If you aree using the vSSwitch Contrroller introduuced in XenSServer 5.6 Feeature Pack 11, you can usee
RSPAN instead
i of promiscuous mode
m to displlay traffic. Thhe vSwitch C
Controller alsso includes
functionaality for mirro
oring.
Promisccuous Mod
de and Secu
urity
When pro omiscuous mode

m is confiigured on a virtual
v or phyysical switch pport, the virttual interfacee or
NIC conn nected to thiis switch portt receives all traffic that ttravels througgh the switchh and then paasses
it to the VM
V that “ow wns” the virtuual interface (or,
( in the caase of NICs, the Control Domain). Th his
means that if malwaree or another type of maliccious attack rreaches acrosss your netw work all VMs will
become infected simuultaneously.
Citrix reccommends thhat you limit your use of promiscuous

p s mode to trooubleshootin
ng and, possib
bly,
security monitoring.
m
Warningg: Do not enaable promiscuous mode without

w a goood reason sinnce the VM iin promiscuo
ous
mode can
n access the network
n trafffic for other VMs.
Page 69
Chapter
C r 6: Des
signing
g Your S
Storage
e Netwoork
Configuration
This sectiion is intendeed to highligght storage co

onsiderationss you should include whille designing yyour
XenServeer network co onfiguration.. It includes the
t followingg topics:
 The
T need to create
c a separrate storage network
n
 How
H to assign
n IP addressees to NICs
 How
H to impro
ove performaance for storage traffic
 Guidance
G abo
out choosing between NIC bonding annd multipathhing for storaage
An extensive discussio
on of storagee configuratio
ons is beyonnd the scope oof this docum
ment.
Overv
view
This chap
pter is design ou configuree your IP-bassed storage coonfiguration so that it has
ned to help yo
redundanncy and gets the
t best netwwork performmance with thhe lowest imppact on otheer network traaffic.
Specificallly, this chaptter explains how

h to createe a separate sstorage netwwork and wheen you wouldd
want to do
d so. It also explains the differences between
b the two failoverr choices for storage traffi
fic,
bonding anda iSCSI multipathing.
m It
I also providdes informatiion about asssigning IP adddresses to NNICs,
since thiss is a common requiremen nt for IP-bassed storage.
Other tecchniques disccussed in thiss chapter that improve peerformance innclude jumbo frames.
Page 70
Creatting a Separat
S te Stora
age Nettwork
Citrix reccommends deedicating onee or more NIICs as a sepaarate storage network for NFS and iSC CSI
storage immplementatio
ons. Many coonsider creatiing a separatee storage nettwork to be a best practicce.
By configguring additio
onal managemment interfaces, you
y can bothh assign an IP P address to a NIC and
isolate sto
orage and network trafficc, provided th he appropriatte physical coonfiguration is in place. T
The
term man nagement interface refers to any NIC assigned an IP address foor identificattion purposess.
(The primmary managemment interface, which is in ntroduced in “Networkinng Configurattion after
on” on page 14, is a typee of managem
Installatio ment interfacee.)
Tip: To figure
f out whhich NIC is the
t primary management
m interface, in XenCenter, click the
Networkk tab, in the Management
M t Interfaces section, checkk the Interfacces column ffor the word
“Primary.”
You can segregate traffic by configguring an add ditional mannagement inteerface(s) for storage and
configuree XenServer to
t access storage through h that interfacce. Then, phhysically isolaate the guest
network and
a configurre virtual macchines to onlly use that isoolated netwoork. Ideally, th he network
should bee bonded or use multipath hing, as desccribed in “Chhoosing to Ennable Multip pathing Support
or Bond NICs.”
N
The overall process fo

or creating a separate storrage networkk is as follow
ws:
1. Configguring physical network in

nfrastructure so that diffeerent traffic iis on differen
nt subnets.
3. Creatin
ng a managem
ment interfacce to use the new networkk.
3. Configguring redund
dancy, either multipathingg or bondingg.
In the illuustration thatt follows, an administrato

or created a N
NIC bond froom NICs 3 aand 4 and theen
configureed the bondeed pair as a management
m interface
i for storage.
Page 71
This illustrration shows hoow the bond maade from NIC Cs 3 and 4 is coonfigured as a mmanagement innterface. XenSeerver
sends its sttorage traffic ovver this NIC boond onto the sto
torage network and, ultimatelyly, the storage aarray. The explloded
diagram shhows how each NIC N in the boond connects to a different swittch.
Creating managementt interfaces leets you establish separate networks foor, for examp
ple, IP-based
traffic pro
ovided:
 You
Y do not co onfigure Xen nServer to use this networrk for any otther purpose (for example, by
pointing a virttual interfacee to this netw
work).
 The
T appropriaate physical network
n conffiguration is iin place.
For exam
mple, to dediccate a NIC too storage trafffic, the NIC , storage targget, switch, an
nd/or VLAN
N
must be configured
c (pphysically con
nnected) so that
t the targeet is only accessible over the assigned
NIC.
To ensure that the sto orage traffic is

i separated from
f the mannagement traaffic, the storrage networkk
must be on
o a differen nt subnet netw work. The suubnet for storrage must bee a separate IIP subnet thaat is
not “routtable” from the
t primary management
m interface. If the physical or logical co
onfiguration ddoes
not enforrce the trafficc separation, then XenSerrver may direect storage trraffic over th
he primary
managemment interfacee after a hostt reboot, due to the orderr in which XeenServer inittializes NICs..
In smaller environments, routing guest,

g managgement, and//or storage trraffic togetheer may not
matter. However,
H in laarger environ
nments or en
nvironments with strict seecurity policiies, you may want
to separatte your traffiic.
f IP-based storage, such as iSCSI so

In order for oftware initiaator and NFSS, to commun nicate with
XenServeer, the XenSeerver NICs must
m have IP addresses. T To specify ann IP address ffor a NIC orr
Page 72
bond, youu must createe a managem
ment interfacee or reuse thee IP address assigned to tthe primary
managemment interfacee.
In other words,
w you can
c assign a XenServer
X P address for your storagee array to con
IP nnect to by eeither:
 Configuring
C additional
a (no
on-primary) management
m t interfaces soo you can asssign IP addreesses
to
o NICs besid
des the primaary managem
ment interfacee for routing storage trafffic.
 Routing
R storagge traffic thrrough the primary manageement interfa
face -- since tthe primary
management
m interface
i has an IP address this will w
work.
Some envvironments, such

s as test labs
l or at verry small comppanies, may eexperience liittle impact fr
from
routing management
m and
a storage traffic
t on one interface. HHowever, in ggeneral, Citriix strongly
recommeends that youu do not routte storage traffic over the primary mannagement intterface.
If you waant to bond the t managem ment interfacee, create the m

managementt interface firrst and then b
bond
it. Ideallyy, the first NIIC in the bon
nd should be the one for that has the IP address assigned to it..
Howeverr, Citrix also recommends
r s configuringg the MAC adddress on thee bond if youu are using
DHCP, as a described in i “Bonding Managemen nt Interfaces aand MAC Adddressing” o on page 62.
Importan nt: The prim

mary managem ment interfacce and other m managementt interfaces mmust be on
different subnets. Thiis is especiallyy critical wheen you are ussing the otheer managemeent interfacess for
storage trraffic.
Assigning IP Add
dresses to
o NICs (M
Manageme
ent Interfa
aces)
You can configure ad
dditional man
nagement inteerfaces in XeenCenter andd using the xee commandss. To
do so in XenCenter:
X
1. Ensure that the NIC

N is on a seeparate subneet, or routingg is configureed to suit youur network
topollogy in order to force the desired trafffic over the sselected NIC
C.
2. In thee XenCenter resource pan

ne, select thee host that is the pool maaster, click th
he Network ttab.
Page 73
3. The Managemen
M nt Interfacess feature is fo
ound on thiss tab. Instructions for connfiguring
manaagement interrfaces varies by XenCenteer release. Seee the XenCennter Help for more
inform
mation.
Tip: If yoou want to dedicate a NIC C for storagee, check XennCenter to maake sure thatt the NIC’s
associatedd network is not configurred so that it is added to tthe VMs by default. To ddo so, in the
Network ks tab, right-cclick <your--storage-nettwork> > Prroperties. Cllick Network k Settings annd
make sure the Autom matically add d this netwo ork to new vvirtual mach hines check b box is not
selected.
Page 74
Configuring
g Redun
ndancy
y for Sto
orage T
Traffic
For envirronments thaat want redun ndancy for thheir network storage trafffic, XenServeer supports NNIC
bonding and
a multipatthing, includiing iSCSI HB BA multipathhing and softtware iSCSI m multipathing. The
term multtipathing referrs to routing storage traffi
fic to a storagge device oveer multiple paaths for
ncy (failover) and increaseed throughpuut.
redundan
This sectiion provides information

n about when
n to choose N
NIC bondingg instead of m
multipathing and
how to coonfigure iSCSI multipathiing.
Bonding NICs or con nfiguring mulltipathing hellps provide rredundancy iin case of parrtial networkk
failure. Redundancy
R helps
h preventt interruption
ns to disk reaads and writees. Interruptin
ng disk readss and
writes cann lead to gueest operating system failurre if the VM consequentlly disconnectts from the
remote diisk.
Citrix stro
ongly recomm mends that you
y do not mixm NIC bondding and iSC CSI multipath hing. There iss no
benefit frrom layering multipathingg and NIC boonding on thhe same connnection. Afteer you enablee
multipathhing, you nott only have better perform
mance but yoou also have tthe failover tthat bondingg
would haave provided..
Note: XeenServer supports multipathing for Fiibre Channell and iSCSI SSANs. Howeever, multipatthing
for Fibre Channel SA ANs is not disscussed in deepth in this gu
guide since traaffic for Fibrre Channel ggoes
across a Fibre
F Channeel network annd not a TCP P/IP networrk. For inform mation aboutt Fibre Chan nnel
multipathhing, see the XenServer
X Addministrator’s Guide
G and thee Citrix Know wledge Centeer.
Choosiing to Ena
able Multip
pathing Support orr Bond NIC
Cs
Citrix reccommends co
onfiguring multipathing
m in
nstead of NIIC bonding w
whenever possible.
Like NICC bonding, multipathing

m provides
p failo
over for storaage traffic. H
However, unliike NIC bon nding,
XenServeer can send trraffic down bothb paths when
w you connfigure multippathing: mulltipathing is aan
active-acttive configuration. By deffault, multipaathing uses roound-robin m mode load baalancing, so b
both
routes wiill have activee traffic on th
hem during normal
n operaation, which results in inccreased
throughpput. The illusttration that follows
f proviides a visual gguide to the differences.
Page 75
This illustrration shows hoow, for storage traffic, both paaths are active wwith multipathhing whereas onnly one path is aactive
with NIC bonding.
Citrix reccommends ussing multipatthing when you y have blocck-based throoughput (forr example, iSCSI
software initiator trafffic). The exceeption to this is if, when the storage aarray is connected to
XenServeer, it does noot work with multipathingg.
Page 76
Consider using NIC bonding
b insteead of multip
pathing whenn:
• You
Y have an NFS
N storage device.
• Your
Y storage device
d does not
n support iSCSI
i conneections over m
multiple IPs (for examplee,
Dell
D EqualLoggic or HP LeeftHand SAN N).
The follo
owing table sh
hows the sup
pported proto
ocols for muultipathing annd NIC bondding:
Multipathin
ng N
NIC Bonding
g
Supported Storage Prrotocols Fibre Channnel, iSCSI HB BA, N

NFS, CIFS, iSCSI softwaree
iSCSI softw
ware Initiator Innitiator
Tip: To determine
d whhat XenServeer hosts havee multipathinng enabled onn them, checck Multipath
hing
in the Geeneral tab in XenCenter.
For inforrmation abouut configuringg iSCSI multtipathing, seee CTX1293099 -- Configurinng iSCSI
Multipathiing Support forr XenServer.
Sugggestions
s for Im
mprovin
ng Stora
age Ne
etwork
Perfo
ormance
This sectiion provides guidance forr improving storage netw
work perform
mance for iSC
CSI storage an
nd
jumbo fraames.
Other meethods of imp proving storage network performancee were discusssed in this cchapter. Thesse
include crreating a separate physicaal network fo
or storage traaffic, and wheen possible, cchoosing
multipath
hing for reduundancy sincee it both links are active, wwhich improoves throughp put over NIC
C
bonding.
iSCSI Storage
S
Provided iSCSI storagge is configurred correctlyy it can providde performannce comparaable to Fibre
Channel.
iSCSI SA ANs consumees more CPU U cycles on thhe host than NFS and Fibbre Channel do. Because CPU
utilization
n can affect network
n perfformance, thiis should be considered wwhen sizing hhardware andd
designingg pools. How wever, it shouuld also be no
oted that usinng an iSCSI hhost bus adap
ptor (HBA) can
offload thhe processingg for higher performance
p e.
Citrix reccommends ussing high perrformance neetwork switchhes for iSCSI SANs to acchieve betterr
iSCSI perrformance. Citrix
C also reccommends ussing redundaant iSCSI nettwork connecctivity for alll
implemen ntations.
Page 77
It is particularly important to sepaarate iSCSI sttorage traffic from managgement and V
VM guest traaffic
since it caan interfere with
w non-storrage traffic.
Configu
uring Netw
works with
h Jumbo Frames
F
Configuriing XenServeer networks to use jumbo o frames can improve perrformance foor storage traaffic.
Jumbo frames are Eth hernet frames containing more than 11500 bytes off payload. Jum
mbo frames are
typically used
u to achieeve better thrroughput, red
ducing the looad on system
m bus memoory, and reduccing
the CPU overhead.
mes if the vSSwitch is usedd as the netw

Currentlyy, XenServer only supporrts jumbo fram working bridgge on
all hosts in
i the pool.
When dettermining wh
hether your network
n perfformance willl benefit from
m jumbo frames, consideer the
followingg:
 Juumbo framess can help offfload CPU overhead.

o
o By inccreasing the Ethernet

E fram
me size to 90000 bytes, jummbo frames rreduce the
number of packet headers the CPUC must pprocess, whichh consequen
ntly decreasess the
deman nds on the CPU. Jumbo frames
f also rreduce the nuumber of NIC interrupts
needed d when transsmitting multti-packet file transfers.
o Jumboo frames mayy help with sllower CPUs if your NICss do not havve a TCP Offfload
Engin
ne (TOE) sup pport. Jumbo o frames are lless apt to reeduce CPU ooverhead with h
more intelligent
i giggabit NIC caards since theese cards cann process mo
ore of the paccket
headerrs on their ow
wn.
 Different
D typees of workloaads may havee their own ooptimum paccket sizes.
o For exxample, for storage

s trafficc, in general, throughput is more impo ortant than
latencyy. As a resultt, if you conffigure larger ppackets for sstorage trafficc (through juumbo
frames), the storagge traffic mayy not be negaatively affecteed by latencyy and may beenefit
from the
t increased d throughputt.
o For transactions th hat require hiigh responsee times, enablling jumbo fr frames may n not be
helpfuul. Jumbo fraames may reqquire more buuffering in thhe network, aand, as a resuult,
the lattency for a paarticular item
m of data migght be higherr. (Larger pacckets take lonnger
to asseemble and more
m bandwid dth per packeet.) As a resuult, if you neeed high respo
onse
times, bigger packeets are not ass good as smmaller packetss.
Generrally, if the sp
peed of the network
n and the need for high througghput increases, it
is prob
bably be goo od to increasee the size of tthe packets.
 When
W the trannsfer size is, on
o average, relatively
r smaall, the beneffits from jum
mbo frames m
might
not be significcant.
Page 78
 The
T performaance gains fro om jumbo fraames vary acccording to thhe type of prrotocol and tthe
tyype of traffic. When VM M traffic is on the same neetwork as storage traffic, iif the VM traaffic
iss latency senssitive, for exaample Voice--Over-IP trafffic, configurring Quality oof Service
priorities in sw
witches and on o virtual intterfaces may be necessaryy to ensure th
he performan nce
of the voice trraffic.
 Traffic
T that haas relatively large
l block siizes at the appplication layyer may beneefit from jum
mbo
frrames since large block siizes make it easier
e for thee TCP/IP staack to use larrge frames.
You can enable jumbo

o frame supp
port on eitheer of the folloowing types oof XenServerr networks:
 External
E netw
works.
 Private
P netwo
orks. For exam
mple, you co
ould enable juumbo frame support on a cross-serveer
private network.
Howeverr, the equipm ment (NICs, switches)

s betw ween all linkks must suppoort jumbo frames. Certain
n
types of traffic,
t such as
a IP-based storage
s trafficc, may beneffit from jumbbo frame suppport. You caan
configuree XenServer tot use frames of between n 1500 to 92116 Mbps.
When youu create the network

n in which
w XenSerrver will trannsmit data in jumbo frames, you mustt
specify th
he Maximum m Transmissioon Unit (MTUU) value the network suppports. In XeenCenter, youu do
so when you
y create thhe network in
n the New Network
N wizzard by enteriing the valuee your entire
network supports
s in the
t MTU texxt box.
Citrix stro
ongly recommmends speciffying jumbo frames whenn you create the managem
ment interfacce for
the storagge network.
To implement jumbo frame suppo ort for bondeed networks,, you specify the MTU fo or both NICss in
the bond when you crreate the bon
nd. In XenCeenter, there iss an MTU teext box in th
he Create Bo
ond
ox and in the New Netwo
dialog bo ork wizard.
Requirem
ments for Using
U Jumbo
o Frames
 All
A NICs transmitting jum
mbo-frame traaffic must suupport the traansmission uunit speed youu
want
w to configgure and be on
o the XenSeerver Hardwarere Compatibility
ty List.
 The
T network segment wheere you want to transmit the jumbo frrames must h have equipmeent
(ffor example, the NICs an
nd switches) that
t supportss the frames in all segmen
nts, from endd-to-
ennd.
 When
W creatingg virtual interrfaces and co
onfiguring N
NICs (PIFs), yyou must con
nfigure all
in
nterfaces on the
t network where you want w to suppoort jumbo fraames with th he same number
of MTUs.
Citrix also
o recommen
nds ensuring all
a componen
nts on the daata path are ttested for intteroperabilityy.
Page 79
To achievve optimum performancee, Citrix recommends thaat networks ccarrying jumb bo frames usee
equipmen nt with the saame transmisssion speed (for
( example,, 1 Gigabit). T This is to pro
omote the
hernet from standardizatiion. While 100/100 Mbps networks may
efficiencyy gains you acchieve in Eth
support juumbo frames, for optimuum performaance Citrix suuggests usingg a minimum m of 1 Gigabitt
Ethernet equipment. Ideally,
I netw
works should not use a miixture of 10//100 Mbps eqquipment an nd 1
Gigabit Ethernet
E equiipment due tot interoperability issues.
Addition
nal Informattion
If you change MTU on o the network in XenCen nter, it will aautomatically change the M
MTU on thee
virtual intterfaces and all the virtuaal interfaces and
a NICs/neetworks (swittches) that po oint to the
network supporting
s juumbo framess on all hostss.
Page 80
Chapter 7: Consid
dering Networ
N rk Perfo
ormancce for P
PVS
–XXenServver Dep
ployments
This chap
pter providess techniques for ensuring network perrformance w
when using XeenServer to h
host
Provision
ning Services VMs. It inclludes the folllowing topicss:
 Network
N perfformance guidance when streaming Prrovisioning SServices disk images to
XenServer
X VMMs
 In
nformation about
a disablin
ng the Spann
ning Tree prootocol
This chappter assumes that you aree familiar with h how Provissioning Serviices basic wo orks and its
componeents. For an introduction
i to Provision
ning Services,, see the Provvisioning Servicces Installation and
Configurattion Guide for your Provisiioning Servicces version.
Virtua
alizing the Pro
ovision
ning Serrvices S
Server
Before deeciding wheth her or not to
o host the Pro
ovisioning Seervices serveer on a VM, iit is importannt to
understan
nd the bottlenecks and co onstraints of Provisioningg Services serrvers, includiing how
Provision
ning Services servers use system
s cachee. It is also im
mportant to uunderstand thhat one of th
he
primary resource
r botttlenecks of Provisioning
P Services
S servvers is networrk I/O.
Recomm
mendations
1. Citrixx suggests thaat you host Provisioning

P Services servvers on XenSServer VMs tthat use Singlgle
Root I/O Virtualiization (SR-IIOV). SR-IO OV lets a singgle PCIe deviice to appear as multiple
separate physical PCIe
P devicess. To use SR IOV, the NIIC on the hoost must supp port SR-IOV V.
When n configured,, each VM beehaves as tho ough it is usinng the NIC ddirectly, whicch reduces
proceessing overheead.
Page 81
Witho out configuriing SR-IOV, it may be diifficult to achhieve throughhput for Provvisioning Serrvices
trafficc over 2 gigabit speeds.
A Pro
ovisioning Seervices host could
c under-perform andd result in a ddegraded userr experience
when
n there are higgh numbers of simultaneous VM starrtups.
To ennsure solid neetwork perfo

ormance, it iss critical to caarefully conssider the writte cache
configguration. In user workloaad scenario th
here are too many users w working simuultaneously,
writin
ng to and reaading from th
he Provisioniing Services w write cache.
Confi
figuring SR-IOOV can mitiggate this issuue. For configguration infoormation, seee CTX1266244 --
XenSeerver SR-IOV
V Support for Provisioning
P Services Virtual Machines.
Notee: SR-IOV is only supported on XenSServer VMs thhat are runniing Windowss Server 20088 as
the guuest operatin
ng system.
2. Ensure you are ruunning at leasst XenServerr 5.6 Feature Pack 1. Thiss is to give m
more the Conttrol
Dommain more CP PU resources. As of XenSServer 5.6 Feature Pack 1, the Controll Domain can n
explo
oit multi-corees and is capaable of using up to four ccores.
3. Consiider increasinng the amoun nt of memorry allocated too the Controol Domains oon the hosts
runniing the Proviisioning Servvices VMs. Yo ou can increaase the mem
mory allocatedd to the Conttrol
Dommain from thee default alloccation of 7522MB by folloowing CTX1226531 -- Conffiguring Dom00
Memoory in XenServver 5.6.
4. If youu want to virtualize Proviisioning Servvices servers, consider redducing the tarrget device too
Proviisioning Servvices server raatio so that th
he target devvices do not eexceed 300 ttargets. Whilee
virtuaalized Provisiioning Servicces servers caan support m
more hosts thhan this, reduucing this ratiio
can im
mprove perfo ormance.
See the Citrix

C Consultting white paaper, CTX128645 -- Desiggn Consideratioons for Virtuallizing Citrix
Provisioninng Services.
Note: It is
i not possibble to perform
m live migrattion of Provi sioning Serviices server V
VMs with SR--IOV
configureed. This is beecause the SR
R-IOV NIC’ss virtual funcction (VF) is directly tied to a specific
virtual maachine. (In XenServer,
X VFs are configgured througgh the XenSeerver CLI wh hereas the VMM
template contains the configuratio ons for the viirtual interfacce functions and bridges in the Contrrol
Domain.)) For High Availability
A deesign, you can
n use the Proovisioning Seervices High Availability
functionaality instead of
o assuming live
l migration n.
Addition
nal Provisiioning Servvices Netw
working Connsideration
ns
This sectiion discuses some high-leevel IP addreessing requireements and iinformation aabout isolatin ng
the streamming service. There are addditional con nsiderations cconcerning thhe TCP Largge Send Offlo oad
option. For
F more info ormation abo
out all of thesse topics, seee CTX1173744 -- Best Practtices for Configguring
Provisioninng Server on a Network.
N
Page 82
IP Ad
ddressing Req
quireme
ents
The Provvisioning Servver and Provvisioning Servvices Target devices requuire at least tw
wo NICs with
h IP
addressess on differentt networks:
 One
O network provides inteer communiccation betweeen devices sppecifically fo
or the streamiing
I/
/O traffic.
 The
T other nettwork provid
des access to network
n resoources, the innternet, and sso on.
Isolatting the
e Provis
sioning
g Servic
ces Strreaming
g Servic
ce
Provision
ning Services segment thee stream trafffic wheneverr applicable fo
for several reaasons:
performaance, provisio
oning growth
h and troubleeshooting aree a few.
When theere are bottleenecks in netw

twork capacitty or along thhe backplanee of switches,, UDP trafficc
tends to be
b the first to
o get dropped or discardeed. As a resul
ult, Citrix encourages segmmentation. W When
segmenteed, the stream
ming service does
d not havve to compette for bandwiidth, which eensures
performaance for the provisioned
p infrastructure
i e. Segmentattion can virtuually eliminatte retries and
maximizee Provisioninng Services Target/Server
T r performancce.
Disab
bling th
he Span
nning Tree
T Pro
otocol
When depploying XenSServer with Provisioning
P Services, as a best practicce, disable th
he Spanning T
Tree
Protocol on the switch (that is, sett FastPort=O
On).
Citrix maakes this reco

ommendation n because PX XE takes initiialize quicklyy and, conseqquently, meanns
that it is best
b if the swwitch initializees as rapidly as possible tto prevent thhe PXE envirronment from m
timing ouut. For similaar reasons, Ciitrix recomm mends disablinng the Spannning Tree pro otocol, since it is
slow to in nitialize.
It is not necessary
n to hard
h code th
he default autto negotiationn setting unleess you noticce long bootiing
times and d PXE timeo outs.
Best Practic
ce Conffigurations
Consider the followin
ng best practiice guideliness when confiiguring XenSServer –Proviisioning Servvices
deploymeents:
1. Follow the guideliines in CTX1117374 -- Besst Practices forr Configuring P

Provisioning Serrver on a Netw
work.
2. Revieew the inform

mation aboutt calculating IOPS
I for Proovisioning Seervices serverrs in CTX1225126
-- Addvanced Memory
ry and Storage Considerationss for Provisioniing Services. N
Note: The guiidance aboutt
CIFS no longer appplies if you are running Windows
W Seerver 2008 R22.
Page 83
3. If youu want to dep ploy Provisiooning Servicees on blades, review the C
Citrix Comm
munity Blog P
Post,
“Opttimizing PVS.” This articlle describes howh to confinne most Provvisioning Serrvices network
trafficc in the bladee chassis so as
a to enable high-perform
h mance networrk connectio
ons between tthe
bladees.
Page 84
Chaptter 8: Verifyin
V g Yourr XenSe
erver Ne
etworking
Configuration
This chap
pter providess some basic steps for verrifying that yyou configureed and physiccally connectted
XenServeer networkingg correctly. This
T chapter includes:
 Stteps for checcking your co

onfiguration
 An
A overview of
o steps you can take to resolve
r issuess
Verify
ying Xe
enServe
er Netw
working
g on a P
Pool
This chappter providess you with waays to verify your networrking configuuration before you create VMs
and deplooy the pool. Checking
C to see if your networking
n is configured pproperly befo
fore you procceed
with furth
her configuraation can red
duce troublesshooting and reconfigurattion later.
Create a resource
r poo
ol and run thee tests in thiss chapter from
m any host iin the pool. T
The tests in tthe
first topicc, “Verifying your Physicaal Configurattion,” verify your physicaal configuratiion, includingg if
your NIC Cs are fully fuunctioning. The
T tests in th he other maj or topic, “Veerifying yourr XenServer
Networkiing Settings anda Configurration,” veriffy whether yoour XenServver networkin ng settings arre
configureed correctly.
Verifyin
ng your Physical Co
onfiguratio
on
This sectiion provides procedures to help you verify
v NIC connectivity aand NIC speed. For testin
ng
purposes only, create the followin
ng:
 A Windows VM
V and a Lin
nux VM with
h XenServer T
Tools installeed on them.
 An
A external network.
Page 85
 An
A external bonded netwo
ork.
 A XenServer single-serverr private netw

work. Add twwo or more V VMs (with XeenServer Too ols
in
nstalled on th
hem) to that network.
n Yoou will need tto manually cconfigure IPP addresses fo
or
th
hese VMs un nless a machin
ne running DHCP
D was addded to the pprivate intern
nal network.
Issues with NIC conn nectivity and NIC speed can c indicate hhardware thaat is not com mpatible with the
XenServerr Hardware Coompatibility Liist. They can also indicatee issues with tthe NIC drivver.
Verifyin
ng NIC Con
nnectivity
1. Usingg Windows Remote

R Deskktop Connecttion or a sim
milar tool, verrify that it is p
possible to
conneect to the Wiindows VM over
o both ann external nettwork and ann external bo onded networrk.
2. Usingg Iperf, verifyy connectivitty between th

he VMs on thhe XenServeer single-serveer private
netwoork.
Verifyin
ng NIC Speeed
Testing to
o see if the NIC
N can send which it was
d and receivee traffic at thee approximatte speed for w
rated can reveal issuess, such as, for example, problems withh the NIC drrivers.
Before beeginning the tests, downlo oad and instaall Iperf on a Windows V VM, a Linux V
VM, and a
separate physical
p servver that is nott running XenServer (a coontrol host).
Run bothh the TCP bi--directional test

t and the UDPU tests beetween each VM and the control hostt. For
example, run the first test between
n (1) the Linuux VM and tthe control hhost and (2) th
he Windows VM
and the control host.
TCP Bi-Directional Test
he Windows VM, run thee following co

1. On th ommand witth the duratioon set to 3000 seconds:
iperf
f.exe -c 192.168.1.1
1 1 -d -t 30
00
2. Whilee running thee command on

o the VM, run
r the follow
wing commaand on the co
ontrol host:
iperf
f.exe –s
3. Repeaat steps 1 and

d 2 using thee Linux VM instead
i of thhe Windows V
VM.
4. Repeaat steps 1 to 3 using a NIIC bond.
Page 86
UDP Test
1. On thhe Linux VM
M, run the folllowing comm
mand with thhe duration sset to 300 secconds. In thiss test,
the VM
V functionss as the Iperff client.
iperf
f.exe -c 192.168.1.1
1 1 -u -t 30
00 -b <band
dwidth>
Replaace <bandwidt
dth> with “1000M” for a 1 gigabit NIC.. For a 10 giggabit NIC, reeplace <banddwith>
with “1000M”.
“
2. Whilee running thee command on

o the VM, run
r the follow
wing commaand on the co
ontrol host:
iperf
f.exe –s -u
-
3. Repeaat steps 1 and

d 2 using thee Windows VM
V instead oof the Linux V
VM.
4. Repeaat steps 1 to 3 except usin

ng each VM as the Iperf server and thhe control ho
ost as the Ipeerf
clientt.
5. Repeaat steps 1 to 4 using a NIIC bond.
Verifyin
ng your Xe
enServer Networking Setting
gs and Co
onfiguratio
on
After settting up your XenServer networking
n co
onfiguration,, verify that yyou did it corrrectly by
checking the followinng:
1. Manaagement Inteerfaces.
Confi
figure networrking after fo orming the po ool, as descriibed in “Sequuence of Nettworking
Confi
figuration Tassks” on pagee 18. After creating the ini nitial networkking configurration or addiing
hosts to a pool, it is possible for
f the primaary managem ent interfacees on the other hosts in th he
pool to be incomp pletely configgured (for exxample, if thee pool masterr does not suuccessfully
propaagate its settings to the member
m or joiining servers)).
1. Verify thaat each primaary managem

ment interfacee uses the sam onding) NIC on
me (correspo
each XenSServer host.
2. Verify thaat you set a un

nique IP add
dress on eachh XenServer pprimary man
nagement
interface or
o bonded paair of primaryy managemennt interfaces.
3. Verify a) and
a b) on anyy additional management
m t interfaces yoou configureed (for examp
ple,
for storage)
2. Verify
fy all the NIC
Cs you bondeed were creatted correctly.. To do so, chheck the XennCenter logs for
failures or any bonnds that unfiinished. A typ
pical sign thaat bonding ddid not work is that the bo
ond
takes excessively long
l to finish
h or it seems to “hang.”
Page 87
3. Verify
fy that the networking con
nfiguration and
a physical ccabling on eaach XenServeer host matches.
For example,
e is NIC ng as NIC 3 on
N 3 on Hosst 4 configured with the ssame networrks and cablin
Host 5.
Tip: To
T make an LED light fo or a NIC on a XenServerr host blink, rrun the ethto
ool comman nd
with the
t –p option n on the hosst. ethtool is a Linux com
mmand that ddisplays or ch
hanges NIC
settin
ngs. For exam
mple, to use the
t ethtool command to make the ligh ghts on the firrst NIC on tthe
host, run the follo
owing on the host: ethto ool -p eth0 0 10.In thiss example, et
th0 is the N
NIC
and 10
1 is the num mber of secon nds you wan nt the NIC too blink.
4. In XeenCenter, sellect each host individuallyy, and verify the informattion in the N
NICs and
Netwwork tabs is fully
f present..
In thee NICs tab, there should d be a row in the NICs lisst for each N
NIC. Verify th
he columns in
n the
list haave correct values,
v especially the speed
d and MAC address coluumns.
In thee Networks tabs, verify that

t all the NICs
N listed inn the NICs taab are presen
nt and they h
have
the co
orrect network listed besiide them.
5. Verify
fy that the ph
hysical networking configuuration matcches for eachh XenServer h
host (that is,
me connectiviity as NIC 3 on
checkk to make surre that NIC 3 on Host 4 is cabled to hhave the sam
Host 5 and so on)).
6. If youu are using a vSwitch as the networkin

ng bridge, veerify that it is enabled on all hosts in th
he
pool.
7. Installl two VMs on

o different hosts,
h if neceessary, and puut them on thhe same netw
work to see if
they can
c “ping” eaach other.
Reso
olving Is
ssues
If, after checking
c thesse items, VM
Ms or hosts caannot connecct to each othher as expectted, then:
1. Verify
fy that your physical
p confiiguration (cab
bles and swittches) is corrrect.
Impo ortant: The #1

# networkin ng issue the XenServer
X teechnical suppport team seees is not actuually a
XenSeerver issue. Most
M calls are from custom mers with inccorrectly conffigured physiical networkss
(cabliing errors) orr incorrectly configured switches. Beffore calling C
Citrix Techniccal Support,
verifyy your cablingg configuratiion.
1. Revieew the section n, “Recoveriing from a baad network cconfigurationn” in the XennServer
Admiinistrator’s Guiide.
Impoortant: Afterr the pool is in

i productionn, always usee extreme carre when channging the phyysical
netwo
orking hardwware in a hostt. Before chaanging, addinng, or replacinng any NICss on the host,
Page 88
alwayys take the VM
Ms offline an
nd put the hoost into mainntenance modde so that th
he host is no
longeer connected to any storagge repositories.
Page 89
Revis
sion His
story
Revision
n Comm
ments Daate
1.0 Initial Release

R Ap
pril 28, 2011
2.0 Updateed for XenSeerver 6.0 release. Also, addded appendiix September 23, 2011
about changing
c youur networkingg configuratiion.
Page 90
About Ciitrix
Citrix Sysstems, Inc. (N

NASDAQ:CT TXS) is the leading
l proviider of virtuaalization, netw
working andd
software as a service technologies
t for more thaan 230,000 oorganizations worldwide. Its Citrix
Delivery Center, Citriix Cloud Cen nter (C3) and Citrix Onlinne Services product famillies radically
simplify computing
c fo
or millions off users, delivvering applicaations as an oon-demand sservice to anyy
user, in an
ny location on
o any devicee. Citrix custo omers includde the world’’s largest Inteernet compannies,
99 percen nt of Fortunee Global 500 enterprises, and hundredds of thousannds of small businesses and
prosumerrs worldwidee. Citrix partn ners with oveer 10,000 com mpanies worl rldwide in mo ore than 100
countries. Founded in n 1989, annuaal revenue in n 2010 was $11.87 billion.
©2011 Citrix Systemss, Inc. All righhts reserved.. Citrix®, Acccess Gatewaay™, Branch Repeater™,,
Citrix Rep
peater™, HD DX™, XenServer™, Xen nCenter™, X XenApp™, X XenDesktop™
™ and Citrixx
Delivery Center™ aree trademarks of Citrix Sysstems, Inc. annd/or one or more of itss subsidiaries, and
may be reegistered in the United Sttates Patent and
a Trademaark Office annd in other co ountries. All other
trademarkks and registered trademaarks are prop perty of theirr respective oowners.
Page 91

XS 60 Design Network - Advanced PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

XS 60 Design Network - Advanced PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Citrrix Xe

Purposse of the Guide ....................................................................................................................................... 6

Additio ology ................................................................................................................................... 8

Chapter 2: working Conccepts ..................................................................................... 11

Introduuction to Xen working .....................................................................................................11

Networrking Configguration afterr Installation......................

Sequen orking Configguration Taskks .........................................................................................18

Cabliing Configurration for XenServer .....................................................................................................18

Creatting Networkk Resiliency through

Scenaario 1: Segreggating Traffic .................................................................................................................28

Scenaario 2: Usingg the Manageement Netwo

Scenaario 3: Isolatting VM Trafffic on a Privvate Networkk ......................................................................30

XenSerrver Networkking Supportt and Requireements ................................................................................42

Conssidering Worrkload Comm

work Configguration ...............................................................................45

Deteermining Hosst Networkin

n against Nettworking Reqquirements ....................................................47

mber of Physsical NICs peer Host ........ .......................................................................49

Decidin d Virtual Switch .......................................................................................53

ning Networkk Redundancy .................................................................................................................56

Seleccting a Type of ding ............................................................................................................58

Best Practices forr Bonded Intterfaces ......................................................................................................62

Design mance ........................................................................................................63

Testiing XenServeer Network Performance

Configuuring Redundancy for Sto

Suggesttions for Imp

Virtualiizing the Pro

Disabliing the Spann

Best Prractice Configurations .........................................................................................................................83

Veriffying your XeenServer Nettworking Setttings and Coonfiguration ..................................................87

Resolviing Issues ..............................................................................................................................................88

To providde you with the

Virtu ual Interfacee. On a VM,, there is a loogical interfacce that appeaars

Hosst. A XenServver host is thhe physical seerver on whicch the XenSeerver

Pooll. A XenServver resource ppool or “poool” is a conneected group o

Poolls comprise a pool masterr and suborddinate serverss known as ppool

This guide may present

A NIIC bond is a pair of NIC s configuredd so they logically function

Primary Managemeent Interfacee. The primarry managemeent interface is a NIC asssigned an IP

This docuumentation explains

These sam mple scenarioos focus on three

Chapter 2 introducess XenServer networking

Chapter 4 provides guidance

Chapter 5 provides innformation about

Chapter 6 provides in nformation about

Chapter 7 provides innformation about

Chapter 8 provides in nformation about

The mostt important networking

This illustrration contrastss a regular NIC

The illusttration that fo

This illustrration shows hoow, during insttallation, XenS

Note: If you plug anyy NICs into switches

This illustrration shows tw

Ideally, yoou should ad

After creaating a new pool

XenServeer requires neetwork settin

Importan nt: After join

1. Cablee the hosts byy plugging alll NICs into the

4. Creatte a pool of the hosts, if you

1. Iff you did nott cable your hosts

In an envvironment wiith only one logical

Ensuringg that the corrresponding NIC

Note: Wh hen you configure netwo NICs plugged in to switches,