Utilisateur:Masquelier.th/MigrationVM

Une page de Wikipédia, l'encyclopédie libre.
Cette page est un brouillon appartenant à Masquelier.th
Conseils de rédaction
  • → N'hésitez pas à publier sur le brouillon un texte inachevé et à le modifier autant que vous le souhaitez.
  • → Pour enregistrer vos modifications au brouillon, il est nécessaire de cliquer sur le bouton bleu : « Publier les modifications ». Il n'y a pas d'enregistrement automatique.

Si votre but est de publier un nouvel article, votre brouillon doit respecter les points suivants :

  • Respectez le droit d'auteur en créant un texte spécialement pour Wikipédia en français (pas de copier-coller venu d'ailleurs).
  • Indiquez les éléments démontrant la notoriété du sujet (aide).
  • Liez chaque fait présenté à une source de qualité (quelles sources  – comment les insérer).
  • Utilisez un ton neutre, qui ne soit ni orienté ni publicitaire (aide).
  • Veillez également à structurer votre article, de manière à ce qu'il soit conforme aux autres pages de l'encyclopédie (structurer – mettre en page).
  • → Si ces points sont respectés, pour transformer votre brouillon en article, utilisez le bouton « publier le brouillon » en haut à droite. Votre brouillon sera alors transféré dans l'espace encyclopédique.
Migration VM

En virtualisation, la migration de machines virtuelles consiste à déplacer l'état d'une machine virtuelle, d'un hôte physique à un autre.

Il existe plusieurs raisons pour lesquelles il est nécessaire de migrer des systèmes d'exploitation, la plus importante étant l'équilibrage de la charge de travail sur les serveurs physiques. Il est également nécessaire de migrer des machines virtuelles lorsqu'un hôte physique est défectueux ou nécessite une maintenance.

Notions[modifier | modifier le code]

La virtualisation est devenue une étape obligatoire dans le développement des clusters[N 1] et du cloud computing[N 2]. Les clouds mettent à disposition des machines virtuelles fonctionnant sur un ou plusieurs hôtes donnant l'illusion à l'utilisateur qu'il dispose d'une certaine quantité de mémoire et de CPU. Les ressources matérielles deviennent des services pour les utilisateurs qui ne payent que pour les ressources qu'ils utilisent, ces ressources se doivent d'être disponibles à la demande. Cette flexibilité implique une nécessité de pouvoir migrer les machines virtuelles d'un hôte à un autre en fonction des ressources nécessaires et disponibles.[1]

Pouvoir migrer un système d'exploitation d'un hôte physique à un autre s'avère être quelque chose d'incontournable dans les data center et dans les clusters. Cela permet de délimiter clairement le hardware du software, de faciliter la gestion des pannes, de répartir de manière uniforme et automatique une charge de travail donnée et surtout de pouvoir organiser la maintenance des machines. Lorsqu'un hôte est surchargé et qu'il n'est plus capable de répondre à la demande, il est nécessaire de migrer l'état de la machine virtuelle vers un hôte plus puissant, ou moins surchargé, qui sera capable de prendre le relais. L'état de la machine virtuelle inclus la mémoire volatile et non-volatile, l'état des CPUs virtuels (VCPU), l'état des périphériques connectés ainsi que l'état des connexions actives.[2] [3]

Cependant la majorité des applications et des services reposant sur ces machines virtuelles ne peuvent pas subir d'arrêt conséquent. Il devient nécessaire de mettre en place des stratégies de migration différentes, en fonction des contrats de niveau de service établis avec les clients.[4]

Stratégies[modifier | modifier le code]

Migration à froid[modifier | modifier le code]

Cette stratégie est la plus basique, il est nécessaire de mettre la machine virtuelle hors tension afin de copier l'état de sa mémoire sur l'hôte cible. Elle est utilisée avec la stratégie de répartition de charge dynamique lorsque l'hôte reçoit plus de requêtes qu'il ne sait en gérer. La décision de migration se fait sur base d'un calcul des requêtes entrantes, de l'utilisation du processeur, des ressources disponibles sur l'hôte physique ainsi que de la consommation en énergie.[2] [5]

L'avantage principal de cette méthode est qu'elle n'impliquera aucune faute lors de la migration de la mémoire. La machine étant arrêtée, les services ne seront plus disponibles et la mémoire ne sera pas altérée sur l'hôte source. La machine une fois migrée pourra reprendre son activité dans le même état que lorsqu'elle s'est arrêtée.[6]

