Étude bibliographique:

Transparence des communications réseau dans la

migration à chaud de machines virtuelles entre
infrastructures de type cloud computing

Djawida DIB
Master informatique, spécialité Recherche en informatique
Établissement: IFSIC, Université de Rennes 1

Encadrants: Pierre RITEAU et Christine MORIN

Équipe: Myriads, IRISA / INRIA Rennes - Bretagne Atlantique

27 janvier 2010
Table des matières
1 Introduction 2

2 Virtualisation et migration à chaud 3

2.1 Virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Migration à chaud . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Problèmes réseau lors de la migration 5

4 Réseaux virtuels 6
4.1 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Classification des différents réseaux virtuels . . . . . . . . . . 9

5 Prise en compte des schémas de communication pour la mi-

gration d’applications distribuées 11

6 Conclusion 11

1
1 Introduction
Le cloud computing ou encore l’informatique dans les nuages est un nou-
veau concept dont les prémices remontent à la technologie des grilles de
calcul, utilisée pour le calcul scientifique. Une grille de calcul est une fédé-
ration de ressources informatiques hétérogènes (postes de travail, grappes
de serveurs, ...), distribuées géographiquement et appartenant à différentes
organisations. Les grilles informatiques permettent le calcul distribué à large
échelle en exploitant un grand nombre de ressources.
Le cloud computing fait référence à l’utilisation des capacités de calcul
des ordinateurs distants, où l’utilisateur dispose d’une puissance informa-
tique considérable sans avoir à posséder des unités puissantes. L’utilisateur
d’un cloud computing a l’impression d’avoir en permanence des ressources
de calcul et/ou de stockage illimitées. Il peut donc adapter le niveau des
ressources suivant la charge de ses applications. Les services qu’offre le cloud
computing sont facturés proportionnellement à l’usage des infrastructures
physiques (bande passante utilisée, caractéristiques des ressources) et à la
période d’utilisation.
L’approche du cloud computing s’appuie principalement sur la virtualisa-
tion, où la virtualisation est un ensemble de techniques permettant de faire
fonctionner sur une seule machine plusieurs systèmes d’exploitation et/ou
plusieurs applications, isolés les uns des autres. Un cloud est constitué d’un
ensemble de machines virtuelles qui utilisent la même infrastructure phy-
sique.
Les techniques de virtualisation permettent notamment la migration de
machines virtuelles d’un nœud physique à un autre. La migration à chaud
permet de déplacer une machine virtuelle d’un nœud physique à un autre
sans interruption de service, ce qui rend le processus totalement transparent.
La migration à chaud permet à un administrateur de débrancher une
machine virtuelle d’une infrastructure physique donnée qui nécessite une
maintenance sans soumettre les utilisateurs du système à un temps d’arrêt.
Un autre avantage de la migration est qu’elle permet d’améliorer la tolérance
aux fautes. Si une défaillance imminente est suspectée, le problème peut être
résolu avant l’interruption du service. La migration à chaud peut également
être utilisée pour l’équilibrage de charge, afin d’optimiser l’utilisation des
ressources CPU et de mieux gérer et économiser l’énergie.
Dans le cadre du clouds computing, les prix d’hébergement de machines
virtuelles dans les clouds peuvent varier au fil du temps et d’un cloud à
un autre, ce qui rend la migration des machines virtuelles entre clouds un
véritable atout économique du point de vue de l’utilisateur.

2
 Cependant les limitations de la migration à chaud s’inscrivent dans le
