Politecnico di Torino
Dipartimento di Automatica ed Informatica
TORSEC Group
Performance of Xen’s
Secured Virtual Networks
Emanuele Cesena
Paolo Carlo Pomi
Gianluca Ramunno
Davide Vernizzi
<cesena@mat.uniroma3.it>
<paolo.pomi@polito.it>
<ramunno@polito.it>
<davide.vernizzi@polito.it>
Outline





Introduction
Experiments
Model
Security mechanism
Conclusion
Introduction
Motivations

Server consolidation
 Planning

Model of virtual network
 Emulation
 Comparison
Virtualization

“Technique for dividing the resources of a computer
into multiple execution environments called
virtual machines (VMs)” (A. Singh)

Full virtualization
 Complete emulation of the underlying hardware
 Unmodified operating system in the VM

Paravirtualization
 VM needs a modified OS
 Best performance, close to native
Virtualization: XEN

XEN is a free Virtual Machines Monitor (hypervisor)
 x86, Intel Itanium, PowerPC platforms
 Paravirtualization, full virtualization (hw support)
 Very low overhead when paravirtualized: average
3-5%

Virtual machines
 Domain-0: privileged VM
 Direct access to hardware
 Direct interface to the hypervisor
 Guest domains
Virtual Network in XEN

Network interfaces
 Front-end within VM: eth0
 Back-end in Domain-0: virtual interface (vif)
 Connection between netfront and netback
provided by the hypervisor
Guest 1
eth0
Domain 0
vif1.0
vif2.0
XEN hypervisor
Guest 2
eth0
Virtual Network in XEN

Virtual Network
 Domain-0 manages all the netbacks
 Bridge as “L2-switch”
Domain 0
physical
world
peth0
switch
br0
eth0
Dom-0
Guest 1
vif0.0
vif1.0
Guest 2
XEN hypervisor
vif2.0
Virtual Network in XEN

Example: Guest 1 sends a packet to Guest 2
 packet created within Guest 1 stack
 copied from FE to BE via page flipping
 forwarded through the bridge
 copied from BE to FE, then received by Guest 2
Guest 1
Domain 0
Guest 2
br0
eth0

vif1.0
we call this a virtual link
vif2.0
eth0
Experiments
Experiments


HP Compaq dc7700
 Intel Core2 Duo 2.13 GHz
 RAM: 2GB
 XEN 3.0.4
 Linux kernel 2.6.20
10 Virtual Machines (guests)
 RAM: 128 MB
 Linux kernel 2.6.20
 minimal Debian installation
 IPerf to test network bandwidth
Experiments: Virtual Network

Simple topology
 All VMs connected to the same bridge
Client
Guest 1
Server
Guest 1
Client
Guest 2
Server
Guest 2
Client
Guest 3
Server
Guest 3
bridge
Client
Guest 4
Server
Guest 4
Client
Guest 5
Server
Guest 5
Experiments: Virtual Network

Simple topology
 All VMs connected to the same bridge

Up to 16 virtual links
 IPerf TCP channels
 Example with 7 links
Client
Guest 1
Server
Guest 1
Client
Guest 2
Server
Guest 2
Client
Guest 3
Server
Guest 3
bridge
Client
Guest 4
Server
Guest 4
Client
Guest 5
Server
Guest 5
Experiments: tests




SMP disabled
SMP enabled
Static domain scheduling
10 iterations for each experiment
 1 minute per link
 Samples every 5 sec
 Average value
Experiments: Results

NoSMP vs. SMP
Experiments: Results

Dynamic scheduling vs Static scheduling
Model
Model: assumptions



Simple resource model
 Single type of resource
 Resources completely separated in system and
network
Network described by the number of virtual links
Bandwidth equally distributed among links
Model



M: maximal total bandwidth
M – K: minimal total bandwidth
F(n): total bandwidth
Bandwidth
F
Total
resources
M
Network
resources
System resources
n links
K
Model

Model curve vs. experimental data: error less than 2%
Security mechanisms
Security mechanisms


Adding security brings
 More workload
 More networking
We focused on increase of number of links (eg.
firewalls)
Security mechanisms


Number of links increases by a factor s
 Depending on topology
 Depending on the security mechanism
The model allows prediction on the loss of bandwidth
Model application 1/2



Scenario: server consolidation
 Computation power available
The virtual network must supply the physical interface
If the virtual network is well-designed, the virtual
network supports the transaction
Model application 2/2


What happens if we introduce a firewall?
Applying the model we can esteem the resulting
bandwidth
Conclusions
Future works



Improve the model
 Relax assumptions
 Forecast parameters without experiments
Validate the model
 Other architecture
 Other security solutions
Improve Xen
 D2D communication
 Optimization
Conclusions


We developed a simple (but still effective) model
 Explain how virtual network works in Xen
 Foresee performance of the virtual network
 Planning
 Impact of security solutions
We show the limits of current Xen’s implementation
and suggested improvements
Thank you
Any question?