Elle comporte par contre un désavantage certain, à partir du moment où la machine est arrêtée, les services fonctionnant sous celle-ci ne seront plus disponibles durant toute la durée de la migration. Ce qui pose évidement des problèmes majeurs pour des applications nécessitant une haute disponibilité. De plus, la mémoire étant transférée entièrement sur l'hôte cible, la migration à froid provoque un ralentissement sur tout le réseau du cloud.[6]

Migration à chaud[modifier | modifier le code]

Article principal : Live Migration.

La migration à chaud est une stratégie utilisée pour palier aux problèmes de la migration à froid. Elle permet à un hyperviseur de transférer, au travers TCP, une machine virtuelle d'un hôte à un autre sans être obligé de l’arrêter.[7] [8]

Migration de VM à chaud par pré-copie
  • Etape 0 : Pre-migration : La machine virtuelle est active sur l'hôte source, durant cette étape l'hyperviseur est à la recherche d'un hôte de destination capable de gérer la machine à migrer.
  • Etape 1 : Reservation : L'hyperviseur se charge de réserver un conteneur sur l'hôte distant en lui envoyant une requête de réservation en y indiquant les ressources nécessaires à la machine virtuelle. Si la requête est acceptée par l'hôte cible, la phase de pré-copie peut démarrer.
  • Etape 2 : Pré-copie itérative : Durant cette phase, l'hyperviseur copie les pages de mémoire sur l'hôte distant via TCP. Lors de ce transfert, si une page de mémoire est modifiée sur l'hôte source, elle est marquée comme "sale". Cette étape est répétée, on ne copie plus que les pages qui ont été modifiées durant la pré-copie précédente. Le cycle s'arrête lorsqu'un nombre d'itérations maximum a été atteint (29 fois par défaut pour Xen) ou bien lorsque ce sont toujours les mêmes pages qui sont salies. En moyenne, l'hyperviseur Xen itère 9 fois avant de passer à l'étape suivante.
  • Etape 3 : Arrêt et copie : Lors de cette étape, la machine virtuelle est arrêtée sur l'hôte source et les pages sales restantes sont copiées sur l'hôte cible. C'est lors de cette étape que la machine virtuelle ne sera plus accessible. Elle ne sera active sur aucun hôte. Cette période est appelée downtime[N 3], c'est ce temps là qu'il est important de minimiser. [9]
  • Etape 4 : Validation : Lors de la validation, l'hôte de destination indique à l'hôte source qu'il a bien réceptionné toute l'image de la machine virtuelle. L'hôte source envoie un accusé de réception à l'hôte de destination et libère les ressources bloquées par la VM. L'hôte de destination est dorénavant l'hôte primaire.
  • Etape 5 : Activation : La machine virtuelle est activée sur l'hôte cible et la table de routage du switch est mise à jour. [7] [8] [10] [11] [12]

Cette implémentation de la migration en temps réel, présentée par Brandford[13], est implémentée par la plupart des hyperviseurs (Xen, VMWare, KVM). Elle a l'avantage d'être simple et de ne pas nécessiter d'inter-connexion rapide entre les hôtes.[8] [12] [14]

Il existe cependant d'autres stratégies de migration de la mémoire lors de migration à chaud.

Migration par internet[modifier | modifier le code]

La migration de machines virtuelles par internet est particulièrement utile dans le cadre des grilles informatiques, elle permet de reconfigurer une grille par migration sans pour autant en arrêter le service. Chaque ordinateur connecté à internet devient donc un hôte potentiel pour héberger une machine virtuelle.[15]

En virtualisation, la mémoire de la machine virtuelle étant généralement stockée sur un système partagé (Network File System[N 4]), il est nécessaire que la machine cible ait également accès à l'espace de stockage de la machine source.[15] [16]

Migration de la mémoire[modifier | modifier le code]

Migration de mémoire par pré-copie[modifier | modifier le code]

Phase d'échauffement[modifier | modifier le code]

Durant cette phase, l'hyperviseur copie toutes les pages mémoire de l'hôte source à l'hôte cible alors que la machine virtuelle est toujours opérationnelle. Si une ou plusieurs pages mémoire sont modifiées, elles seront recopiées d'un hôte à un autre durant la phase itérative suivante jusqu'au moment ou le taux de pages salies deviendra inférieur au taux de pages copiées.[17]