cas où on souhaite déplacer une machine virtuelle d’un réseau à un autre ou
d’un cloud à un autre, ce qu’on appelle la migration inter-site. Dans ces cir-
constances la machine virtuelle déplacée perd ses anciennes communications
à cause de conflits d’adressage ou de problèmes de routage. Ce rapport traite
cette problématique de migration inter-site.
Dans la suite de ce document, nous présentons la virtualisation et le pro-
cessus de la migration à chaud dans la section 2. Ensuite, nous décrivons les
problèmes des réseaux physiques lors de la migration des machines virtuelles
en section 3. Les solutions actuelles à ces problèmes se fondent principale-
ment sur les réseaux virtuels que nous détaillons en section 4. La section 5
introduit la notion de prise en compte des schémas de communication pour
la migration d’applications distribuées que nous allons réaliser pendant le
stage. Enfin, la section 6 conclut ce rapport bibliographique.

2 Virtualisation et migration à chaud

2.1 Virtualisation
La virtualisation est une technologie permettant l’exécution de plusieurs
systèmes d’exploitation et/ou plusieurs applications sur le même ordinateur,
ce qui accroît l’utilisation et la flexibilité du matériel.
Un même ordinateur peut ainsi permettre l’exécution de plusieurs ma-
chines virtuelles contenant différents systèmes d’exploitation et/ou diffé-
rentes applications isolées les unes des autres. La mise en œuvre d’une ma-
chine virtuelle (virtual machine ou VM) nécessite l’ajout d’une couche logi-
cielle à la machine physique. L’emplacement de cette couche dépend du type
d’architecture de la machine virtuelle [1]. Il existe deux types de technolo-
gies de machine virtuelle : les machines virtuelles applicatives (process virtual
machines) et les machines virtuelles système (system virtual machines).
Dans une machine virtuelle applicative, la nouvelle couche logicielle s’ap-
pelle runtime (abréviation de runtime software), et se place entre le système
d’exploitation et les applications utilisateur. La machine virtuelle applicative
est un programme qui émule dans un système d’exploitation un environne-
ment standardisé, isolé et sécurisé. Cela permet au concepteur de l’applica-
tion de ne pas avoir à rédiger plusieurs versions de son logiciel pour qu’il soit
exécutable dans tous les environnements. La création et la terminaison de
ce type de machine virtuelle se fait lors de la création et la terminaison du
processus exécutant l’application virtualisée.

3
 En revanche, dans une machine virtuelle système la nouvelle couche lo-
gicielle se place entre le matériel et le système d’exploitation et s’appelle
hyperviseur ou moniteur de machine virtuelle, en anglais hypervisor ou vir-
tual machine monitor (VMM). Une machine virtuelle système fournit un
environnement complet qui a son propre système d’exploitation.
Le système d’exploitation qui s’exécute dans une machine virtuelle sys-
tème est appelé invité, en anglais guest, tandis que la plat-forme sous-jacente
qui supporte la machine virtuelle est l’hôte, en anglais host. Une machine vir-
tuelle système offre une copie du matériel et se comporte exactement comme
un ordinateur physique contenant ses propres CPU, mémoire RAM, disque
dur et cartes d’interface réseau virtuels. En conséquence, le système d’ex-
ploitation invité est généralement incapable de faire la différence entre une
machine virtuelle et une machine physique.
Dans ce qui suit, nous nous intéressons principalement aux machines vir-
tuelles système, car elles offrent certains avantages par rapport aux machines
virtuelles applicatives tels que : un support avancé de la migration, ainsi que
le support de l’exécution d’applications patrimoniales (legacy application).
Ainsi un environnement d’exécution ne requiert pas de modification pour
être exécuté sur une machine virtuelle système.
Il existe deux types d’architecture de machine virtuelle système [2]. Dans
le type I le VMM se trouve directement au-dessus de la couche matérielle.
Au-dessus du VMM se trouvent les différentes VMs. Sur une de ces VMs
s’exécute le système d’exploitation (Operating System ou OS) de la machine
hôte qui gère le partage des ressources entre les autres VMs. Les autres VMs
exécutent des OS moins privilégiés. Cette architecture est utilisée notamment
par Xen [3].
Dans le type II, c’est l’OS de la machine hôte qui se trouve directe-
ment sur la couche matérielle. Au-dessus de celui-ci le VMM prend place.
Au-dessus du VMM se trouve les OS invités des différentes VMs. Cette ar-
chitecture est utilisée par des hyperviseurs tel que VMware Workstation[4],
KVM [5] ou VirtualBox [6].

