The Open Source Virtual Lab: a Case Study

Ernesto Damiani

Fulvio Frati

Davide Rebeccani

Department of Information
Technology
University of Milan
Italy

Department of Information
Technology
University of Milan
Italy

Department of Information
Technology
University of Milan
Italy

[email protected]

[email protected]

[email protected]

ABSTRACT
E-Learning is becoming a standard issue for Information
Technologies degree courses. Video lessons, on-line exercises, and didactic forums, with interactions with tutors
and teachers are already provided by current on-line degree
courses. Within this scenario, there is a lack of virtual environments to allow students to make real experiences on
network programming and configuration. In order to plug
this gap, within the on-line degree course of Security of
Informatics Systems and Networks provided by University
of Milan, our group designed and realized the Virtual Lab,
to offer to students a complete training environment accessible via web directly from normal web browser. This paper
describes our fully open source solution and supplies a road
map for other future works on virtual laboratories and online
teaching.

Keywords
e-Learning, On-Line degree courses, Open Source, Virtual
Laboratories, Xen

1.

INTRODUCTION

Providing hands-on experience by using computer and making exercises on network configuration and security-related
issues are essential for current Information Technologies (IT)
education. In fact, IT degrees rely on laboratory activities, especially for courses that aim to provide an experience on network programming. Many universities, therefore, developed security laboratories, from which realistic
experience of security technologies, network programming
and tools become available for students. Thanks to Internet
technologies, it is now possible to offer courses and laboratories on the web that satisfy all functionalities of conventional laboratories. However, some issues remain to be
solved. For instance, conventional laboratories usually are
implemented on an isolated network which allows students
to exercise on network programming, firewall design, etc.
Although this isolation, that prevents students from per-

forming some dangerous operations, there are several problems, like system failures, that can be recovered manually
only if they take place in a conventional laboratory. The
computational resource requested and the fact that virtual
machines must be used with administrator privileges, make
virtual laboratories very difficult to develop. Nevertheless,
they are of paramount importance in case of remote teaching
and e-Learning experience, especially in Information Technologies related courses. This idea, coupled with the eLearning Strategies of University of Milan1 and the Italian legislation (ministerial decree 17.4.2003, http://www.
mininnovazione.it/ita/normativa/allegati/Decreto17_
04_03.pdf) that defines the possibility of online university
degrees, constitutes the bases of University of Milans CdL
(Corso di Laurea, degree course) online project. This online course, focused on security related issues, provides an
e-Learning experience with a full support of a virtual laboratory. This kind of e-Learning experience is not only an online
distribution of course related material: CdL online is not a
simple online version of a normal university course but
an online focused course with a totally re-minded and redesigned teaching context. The e-Learning model used is a
blended model based on the presence of different teaching
situations: traditional lessons, online video-lessons, forum
activities, online exercises and laboratory exercises. In this
context, we develop the Virtual Lab project basing only on
open source technologies. This fully open source system has
been developed using Xen platform on top of Gentoo Linux
distribution. In this manner we overcome all problems related to virtual networking laboratory and networking programming on virtual network using powerful Linux scripts.
The purpose of this paper is to present our fully open source
virtual laboratory for e-Learning on University course of IT,
and to propose an ideal road map for other future works on
virtual laboratories and online teaching. This paper is organized as follows. Section 2 presents related works about
existing implementations of remote laboratories and available virtualization techniques. Section 3 globally describes
the entities of our environment. Section 4 shows the Virtual
Lab system framework and the implemented technologies.
Section 5 describes in details how we configured the Virtual
Lab environment. Section 6 lists some expected enhanced of
1
This strategies is well delineated in international congresses: e-Learning: una sfida per luniversit`
a. Strategie, metodi, modelli (11-13 November 2002) and the following meetings e-Learning 2003 ANEE (30 June 2003)
and Qualit`
a nella gestione di progetti di e-Learning (June
2004)

our project, and, finally, Section 7 presents our conclusions.