Phase d'arrêt et de copie[modifier | modifier le code]

C'est lors de cette phase que la machine virtuelle est arrêtée sur l'hôte source, l'état de la machine et les dernières pages sales sont copiées sur l'hôte cible et la machine virtuelle est re-démarrée sur celui-ci. C'est le downtime de la VM, il ne dure en général que quelques millisecondes, dépendant du nombre de pages restant à copier.[18] L'enjeu principal de la migration est donc de minimiser ce downtime afin de donner au maximum l'illusion que la machine ne s'est jamais arrêtée.[19]

La pré-copie a fait ses preuves pour les applications nécessitant beaucoup de lectures mémoire. Cependant, dans le cas d'applications qui écrivent sur la mémoire de manière intensive, cette approche de migration ne sera pas performante, dans les pires cas elle ne fonctionnera même pas.[20]

Migration de mémoire par post-copie[modifier | modifier le code]

Cette étape nécessite, dans un premier temps, l'arrêt du système sur l'hôte source. L'état du processeur est copié sur l'hôte cible et la machine est ensuite redémarrée sur l'hôte cible. Ensuite, les pages mémoire sont copiées à l'aide d'une combinaison de 4 techniques. La première demand-paging[N 5] permet à l'hôte cible de demander une page mémoire manquante à l'hôte source, cette méthode implique inévitablement un ralentissement du système de part la lenteur du réseau. Active-push permet à l'hôte source d'envoyer à la cible les pages mémoire fautives qui n'ont pas encore été demandées par l'hôte cible. Le pre-paging[N 6] est un système permettant à l'hôte source de prédire la prochaine page fautive sur l'hôte cible en fonction des défauts de page récents. Dynamic self balooning[21] permet quant à lui de réduire le nombre de transferts des pages non allouées. [22] [23]

En post-copie le downtime est moins long qu'en pré-copie étant donné que seul l'état du CPU et du matériel, soit quelques Ko, doivent être migrés durant cette inactivité. Le temps total de migration est court et déterministe étant donné que les pages ne sont pas salies sur l'hôte source durant la migration.[8]

La post-copie est plus optimisée pour les applications nécessitant beaucoup d'écritures en mémoire.[20]

Migration de mémoire par post-copie hybride[modifier | modifier le code]

En post-copie hybride, une seule phase de pré-copie est effectuée avant la phase de post-copie, de cette manière l'hôte cible dispose déjà de toute la mémoire, seules les pages sales devront être transférées en post-copie[8]. Pendant la copie des pages mémoire d'un hôte à un autre, la machine virtuelle continue de fonctionner sur l'hôte source. Une fois la copie effectuée, la machine virtuelle est stoppée, l'état du processeur et les pages modifiées sont copiées à leur tour sur la machine cible. La machine virtuelle est ensuite redémarrée sur l'hôte cible et la phase de post-copie commence. Ce système fonctionne bien pour les applications nécessitant un grand nombre de lectures mémoire, tout comme la migration par post-copie. Il fournit également un temps de migration déterministe pour les applications nécessitant un grand nombre d'écritures mémoire.[23] [24]

Stockage partagé[modifier | modifier le code]

La mémoire permanente, est dans la majorité des cas, associée à une mémoire partagée de type NAS et ne nécessite donc pas d'être déplacée.[3]

Problèmes et coûts liés à la migration[modifier | modifier le code]

Il est possible d'évaluer la migration à chaud à l'aide de quatre différentes mesures [8] [23]:

  1. Downtime
  2. Temps total de la migration
  3. Nombre de bytes total transférés
  4. Dégradation du service

Défauts de pages[modifier | modifier le code]

Lors de la migration de mémoire par pré-copie, plus les services écrivent sur la mémoire plus il y aura de défauts de pages. Ce nombre de défauts de page important impliquera par conséquent un downtime du système plus important.[24]

Pour ce type de service il est donc préférable d'utiliser la migration par post-copie, pour laquelle les défauts de page n'entrent pas en compte lors de l'arrêt de la machine virtuelle. La migration de mémoire par post-copie hybride reste un choix judicieux pour ce type de service.[8]

Conflits d’adressage[modifier | modifier le code]

La migration par internet permet de transférer l'environnement d'exécution des machines virtuelles d'un cloud à un autre. Ce type de migration peut engendrer des problématiques d'adressage liées au changement de réseaux.[25] [26]