2.2 Migration à chaud

La migration à chaud permet de déplacer une machine virtuelle d’un
nœud physique à un autre sans interruption de service et doit être tota-
lement transparente pour l’utilisateur. Le processus de migration à chaud
d’une machine virtuelle d’un hôte source vers un hôte de destination se com-
pose de six étapes principales [7] [8] :

4
 1. Réservation
L’hôte source envoie la requête de migration à l’hôte de destination
et attend sa confirmation de disponibilité des ressources. L’hôte de
destination réserve par la suite la mémoire nécessaire à la machine
virtuelle.
2. Copie itérative de pages mémoire
Pendant la première itération toutes les pages mémoire de la machine
virtuelle source sont copiées sur l’hôte de destination dans la mémoire
qui lui est allouée. Dans les itérations ultérieures, seulement les pages
mémoire modifiées (dirty pages) durant la phase de transfert précédente
sont copiées.
3. Stop et copie
La machine virtuelle est mise en pause afin de permettre une ultime
copie des pages mémoire modifiées. L’hôte transfère également les re-
gistres processeur ainsi que l’état des périphériques à la machine de
destination. Une fois cette copie terminée, la VM cible est une copie
parfaite de la VM source.
4. Redirection
L’hôte de destination indique à l’hôte source qu’il a correctement reçu
l’image de la VM.
5. Activation de la machine virtuelle
La machine virtuelle migrée est activée et peut continuer son exécution.
6. Mise à jour des informations réseau
Un message est envoyé au switch physique pour mettre à jour la table
ARP. Les paquets à destination de la machine virtuelle ne passent plus
par le même port physique.

3 Problèmes réseau lors de la migration

Dans cette section, nous définissons les problèmes réseau concernant la
migration des machines virtuelles d’un cloud à un autre et qui font partie de
la même grappe virtuelle. Une grappe virtuelle est un ensemble de machines
virtuelles utilisées pour l’exécution d’une application distribuée. Initialement
on suppose que toutes les VMs d’une grappe, qui communiquent entre elles,
se trouvent sur le même cloud (Figure 1).
Ensuite pour les raisons mentionnées dans l’introduction, on peut avoir
besoin de migrer certaines VMs de la grappe sur un autre cloud. Nous consi-
dérons trois cas problématiques. Le premier cas est le fait de migrer seulement

5
 Figure 1 – L’état initial du réseau virtuel.

une partie des VMs qui communiquent entre elles (Figure 2). Le deuxième cas
consiste à migrer la grappe virtuelle complète (Figure 3). Enfin le troisième
cas considère la migration d’une VM qui communique avec un utilisateur
extérieur, ne faisant pas partie de la grappe (Figure 4).

Figure 2 – Migration d’une partie de la grappe du cloud A vers le cloud B.

Dans les trois cas cités ci-dessus la communication s’interrompt, car les
adresses IP des VMs ne sont plus valides. Non seulement la recherche d’un
moyen pour résoudre ce problème est nécessaire, mais en plus il faut s’as-
surer que les performances soient optimales. Par exemple, si les machines
VM 2 et VM 3 de la Figure 2 veulent communiquer, elles doivent utiliser
l’infrastructure physique du cloud B sans passer par le cloud A.
L’approche de réseaux virtuels représente un outil très puissant pour
résoudre ces différents problèmes.Nous détaillons ce concept dans la section
suivante.