2. BACKGROUND
2.1 Related Work
Remote laboratories represent the translation of in-situ laboratory experiments to distance learning (or e-Learning), offering remote access to real laboratory equipments and real
instruments. New way for e-Learning is a virtual laboratory,
where a simulation system commonly replaces the real system. Virtual laboratories typically were born for simulation
software such as Matlab+Simulink in case of [6] or LabView
for [15] or web-based training system for Information Technology Security named Telelab [10, 11], that provides to
students virtual machines related on a particular security
exercise. Yet, one has to take care that such software can
be also used for real system control. One can find remote
(or virtual) laboratory experiments in various scientific and
technical topics such as automatic control in [7], electronics,
chemicals and mechanicals in [8] and robotics in [5, 14].

2.2

Related Techniques for Virtualization

A Virtual Machine (VM) is a duplicate of a real machine

running in an simulated environment. This simulated environment is exposed by the virtual machine monitor, a software component that presents a layer functionally identical
to the underlying hardware, manages the VMs instances and
controls system resources access. Thanks to this hardware
replication the applications running on a VM are not aware
of running in a simulated environment. Applications have
thus at their disposal an environment populated with virtual
devices such as virtual disks, emulated processors, virtual
network adapters, and so on. This approach ensuresa VM
isolation.
The Virtual Machine Monitor (VMM) has the complete control over the resource pool allocated to the VMs; is impossible for an application running in a simulated environment
to use resources not explicitly assigned to its container.
There are mainly two approaches to virtualization: full virtualization and paravirtualization. The full virtualization
strategy aims to create a virtual execution environment for
running full unmodified operating system images, replicating the original guest operating system platform behavior
and facilities on the host system. The main drawback of
this approach regards the intrinsic slowness of the implementation of this type of solution, and the need to mimic a
real complete system behavior and to enforce resource isolation lead to the realization of a complex resource-hungry
software component. Full virtualization is featured in products such as VMWare [19], Bochs [12], and QEMU [3]. Paravirtualization approach addresses the performance problem
demanding that the guest operating system must be modified to run in the virtual environment. The need of applying
changes or patches to the kernel requires obviously the operating system source to be available. At times, the two
strategies have been mixed in some emulators to take the
best of each approach.

3.

SYSTEM DESCRIPTION

Fundamental requirement of e-Learning platforms is to make

contents accessible on the web and give to students a privileged communication channel with didactic tutors and teachers [18]. To achieve this goal, e-Learning platforms share a

common three-tiers structure composed by a user interface,

represented by user web browser, connected to a web server,
that provides services based on data repositories and connects users to resources. CdL online e-Learning environment
follows this architectural paradigm and its structure is depicted in Figure 1.
The system is composed by three major entities:
1. the e-Learning platform, that allows the access to courses contents and to the Virtual Lab, and the interactions with tutors and teachers;
2. the Virtual Server, that implements an informatics laboratory which provides students with a real working
environment; it consists of a VMs pool, a virtualization server and a firewall. The pool contains VMs
which are assigned to students.
3. the student web browser, that allows to connect and
interact with the platform and runs applet to connect,
by ssh connections, to the assigned VM.
Each user is identified by username and password whereby
access to the platform by means of the web browser. The
services supplied by the platform are fourfold:
1. Communication services, where students can communicate with their coursemates and didactic tutors with
dedicated forums;
2. Community services, where students can find profiles
of teachers, tutors and students themselves;
3. Teaching services, that give access to contents (videolessons and exercises) related to courses students are
enrolled on;
4. Calendar services, to remind students deadlines and
engagements.
Within the teaching services, we focus on the implementation of the Virtual Lab, where each student can interact with
an own Linux VM with all administrator privileges. They
could access to it following specific links in the platform;
these links will establish a connection with the Virtual Lab
server and open a ssh shell on the students VM.
As described in Figure 1, the e-Learning platform is connected to the Virtual Lab server through a dedicated firewall
that filters and manages all incoming connections, ensuring
virtual server security and isolating the VMs pool from external environment. In fact, each VM operates in a sealed
environment: students can modify the overall Linux system
configuration and can interact with all VMs that are active at the same time; communication between students and
their own VM is allowed only by a ssh connection through
predefined ports. Teaching activities are shaped basing on
Virtual Lab: exercises consist of making simple application about network programming, as for instance Socket and
RPC (Remote Procedure Calls) libraries, and discussions in
forums stimulate students to try what they learned during
lessons, as for instance configuring system firewall, routing

Figure 1: System structure

tables, and network interfaces. In this way, students, in
addiction to learning theoretic notions, are faced with real
world systems and can try to resolve real world problems.

4.