Chaque VM localisée dans un cloud définit un état réseau qui inclus une adresse IP ainsi qu'une liste des connexions ouvertes. Lors d'une migration sur le même réseau, une mémoire partagée peut solutionner le problème d'adressage en y stockant l'état réseau en vue d'une restauration sur l'hôte cible. Cependant lors d'une migration au travers d'internet, il est fort probable que la machine cible n'ait pas accès à cette mémoire partagée.[27]

Lors d'une migration à chaud par Internet, il est nécessaire que le service soit maintenu. Cela implique que l'adresse IP publique de la VM reste la même. Il est également nécessaire que la migration n'interfère pas avec les protocoles de communication au niveau applicatif (TCP/UDP), ou avec la mémoire partagée.[26] [28]

Une des solutions à ces problèmes est d'utiliser un protocole d'IP mobile[29], permettant un déplacement d'un réseau d'IP vers un autre tout en gardant la même adresse IP ainsi que les connexions actives.

Une autre solution, proposée par Bradford[13], implique la résolution DNS. Lors de la migration, les VMs gardent leurs noms canoniques et la nouvelle adresse IP est enregistrée avec le nom du serveur. De cette manière la recherche d'une VM de part son nom canonique va permettre de résoudre la nouvelle adresse IP attribuée à la machine. La problématique de cette solution réside dans la gestion de ce changement d'IP au niveau applicatif.[26]

Cloudnet[30], utilise une combinaison de réseaux privés en couche réseau 3 (réseau privé virtuel) et de service privé LAN en couche réseau 2 (Virtual Private LAN Service) pour fournir un routage, multipoint-à-multipoint, au travers différents réseaux à l'aide de ponts LANs.[26]