4 Réseaux virtuels
Le succès des réseaux privés virtuels (Virtual Private Networks ou VPN)
[9] a donné naissance au concept de réseaux virtuels (Virtual Network ou

6
Figure 3 – Migration de la grappe toute entière du cloud A vers le cloud B.

Figure 4 – Migration d’une machine virtuelle qui communique avec un

utilisateur de l’extérieur.

VN). Les réseaux virtuels prennent de plus en plus place dans la commu-
nauté réseau et offrent de nouvelles perspectives pour l’internet du futur,
tout en permettant le déploiement de différentes architectures et de diffé-
rents protocoles sur une infrastructure physique partagée [10].
La virtualisation réseau consiste à virtualiser à la fois les noeuds et les
liens. La virtualisation des nœuds est fondée sur l’isolation et le partitionne-
ment des ressources du nœud physique. D’autre part, chaque lien physique
peut transporter plusieurs liens virtuels. L’interconnexion de ces noeuds vir-
tuels et liens virtuels permet la création d’un réseau virtuel.
Outre l’avantage technique des réseaux virtuels qui permettent d’optimi-
ser l’utilisation des infrastructures physiques et de mieux les gérer, ce concept
a également des intérêts commerciaux. Par exemple le partage d’une infra-
structure physique entre différents opérateurs réseaux réduit considérable-
ment le coût de propriété.

7
4.1 État de l’art
Différentes architectures de réseaux virtuels ont été proposées : Violin
[11], ViNe [12], SoftUDC VNET [13], Virtuos VNET [14], PVC [15], N2N
[16], OCALA [17] et IPOP [18].
La majorité des réseaux virtuels cités ci-dessus s’appuient sur des réseaux
overlay. Les réseaux overlay sont des réseaux décentralisés, distribués, sans
organisation hiérarchique, où tous les noeuds, appelés pairs, jouent à la fois
le rôle de serveur et de client. L’organisation dans un tel réseau repose sur
l’ensemble des pairs, il n’y a pas d’entité chargée d’administrer ce type de
réseau. Ces réseaux overlay sont utilisés pour construire une infrastructure
de réseau virtuel permettant la communication au niveau 2 (Ethernet) ou
au niveau 3 (IP).
ViNe (Virtual Network) [12] est un réseau virtuel pour les grilles dont
l’architecture est fondée sur un overlay niveau IP. Un espace d’adressage
virtuel est alloué pour chaque réseau physique qui souhaite joindre la grille,
afin de permettre l’identification de ses hôtes. ViNe supporte de multiples
VNs indépendants dans la même infrastructure physique, et il est facilement
configurable pour l’ajout des ressources à la grille. Cependant, la migration
n’est pas mentionnée.
OCALA (Overlay Convergence Architecture for Legacy Applications) [17]
est un réseau virtuel permettant un accès simultané à de multiples overlay
et donne la possibilité aux hôtes des différents overlay de communiquer entre
eux. OCALA impose une couche Overlay Convergence (OC) entre la couche
transport et la couche réseau. La couche OC remplace la couche IP d’Internet
et se compose de deux sous-couches : OC-I, une sous-couche indépendante des
overlay utilisés et OC-D, une sous-couche dépendante d’un overlay particu-
lier. La reconfiguration (ajout et suppression des ressources) et la migration
ne sont pas discutées dans cette architecture.
IPOP (IP-over-P2P) [18] est un réseau virtuel P2P, son architecture
est fondée également sur un overlay. Dans un système P2P chaque nœud
a deux façons d’être adressé : à travers la couche réseau avec une adresse
IP, et à travers l’overlay via les adresses P2P. Les adresses IP des machines
sont utilisées uniquement pour rejoindre l’overlay et créer les connections du
réseau pair à pair ; les adresses P2P sont utilisées lorsque les communications
se font à travers l’overlay. IPOP utilise les adresses P2P pour les messages
de routage et une table de hachage produite par le système pair à pair ce
qui lui permet de supporter une allocation d’adresse distribuée (statique ou
dynamique). IPOP supporte l’ajout dynamique de nouvelles ressources, et
permet une migration transparente pour les réseau étendus.