THE VIRTUAL LAB FRAMEWORK

The system framework of Virtual Lab can be examined focusing on three aspects:
the Hardware of the Virtual Server and the Firewall;
the Virtualization software;
the Virtual Machines.
Each of these aspects is explained in details in the following
sections.

4.1

Hardware

In order to implement a reliable and scalable environment,

the requirements that drive our choices about hardware were
essentially two: a spacious storage unit, that allows us to
give to students a complete development environment, suitable also for different courses that could need additional software, and a big RAM memory, indispensable to allow the
system to manage as much as VMs at the same time.
Following these requirements, we choice to implement the
virtual server with these characteristics: a Fujitsu-Siemens
Primergy RX-300 S2 with 2 Intel Xeon EM64T CPUs at
3.20Ghz, 8 Gb RAM memory and four 300 Gb SCSI U320
hard disks in RAID 5; the server is connected to our internal
net with a Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI network interface. The firewall is implemented on a separate machine to increment system security

from external attacks and to preserve virtual server performance. The firewall has the following features: a FujitsuSiemens Primergy RX-100 S2 with an Intel Pentium 4 CPU
at 3.00 Ghz, 1Gb RAM memory and two 80Gb SATA hard
disks. Further, it is connected to the external net with an
Intel Corporation 82541 GI/PI Gigabit Ethernet network
interface.
The maximum number of VMs running simultaneously on
our system is currently about 90, and the storage occupation
is currently of about 300 Gb, that allows us to fully manage
all students of current and future academic years.

4.2

The Virtualization Software: Xen

For our system, we choose Xen as virtualization framework.

Xen is a virtual machine monitor created by the University
of Cambridge [2, 21] and released under the GNU GPL license that embraces the paravirtualization approach. Xen
supports x86/32 and x86/64 platform, and, using the hardware CPU virtualization provided by Intel VT and AMD
SVM technologies, has the ability to run an unmodified
guest operating system kernel. As said previously, Xen requires the guest operating system kernel to be ported to the
environment x86-xeno architecture. Its paravirtualized virtual machine monitor or hypervisor permits to achieve performance close to native hardware. More in detail, a Xen
system is composed by multiple layers as shown in Figure
2. Each isolated virtual execution environment is called domain. Xen hypervisor [4] manages the scheduling operation
related to the execution of each domain, while each guest
operating system manages the VM application scheduling.
During system boot, a domain with special privileges, Domain 0, is automatically created. Domain 0 can initialize
other domains (DomU ) and manages their virtual devices.
The majority of all management and administration tasks

Figure 2: Xen system layers.

are carried out through this special domain. Xend, a process
that runs in domain 0, manages VMs and provides access to
their console. Common Xen usage scenarios include kernel
development, operating system and network configuration
tests, server consolidation and server resources allocation.

4.3

Virtual Machines

The implementation of virtual machines required a further

analysis based on some additional considerations.
First, a VM has to be an efficient, isolated duplicate of a
real machine [13]. Every VM works in a sealed environment, to isolate its disk and memory address space and to
protect system integrity from possible VM failures. Second, we had to supply to students a complete and up to
date operating system, in order to give them all the instruments to develop simple programs and get experiences on
system configurations. Further, some hardware constraints,
in particular the 64 bit implementation of the server, and
the support of Xen, restrict the set of possible acceptable
operating systems. Following the points depicted above and
basing to our previous experiences, we chose to implement
our VMs based on the Linux distribution Gentoo, that is
described in Section 4.3.1.

4.3.1

Gentoo

Gentoo is a Linux distribution [9, 17] with several unique

characteristics that fit our requests about VMs. First of all,
the major feature of Gentoo distribution is its high adaptability, thanks to a technology called Portage. Portage performs many key functions: i) software distribution system,
that permits to developers to install and compile only the
needed packages that can be added at all the time without reinstalling the entire system, ii) package building and
installation, Portage automatically builds a custom version
of the package optimizing it for the underlying hardware,
and iii) automatic updating of the entire system. Second,
Gentoo is fully open source and distributed under the GNU
General Public License. Finally, Gentoo supports our 64 bit
architecture and implements the Xen environment.

5.

VIRTUAL LAB IMPLEMENTATION

The implementation of Virtual Lab follows three major steps:

the Network configuration, the Firewall configuration, and
the Platform connection. In the following sections, these
steps are explained without enter into details. A more specific description of configuration technical details is out of
the scope of this paper.

5.1

Network Configuration

The initial stage of VMs network configuration is the creation of VM images. In fact, each VM is composed of a root

kernel = "/home/kernels/vmlinuz-2.6"
memory = 512
name = "vm-10058"
vif = [ ]
ip = "10.0.0.1"
netmask = "255.255.255.0"
gateway = "10.0.0.254"
disk = [file:/vm/root-10001,hda1,w,
file:/vm/swap-10001,hda2,w]
root = "/dev/hda1 ro"
Figure 3: Xen virtual machine configuration file example.
image, that represents the available disk space and contains
the operating system and the installed packages, and a swap
image, used to manage memory swaps. We create an initial
2 Gb image over which we install a basic version of Gentoo.
This image contains all essential services and, in particular,
a complete gcc compiler and tools such as iptables, text editors, Perl and Python. The swap image is created by the
mkswap command and has a size of 256 Mb. At this point,
we have to associate each student with the relative root and
swap images. Students root and swap images are automatically created by a shell script, that reads students id and
copies the original images naming them by the concatenation of the string root and swap with the student id
plus 10000.
The next stage is to create for each VM the relative Xen
configuration file, that contains all the settings specific to
this VM. Figure 3 shows an example of Xen configuration
file created by a shell script for the student id 1. Except
for small differences, all the VMs share the same settings
[20]:
kernel : indicate which kernel load at boot time;
memory: indicate the amount of server memory to
assign to the VM. This value is tuned basing on VM
purposes and installed packages;
name: indicate the name to assign to the VM. Since
it has to be unique within the Xen environment and
it is used to refer to the specific VM, it is created
concatenating the string vm- with the student id
plus 10000.
vif : allow to specify additional options for the virtual
network interface, as for instance the VM MAC address;
ip: set a static IP address to the VM. IP addresses are
assigned sequentially and all students of the same year
share the same subnet. For the next year, IP addresses
will be in the form of 10.0.1.x;
netmask : set the netmask, allowing students to communicate only with VMs owned by students of the
same year. In particular, they can communicate only
with machines that share the same subnet;
gateway: set the VM common gateway. The gateway is
responsible for the management of the packets through

$IPTABLES -t nat -A PREROUTING -p tcp -i

$EXTERNAL_INTERFACE -d $VM_PUBLIC_IP
--dport 10001 -j DNAT
--to-destination 10.0.0.1:22
$IPTABLES -A FORWARD -p tcp
-i $EXTERNAL_INTERFACE
-o $INTERNAL_INTERFACE
-d 10.0.0.1 --dport 22 -j ACCEPT
Figure 4: Example of firewall rules.
the subnet. The gateway IP is the same than the Xenbridge (see Figure 5), a virtual network interface that
supervises all communications between VMs and the
external net;
disk : indicate where root and swap images are located
into the host system and in which logical partition, of
the guest system, mount them (in the example hda1
and hda2 );
root: indicate which partition, specified in the previous
disk field, has to be considered as the root partition.
At this point, the server is ready to work as a virtualization
server and VMs can be started, accessed locally via console
or ssh, and destroyed. Our goal is a little more complicated,
since we have to give to the student the access to her VM
via ssh through the e-Learning platform, and, at the same
time, isolated virtual server from the external net, except for
the ssh channel. These features has been achieved through
particular a firewall configuration.

5.2

Firewall Configuration

In the Virtual Lab project, the firewall has three main goals:
protects the server from external attacks, isolates VMs from
the external net, and forwards connections from student
computer, through the e-Learning platform, to the relative
VM via ssh. Note that each VM has a local IP address and
can not be accessed from the external without some specific
firewall configurations.
Figure 5 shows the communication flow between the platform, with its public IP address,
accessed by a student, to the virtual server through the firewall. In particular, the figure explains how the student,
whose id is equal to 1, through the platform, accesses to
the firewall; the port number used to connect identifies univocally the VM owned by the student. Based on this port
number, firewall rules forward the incoming connection to
the right local IP, identifying the VM, to the well-known
ssh port 22. Looking at the example in Figure 5, the incoming communication on port 10001 is forwarded to local
IP 10.0.0.1 on port 22, hence to VM 1. Figure 4 supplies
an example of firewall rules, created by a shell script, that
forward connections from port 10001 to the local IP 10.0.0.1
on the port 22 and vice versa. The first statement in the example literally says to add to the NAT table of the firewall
a rule to intercept all incoming packets from the external
interface, on the TCP protocol, on the 10001 port and to
forward them to the local IP 10.0.0.1, the VM running on
the virtual server, on the port 22. The second statement
add a rule to the FORWARD chain; this rule accepts all