Bibliograhpie[modifier | modifier le code]

  • (en) W. Voorsluys, J. Broberg, S. Venugopal et R. Buyya, « Cost of Virtual Machine Live Migration in Clouds: A Performance Evaluation », Cloud Computing, vol. 5931, no 9,‎ , p. 254- 265 (DOI 10.1007/978-3-642-10665-1_23)
  • (en) S. Akoush, R. Sohan, A. Rice, A.W. Moore et A. Hopper, « Predicting the Performance of Virtual Machine Migration », Modeling, Analysis & Simulation of Computer and Telecommunication Systems (MASCOTS), 2010 IEEE International Symposium on,‎ , p. 37 - 46 (ISSN 1526-7539, DOI 10.1109/MASCOTS.2010.13)
  • (en) M. Mishra, A. Das, P. Kulkarni et A. ahoo, « Dynamic resource management using virtual machine migrations », Communications Magazine, IEEE, vol. 50, no 9,‎ , p. 34 - 40 (ISSN 0163-6804, DOI 10.1109/MCOM.2012.6295709)
  • (en) C. Clark, Keir Fraser, Steven Hand, Jacob Gorm Hansen, Eric Jul, Christian Limpach, Ian Pratt et Andrew Warfield, « Live Migration of virtual machines », Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation, vol. 2,‎ , p. 273-286 (lire en ligne)
  • (en) Eric. Harney, Sebastien. Goasguen, Jim Martin, Mike Murphy et Mike Westall, « The efficacy of live virtual machine migrations over the internet », Proceedings of the 2nd international workshop on Virtualization technology in distributed computing, no 8,‎ , p. 34 - 40 (ISBN 978-1-59593-897-8, DOI 10.1145/1408654.1408662)
  • (en) Dave Stuti et Mehta Prashant, « Role of Virtual Machine Live Migration in Cloud Load Balancing », IOSR Journal of Computer Engineering, vol. 15, no 5,‎ , p. 69-72 (OCLC 5525734236)
  • (en) Qiang Huang, Fengqian Gao, Rui Wang et Zhengwei Qi, « Power Consumption of Virtual Machine Live Migration in Clouds », Communications and Mobile Computing (CMC), Third International Conference on,‎ , p. 122 - 125 (ISBN 978-1-61284-312-4, DOI 10.1109/CMC.2011.62)
  • (en) Rajkumar Buyya, James Broberg et Andrzej M. Goscinski, Cloud Computing: Principles and Paradigms, John Wiley & Sons, (ISBN 9781118002209, lire en ligne)
  • (en) Constantine P. Sapuntzakis, Ramesh Chandra, Ben Pfaff et Jim Chow, « Optimizing the Migration of Virtual Computers », SIGOPS Oper. Syst. Rev., vol. 36,‎ , p. 377–390 (ISSN 0163-5980, DOI 10.1145/844128.844163, lire en ligne, consulté le )
  • (en) Xiang Zhang, Zhigang Huo, Jie Ma et Dan Meng, « Exploiting Data Deduplication to Accelerate Live Virtual Machine Migration », Cluster Computing (CLUSTER), 2010 IEEE International Conference on,‎ , p. 88-96 (DOI 10.1109/CLUSTER.2010.17, lire en ligne, consulté le )
  • (en) K.Z. Ibrahim, S. Hofmeyr, C. Iancu et E. Roman, « Optimized pre-copy live migration for memory intensive applications », Proceedings of 2011 International Conference for High Performance Computing, Networking, Storage and Analysis,‎ , p. 1-11 (DOI 10.1145/2063384.2063437, lire en ligne, consulté le )
  • (en) Robert Bradford, Evangelos Kotsovinos, Anja Feldmann et Harald Schiöberg, « Live Wide-area Migration of Virtual Machines Including Local Persistent State », Proceedings of the 3rd international conference on Virtual execution environments, ACM, vEE '07,‎ , p. 169–179 (ISBN 978-1-59593-630-1, DOI 10.1145/1254810.1254834, lire en ligne, consulté le )
  • (en) Rajkumar Buyya, James Broberg et Andrzej M. Goscinski, Cloud Computing: Principles and Paradigms, John Wiley & Sons, (ISBN 9781118002209, lire en ligne)
  • (en) M. Kozuch et M. Satyanarayanan, « Internet suspend/resume », Mobile Computing Systems and Applications, 2002. Proceedings Fourth IEEE Workshop on,‎ , p. 40-46 (DOI 10.1109/MCSA.2002.1017484, lire en ligne, consulté le )
  • (en) Stuart Hacking et Benoît Hudzia, « Improving the Live Migration Process of Large Enterprise Applications », Proceedings of the 3rd international workshop on Virtualization technologies in distributed computing, ACM, vTDC '09,‎ , p. 51–58 (ISBN 978-1-60558-580-2, DOI 10.1145/1555336.1555346, lire en ligne, consulté le )
  • (en) F.F. Moghaddam et M. Cheriet, « Decreasing live virtual machine migration down-time using a memory page selection based on memory change PDF », Networking, Sensing and Control (ICNSC), 2010 International Conference on,‎ , p. 355-359 (DOI 10.1109/ICNSC.2010.5461517, lire en ligne, consulté le )
  • (en) A. B. M. Moniruzzaman, « Analysis of Memory Ballooning Technique for Dynamic Memory Management of Virtual Machines (VMs) », arXiv:1411.7344 [cs],‎ (lire en ligne, consulté le )
  • (en) Michael R. Hines, Umesh Deshpande et Kartik Gopalan, « Post-copy Live Migration of Virtual Machines », SIGOPS Oper. Syst. Rev., vol. 43,‎ , p. 14–26 (ISSN 0163-5980, DOI 10.1145/1618525.1618528, lire en ligne, consulté le )
  • (en) Michael R. Hines et Kartik Gopalan, « Post-copy Based Live Virtual Machine Migration Using Adaptive Pre-paging and Dynamic Self-ballooning », Proceedings of the 2009 ACM SIGPLAN/SIGOPS international conference on Virtual execution environments, ACM, vEE '09,‎ , p. 51–60 (ISBN 978-1-60558-375-4, DOI 10.1145/1508293.1508301, lire en ligne, consulté le )
  • (en) Timothy Wood, K. K. Ramakrishnan, Prashant Shenoy et Jacobus van der Merwe, « CloudNet: Dynamic Pooling of Cloud Resources by Live WAN Migration of Virtual Machines », Proceedings of the 7th ACM SIGPLAN/SIGOPS international conference on Virtual execution environments, ACM, vEE '11,‎ , p. 121–132 (ISBN 978-1-4503-0687-4, DOI 10.1145/1952682.1952699, lire en ligne, consulté le )
  • (en) S. Sahni et V. Varma, « A Hybrid Approach to Live Migration of Virtual Machines », Cloud Computing in Emerging Markets (CCEM), 2012 IEEE International Conference on,‎ , p. 1-5 (DOI 10.1109/CCEM.2012.6354587, lire en ligne, consulté le )
  • (en) Changyeon Jo, Erik Gustafsson, Jeongseok Son et Bernhard Egger, « Efficient Live Migration of Virtual Machines Using Shared Storage », Proceedings of the 9th ACM SIGPLAN/SIGOPS international conference on Virtual execution environments, ACM, vEE '13,‎ , p. 41–50 (ISBN 978-1-4503-1266-0, DOI 10.1145/2451512.2451524, lire en ligne, consulté le )
  • (en) S.A.R. Shah, A.H. Jaikar et Seo-Young Noh, « A performance analysis of precopy, postcopy and hybrid live VM migration algorithms in scientific cloud computing environment », High Performance Computing & Simulation (HPCS), 2015 International Conference on,‎ , p. 229-236 (DOI 10.1109/HPCSim.2015.7237044, lire en ligne, consulté le )
  • (en) A. Beloglazov et R. Buyya, « Energy Efficient Allocation of Virtual Machines in Cloud Data Centers », Cluster, Cloud and Grid Computing (CCGrid), 2010 10th IEEE/ACM International Conference on,‎ , p. 577-578 (DOI 10.1109/CCGRID.2010.45, lire en ligne, consulté le )
  • Djawida Dib, Migration dynamique d'applications réparties virtualisées dans les fédérations d'infrastructures distribuées, (lire en ligne)