8
 VIOLIN (Virtual Interconnecting on Overlay Infrastructure) [11] est un
réseau virtuel au-dessus de l’infrastructure overlay qui a son propre espace
d’adressage. VIOLIN améliore la virtualisation des réseaux et conduit à l’iso-
lation entre un réseau VIOLIN et le réseau IP sous-jacent. Toutes les entités
de VIOLIN sont hébergées par les hôtes de l’infrastructure overlay, et il est
possible de répéter cette virtualisation plusieurs fois, un Violin niveau-n peut
être crée au-dessus d’un VIOLIN niveau-(n-1), sachant que le niveau-0 re-
présente l’internet réel. VIOLIN est entièrement reconfigurable et permet
l’ajout, la suppression et la migration à la demande.
Le réseau virtuel PVC (Private Virtual Cluster) [15] est conçu pour éta-
blir dynamiquement des grappe virtuelles à travers les ressources connectées
à Internet. Un de ses objectifs est de permettre l’exécution d’applications
grappe, sans aucune modification. Les applications grappes utilisent en gé-
néral le modèle de socket comme interface de communication réseau, ce qui
explique l’utilisation de la couche IP comme domaine de virtualisation par
le réseau virtuel PVC.
Virtuoso VNET [14] est un simple réseau virtuel de couche 2 qui s’appuie
sur le VMM pour extraire et injecter les paquets Ethernet transmis par la
carte réseau virtuelle. Les mécanismes utilisés sont les filtres de paquets et
les sockets de paquets. VNET donne illusion à l’utilisateur qu’il est dans
son propre réseau local (Local Area Network). Virtuoso VNET utilise un
intergiciel nommé Virtuoso pour les machines virtuelles des grilles de calcul.
Cette architecture de réseau virtuel est reconfigurable et permet la migration
des machines virtuelles d’un nœud physique à un autre.
De même, SoftUDC VNET [13] permet aux domaines d’application et
d’administration de partager les mêmes ressources physiques en maintenant
la fonctionnalité d’isolation. La caractéristique principale de SoftUDC est
sa virtualisation au niveau des serveurs, des réseaux et des ressources de
stockage. La migration dans SoftUDC est possible mais elle n’est pas discutée
pour les réseaux étendus.
N2N (Network To Netwotk) [16] est un réseau privé virtuel pair à pair
de couche 2 complètement décentralisé. Les applications VPN existantes
peuvent utiliser N2N sans modification. La migration n’est pas discutée pour
cette architecture.
Le tableau 1 résume les caractéristiques des réseaux virtuels étudiés.

4.2 Classification des différents réseaux virtuels

Nous distinguons principalement deux types de réseaux virtuels, les ré-
seaux virtuels stables et les réseaux virtuels reconfigurables.

9
 Configuration Niveau d’application Migration
Violin Reconfigurable Overlay Migration à
(Niveau application) la demande
ViNe Reconfigurable Overlay Migration non
(Niveau IP) mentionnée
SoftUDC VNET Reconfigurable Ethernet Migration possible
mais pas discutée
pour les réseaux
étendus.
Virtuoso VNET Reconfigurable Couche 2 Migration possible
IPOP Reconfigurable Overlay (P2P) Migration possible
PVC Non reconfigurable IP Migration non
(stable) discutée
N2N Reconfigurable Couche 2 : Ethernet Migration non
discutée
OCALA Non mentionné Overlay Convergence Migration non
(OC) entre la couche discutée
réseau et la couche
transport.

Table 1 – Comparaison des réseaux virtuels étudiés

10
 Un réseau virtuel stable utilise les mêmes liens et les mêmes noeuds