incoming connections from the external interface to the internal interface that are directed to the local IP 10.0.0.1 on
the port 22 [16].

5.3

Platform Connection

The final step of Virtual Lab configuration resides in defining

the communication protocol between the e-Learning platform and the virtual server. As said before, the interaction
between students and VMs happens via ssh protocol. To increase server performance, VMs are not loaded at boot time;
they are started only when requested by the platform. Every time a student activates her VM, the platform calls the
script in Figure 7 to start a specific VM; in the same way,
when she closes the connection, the platform calls again the
script to shutdown the VM. The script we used accepts two
parameters: the first one can be start or stop, respectively,
to load and shutdown the VM, and the second contains the
id of the student who asks for the operation. Looking to the
script in details, in case that the first parameters is equal
to start, the system calls the Xen command xm to load
the VM associated to the configuration file and relative to
the student specified by the second parameter. If the second
parameter is stop, the system closes the VM and looks for
unmounted loop devices, detaching, with the Linux command losetup, the file associated with the specified loop
device. Once the platform has started the corrected VM,
the direct connection with the student can be finalized. The
platform then opens an applet that supplies the ssh shell; the
applet we choose is MindTerm [1], a pure Java client that implements the SSH1 and SSH2 protocols and is released free
for non-commercial use. To summarize the communication
flow between all actors (Student, e-Learning Platform, Firewall, Virtual Server, Virtual Machine), Figure 6 shows the
UML sequence diagram of a communication session, starting
from the user platform login and including the VM activation and concluding with the VM closing.

6.

FUTURE WORKS

There are essentially two categories of new features that will

be implemented in future releases of the Virtual Lab. The
first category comprises enhancement in the management of
VMs: we plan to create scripts for the nightly back-up of
VMs home directory and for software updates or new packages installation. The second category will include the need
to create new and more complex network topologies, where
each student will own a private subnet with, for example,
three VMs that will act as client computer, web server, firewall, to test applications for a real net environment.

7.

CONCLUSIONS

In this paper we presented our e-Learning experience within

the more comprehensive project of on-line degree course of
Security of Informatics Systems and Networks of University of Milan. Virtual Lab manages a pool of 120 users and,
actually, registered an average of 30 contemporaneous accesses. We implemented a Virtual Lab that supplies to each
student a own VM accessible every time by a ssh connection,
instead of different approaches, as for instance [10][11], that
do not provide personal VMs. We described step by step
how we realized all the framework to give to interested organizations a road map to build a cost effective, fully open
source solution that allows them to provide to students a
complete and available working environment.

Figure 5: Communications between virtual machines and the external net through Xen-bridge.

Figure 6: Virtual Lab communication UML sequence diagram.

#!/bin/bash
XM="/usr/sbin/xm"
MACHINES_CONFIG="/vm"
CONFIG_PREFIX="config-"
case "$1" in
start)
sudo $XM create
$MACHINES_CONFIG/$CONFIG_PREFIX$2
;;
stop)
sudo $XM shutdown
sudo xm list|grep $2|awk {print $2}
sleep 10
if [ -z sudo losetup -a |
grep root-$2 |
cut -d ":" -f 1 ];
then
exit;
else
sudo losetup -d
sudo losetup -a |
grep root-$2|
cut -d ":" -f 1
sudo losetup -d
sudo losetup -a |
grep swap-$2|
cut -d ":" -f 1
fi
;;
esac
exit 0

Review, volume 37, 5, pages 164177, New York,