Wikipedia

Vous êtes ici sur la page personnelle d’un utilisateur de Wikipédia en français.
Cette page ne fait pas partie de l’espace encyclopédique de Wikipédia.

Si vous avez accédé à cette page depuis un autre site que celui de Wikipédia en français, c’est que vous êtes sur un site miroir ou un site qui fait de la réutilisation de contenu. Cette page n’est peut-être pas à jour et l’utilisateur identifié n’a probablement aucune affiliation avec le site sur lequel vous vous trouvez. L’original de cette page se trouve à l'adresse suivante : https://fr.wikipedia.org/wiki/Utilisateur:Masquelier.th/MigrationVM.

Notes et références[modifier | modifier le code]

Notes[modifier | modifier le code]

  1. ↑ Grappe de serveurs
  2. ↑ Informatique en nuage
  3. ↑ Taux d'indisponibilité
  4. ↑ Système de fichiers en réseau
  5. ↑ Demande de pagination
  6. ↑ Pré-pagination

Références[modifier | modifier le code]

  1. ↑ Mishra 2010, p. 34
  2. ↑ a et b Stuti 2013, p. 70
  3. ↑ a et b Jo 2013, p. ?
  4. ↑ Voorsluys 2012, p. 254
  5. ↑ (en) « Xen migration », sur http://wiki.prgmr.com/
  6. ↑ a et b Stuti 2013, p. 71
  7. ↑ a et b Rajkumar 2010, p. chapter5
  8. ↑ a b c d e f et g Shribman 2012, p. 540
  9. ↑ Ibrahim 2011, p. 2
  10. ↑ « Chapter 9: Xen Migration - PrgmrWiki », sur wiki.prgmr.com (consulté le )
  11. ↑ « Windows server 2012 & Hyper-V 3 : Live Migration », sur http://alexnogard.com/
  12. ↑ a et b (en) « KVM Migration », sur www.linux-kvm.org
  13. ↑ a et b Bradford 2007
  14. ↑ Clark 2005, p. 37
  15. ↑ a et b Kozuch 2002, p. ?
  16. ↑ Harney 2007, p. 37
  17. ↑ Hacking 2009, p. 53
  18. ↑ (en) Live Migration Stop-and-copy phase
  19. ↑ Moghaddam 2010, p. 355
  20. ↑ a et b Sahni 2012, p. 2
  21. ↑ Moniruzzaman 2014, p. 2
  22. ↑ Hines 2009, p. 17
  23. ↑ a b et c Hines 2009, p. 53
  24. ↑ a et b Shah 2015, p. 231
  25. ↑ Djawida 2010, p. 7
  26. ↑ a b c et d Mishra 2012, p. 39
  27. ↑ Mishra 2012, p. 39
  28. ↑ Harney 2007, p. 2
  29. ↑ Valkó 1999, p. ?
  30. ↑ Wood 2011, p. ?
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Utilisateur:Masquelier.th/MigrationVM&oldid=162723584 ».