pendant toute sa durée de vie, et donc sa topologie ne change pas. L’ad-
ministrateur d’un réseau virtuel stable doit réserver toutes les ressources
nécessaires pour effectuer ses tâches à la configuration initiale. Les réseaux
virtuels stables sont peu adaptés à la migration dynamique entre clouds car
ils nécessitent de prévoir l’architecture complète du réseau dès sa création.
En revanche, la topologie d’un réseau virtuel reconfigurable peut chan-
ger en fonction des ressources disponibles sur les infrastructures physiques
utilisées, afin d’améliorer les performances ou de réduire le coût d’utilisa-
tion. Les réseaux virtuels reconfigurables suscitent beaucoup d’intêrets car
ils permettent de résoudre les problèmes de migration inter-site cités dans la
section 3.

5 Prise en compte des schémas de communication

pour la migration d’applications distribuées
Une application distribuée est une application composée de plusieurs pro-
cessus communiquant entre eux et pouvant être distants géographiquement.
Les composants d’une application distribuée peuvent communiquer entre eux
à travers le passage des messages, par exemple en utilisant MPI (Message
Passing Interface), ou en utilisant d’autres mécanismes.
Les applications distribuées peuvent avoir des schémas de communica-
tion différents. Par exemple, dans l’application CG des NAS Parallel Bench-
marks [19], les nœuds forment des groupe de communication. Pour assurer de
bonnes performances, la migration inter-site de telles applications doit tenir
compte de ces schémas de communication. En effet, migrer sur deux clouds
différents des processus qui communiquent beaucoup entre eux pénaliserait
les performances.
Pour réaliser une migration tenant compte de ces schémas de commu-
nication, il serait possible d’analyser le trafic réseau des machines virtuelles
depuis l’hyperviseur. Ces informations sur le trafic nous permettraient de
détecter les groupes de communication éventuels formés par l’application
distribuée. Par exemple, pour l’application CG, il faudrait faire en sorte de
migrer uniquement des groupes de communication complets.

6 Conclusion
Dans cette étude, nous avons montré que la migration à chaud, permise
par l’utilisation de technologies de virtualisation dans les infrastructures de

11
type cloud computing, présentent un intérêt important. Nous nous sommes
intéressés aux avantages présentés par la migration à chaud de machines
virtuelles entre clouds.
Nous avons indiqué les problèmes importants qui se posent dans le contexte
de la migration à chaud entre réseaux physiques distincts. Ces problèmes se
rencontrent lors de la migration à chaud de machines virtuelles entre clouds et
provoquent la perte des communications en cours à cause de conflits d’adres-
sage ou de problèmes de routage.
Nous avons étudié les différents systèmes permettant de résoudre ces
problèmes réseaux. Ces systèmes permettent la création de réseaux virtuels,
en se fondant sur l’utilisation de réseaux overlay pair-à-pair.
Enfin, nous avons introduit la présence de schémas de communication
entre processus d’une application distribuée. Afin de garantir un bon niveau
de performances, ces schémas de communication doivent être pris en compte
lors de la migration à chaud de machines virtuelles.
Durant ce stage, nous nous intéresserons à la problématique de migration
à chaud de machine virtuelles entre différentes infrastructures de type cloud
computing, et plus précisément à la transparence des communications réseau.
Nous commencerons par tester les mises en œuvre de quelques solutions
existantes permettant de migrer une grappe virtuelle complète ou une sous-
partie d’une grappe d’un cloud à un autre sans perte de connectivité réseau
entre toutes les machines de la grappe. À partir de l’étude de ces solutions,
un prototype sera réalisé et évalué sur Grid’5000. Enfin, nous mettrons en
œuvre un système de migration dynamique de machines virtuelles respectant
les schémas de communication, qui sera validé avec le prototype réalisé.

Références
[1] James E. Smith and Ravi Nair. The architecture of virtual machines.
Computer, 38(5) :32–38, 2005.
[2] R. P. Goldberg. Architecture of virtual machines. In Proceedings of the
workshop on virtual computer systems, pages 74–112, New York, NY,
USA, 1973. ACM.
[3] Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris,
Alex Ho, Rolf Neugebauer, Ian Pratt, and Andrew Warfield. Xen and
the art of virtualization. In SOSP ’03 : Proceedings of the nineteenth
ACM symposium on Operating systems principles, pages 164–177, New
York, NY, USA, 2003. ACM.
[4] http ://www.vmware.com/.