2003.
[3] F. Bellard: QEMU CPU emulator.,
http://fabrice.bellard.free.fr/qemu/.
[4] M. Ben-Yehuda: The Xen hypervisor: virtualizing a
machine near you, http://www.mulix.org/
lectures/xen-haifux-apr-2005/xen-haifux.pdf,
IBM Haifa Research Labs, 2006.
[5] A. Bicchi, A. Coppelli, F. Quarto, L. Rizzo, F.
Turchi, and A. Balestrino: Breaking the Labs Walls
Tele-Laboratories at the University of Pisa, In Proc.
of IEEE International Conference on Robotics and
Automation, May 21-26, 2001, Seoul, Korea.
[6] C. Bonivento, L. Gentili, L. Marconi, and L. Rappini:
A Web-Based Laboratory For Control Engineering
Education, In Proc. of 2nd International workshop
on tele-education using Virtual Laboratories, August
8-9, 2002, Sherbrooke, Canada.
[7] C. Chiliculita and L. Frangu: A Web Based Remote
Control Laboratory, In 6th Multiconference on
Systemic, Cybernetics and Informatics,July 14-18
2002, Orlando, Florida, USA.
[8] S.K. Esche: Remote Experimentation One building
Block in Online Engineering Education, In Proc. of
the 2002 ASEE/SEFI/TUB International
Colloquium on Global Changes in Engineering
Education, October 1-4, 2002, Berlin, Germany.
[9] Gentoo Linux, http://www.gentoo.org/, 2006

Figure 7: Shell script to load and shutdown virtual

machines.

Acknowledgments

[10] J. Hu, M. Schmitt, and C. Meinel: Virtual Machine

Management for Tele-Lab IT-Security Server, In
Proc. of 10th IEEE Symposium on Computers and
Communications (ISCC 2005), 2005.

This work was supported in part by the European Union

within the PRIME Project in the FP6/IST Programme under contract IST-2002-507591 and by the Italian MIUR within the KIWI and MAPS projects.

[11] J. Hu, C. Meinel, and M. Schmitt II: Tele-Lab IT

Security: An Architecture for Interactive Lessons for
Security Education In SIGCSE04, March 37, 2004,
Norfolk, Virginia, USA.

8.

[12] IA-32 Emulator Project, Available from

http://bochs.sourceforge.org/,2001

ADDITIONAL AUTHORS

Additional authors:
Marco Anisetti (Department of Information Technology, University of Milan, email: [email protected]),
Valerio Bellandi (Department of Information Technology,
University of Milan, email: [email protected]), and
Umberto Raimondi (Department of Information Technology,
University of Milan, email: [email protected]).

9.

REFERENCES
[1] AppGate Network Security - MindTerm,
http://www.appgate.com/products/80_MindTerm/,
April 2006.
[2] P. Barham, B. Dragovic, K. Fraser, S. Hand, T.
Harris, A. Ho, R. Neugebauer, I. Pratt, and Andrew
Warfield: Xen and the Art of Virtualization, In
Proceedings of the nineteenth ACM symposium on
Operating systems principles, Operating Systems

[13] G. J. Popek and R. P. Goldberg: Formal

requirements for virtualizable third generation
architectures, Communications of the ACM, 17(7),
1974.
[14] R. Safaric, D.W. Calkin, R.M. Parkin, and C.A.
Czarnecki: Virtual environment for telerobotic,
Integrated Computer-Aided Engineerings, Apr. 2001,
vol. 8, no. 2, pp. 95-104.
[15] C. Salzamann, H.A. Latchman, D. Gillet, and O.D.
Crisalle: Requirements for real-time laboratory
experimentation over the Internet In Proc. of 1998
International Conference on Engineering Education,
1998, Rio de Janeiro, Brazil.
[16] The NetFilter/IpTables Project, http://www.
netfilter.org/projects/iptables/index.html,
2006.

[17] G. K. Thiruvathukal: Gentoo Linux: The next

generation of Linux, j-COMPUT-SCI-ENG,
6(5):6674, Sept./Oct. 2004.
[18] G. Totkov: Virtual Learning Environments: Towards
New Generation, In Proceedings of International
Conference on Computer System and Technologies
(CompSysTech2003), Sofia, Bulgaria, 2003.

[19] VMware Inc. VMware GSX Server, Available from

http://www.vmware.com/, 2002.
[20] Xen User Manual - v3.0, http://www.cl.cam.ac.uk/
Research/SRG/netos/xen/readmes/user.pdf, 2006.
[21] Xen Virtual Machine Monitor - University of
Cambridge, http:
//www.cl.cam.ac.uk/Research/SRG/netos/xen/