12
 [5] Avi Kivity, Yaniv Kamay, Dor Laor, Uri Lublin, and Anthony Liguori.
kvm : the Linux Virtual Machine Monitor. In Proceedings of the 2007
Linux Symposium, volume 1, pages 225–230, June 2007.
[6] http ://www.virtualbox.org/.
[7] Christopher Clark, Keir Fraser, Steven Hand, Jacob Gorm Hansen, Eric
Jul, Christian Limpach, Ian Pratt, and Andrew Warfield. Live migration
of virtual machines. In NSDI’05 : Proceedings of the 2nd conference
on Symposium on Networked Systems Design & Implementation, pages
273–286, Berkeley, CA, USA, 2005. USENIX Association.
[8] Michael Nelson, Beng-Hong Lim, and Greg Hutchins. Fast transpa-
rent migration for virtual machines. In ATEC ’05 : Proceedings of the
annual conference on USENIX Annual Technical Conference, Berkeley,
CA, USA, 2005. USENIX Association.
[9] http ://www.frameip.com/vpn/.
[10] Jorge Carapinha and Javier Jiménez. Network virtualization : a view
from the bottom. In VISA ’09 : Proceedings of the 1st ACM workshop on
Virtualized infrastructure systems and architectures, pages 73–80, New
York, NY, USA, 2009. ACM.
[11] Xuxian Jiang Dongyan. Violin : Virtual internetworking on overlay
infrastructure, 2003.
[12] M. Tsugawa and J.A.B. Fortes. A virtual network (vine) architecture
for grid computing. Parallel and Distributed Processing Symposium,
International, 0 :123, 2006.
[13] Mahesh Kallahalla, Mustafa Uysal, Ram Swaminathan, David E. Lo-
well, Mike Wray, Tom Christian, Nigel Edwards, Chris I. Dalton, and
Frederic Gittler. Softudc : A software-based data center for utility com-
puting. Computer, 37(11) :38–46, 2004.
[14] Ananth I. Sundararaj, Ashish Gupta, and Peter A. Dinda. Dynamic to-
pology adaptation of virtual networks of virtual machines. In LCR ’04 :
Proceedings of the 7th workshop on Workshop on languages, compilers,
and run-time support for scalable systems, pages 1–8, New York, NY,
USA, 2004. ACM.
[15] Ala Rezmerita, Tangui Morlier, Vincent Néri, and Franck Cappello. Pri-
vate virtual cluster : Infrastructure and protocol for instant grids. In
Euro-Par 2006 Parallel Processing, pages 393–404, 2006.
[16] Luca Deri and Richard Andrews. N2n : A layer two peer-to-peer vpn.
In AIMS ’08 : Proceedings of the 2nd international conference on Auto-

13
 nomous Infrastructure, Management and Security, pages 53–64, Berlin,
Heidelberg, 2008. Springer-Verlag.
[17] Dilip Joseph, Jayanth Kannan, Ayumu Kubota, Karthik Lakshmina-
rayanan, Ion Stoica, and Klaus Wehrle. Ocala : An architecture for
supporting legacy applications over overlays. In In NSDI, 2006.
[18] David Isaac Wolinsky, Yonggang Liu, Pierre St. Juste, Girish Venkata-
subramanian, and Renato Figueiredo. On the design of scalable, self-
configuring virtual networks. In SC ’09 : Proceedings of the Confe-
rence on High Performance Computing Networking, Storage and Ana-
lysis, pages 1–12, New York, NY, USA, 2009. ACM.
[19] Rolf Riesen. Communication patterns [message-passing patterns].
In 20th International Parallel and Distributed Processing Symposium
(IPDPS 2006), 2006.

14