Cher lecteurs,
avec tout ce qu'il se profile à l'horizon concernant la virtualisation sous Linux je me suis dit qu'un point semblait opportun.
Tout d'abord Xen:
La version 3.4.1 étant sortie il y a peu, force est de constater que cet hyperviseur est en pleine phase de transition concernant le Dom0. A l'heure actuelle pas moins de 5 candidats s'offrent à nous pour ce domaine privilégié (Lien 1).
Sur ces 5 seul l'ancestral 2.6.18 est pleinement fonctionnel à ce jour. Tous les efforts se portent néanmoins sur l'architecture pvops pour la prochaine version 3.5 (cf. page suscitée). Malheureusement, il semble que l'inclusion dans la branche principale du kernel Linux soit deja abandonnée pour le 2.6.32 et que les espoirs se fondent maintenant sur la version 2.6.33, dixit le wiki de Fedora (Lien 2).
Sachant que l'initiative XCI (Xen Client Initiative, une distribution bare-metal pour le desktop) utilise un Dom0 à base de noyau 2.6.27 modifié, accompagné d'outils de contrôle nouveaux ( RIP xend et anciens fichiers de configuration, Lien 3) et que Cloud Xen est encore bien mystérieux (Lien 4), il apparait que cette solution a besoin à l'heure actuelle d'un peu de temps afin de retrouver une cohésion de premier ordre.
KVM:
De son côté, le rejeton de Qumranet, nouvellement sous l'égide Red Hat, évolue lui aussi de façon impressionante. Il est maintenant pourvu de KSM (Kernel SamePage Merging) permettant de fusionner au niveau de l'hôte les pages mémoire identiques des invités, améliorant de cette façon le nombre potentiel de machine virtuelles pouvant tourner sur une machine physique. A ceci viennent s'ajouter le support des HugePages (affligé néanmoins de désavantages), le branchement/débranchement à chaud d'interfaces réseau, des améliorations de performances substantielles pour le format de disque qcow2 avec le cache d'écriture désactivé et l'arrivée d'une ABI invité stable entre les versions ( plus de réactivation Windows en perspective ). Tout ceci est consultable sur le Lien 2. Ensuite, après le nested SVM (instructions de virtualisation AMD), vient à son tour le nested VMX (instructions de virtualisation Intel) ( Lien 5 ). Non encore totalement implémentée, cette fonctionnalité très intérressante en environnement de test, consistant à pouvoir virtualiser les extensions de virtualisation elles-même dans les invités et permettant de ce fait de simuler une ferme d'hôtes, ne sera plus reservée aux possesseurs de processeurs AMD. Enfin, et cette fois concernant les invités Windows, Red Hat a libéré ses drivers para-virtualisés de réseau et de stockage, promettant une amélioration visible des performances pour les machines virtuelles tournant sous l'OS de la firme de Redmond ( Lien 6 ).
Spice:
Suivant les deux excellents journaux d'IsNotGood (Liens 7 et 8), le protocole de bureau distant SPICE se pose indéniablement comme composant majeur de l'infrastructure virtualisée. Grandement attendu de la communauté, les informations le concernant restaient malheureusement rares et éparses, surtout depuis que toute trace de son existance a disparue du wiki de Fedora (Lien 9). Après quelques recherches je suis finalement tombé sur une présentation de Arnon Gilboa provenant du Red Hat summit 2009 nommée 'SPICE: An Open Remote Computing Solution' (Lien 10) et quelle présentation! Celle-ci explique en détail l'architecture de cette solution, son état actuel ainsi que son développement futur. Succintement, SPICE, comme vu plus haut, est un protocole crée spécialement pour les bureaux virtualisés distants. Il concurrence de ce fait directement les ténors actuels comme RDP, ICA et NX. Il dispose de plus d'avantages de taille. En effet il tire tout d'abord parti du GPU client pour le rendement, libérant le CPU de cette tâche. Il distribue de même dynamiquement les calculs entre le serveur et le client suivant la puissance et les possibilités de ce dernier. Il supporte le chiffrement des flux, le multi-écran distant, la video HD et les flux audio bi-directionnels (il est possible d'écouter de la musique tout en s'enregistrant par exemple). La 3D est en prépartion ainsi que le partage d'imprimante, le partage de périphérique générique et bien d'autres choses. Tout ceci est accessible aussi bien pour les systèmes Linux que Windows. Un site lui étant dédié va d'ailleurs bientôt être mis en place ( Lien 11 ). La présentation ne contenant pas de déclaration claire quand à sa libération, j'ai pris la liberté de le demander à son auteur. Voici la partie pertinente de sa réponse:
...
Spice is soon to be completely open-sourced (we are Red Hat).
...
Le doute n'est donc plus de mise, SPICE va bientôt rejoindre les rangs du libre!
Openvswitch/OpenFlow:
Changeons à présent de paysage pour nous concentrer sur la virtualisation du réseau. Citrix a, comme convenu, mis à disposition de la communauté le résultat de ses travaux à propos de son switch virtuel, nommé openvswitch ( Lien 12 ). Celui-ci supporte NetFlow, le SPAN, le RSPAN (permettant une visibilité quant aux communications inter-VMs) ainsi que les VLAN avec trunking (possibilité d'assigner simplement plusieurs VLAN à une même interface), les polices de contrôle par machine virtuelle, le bonding avec load-balancing et un mode de compatibilité avec brctl. Beaucoup d'autre fonctionnalités sont en phase d'implémentation. Etant à l'heure actuelle en finalisation, il ne possède pas encore de release officielle ( seul le dépôt git est disponible ). Cela ne devrait plus tarder. Bien que très complet, il ne prétend pas concurrencer à lui seul le Nexus 1000v de Cisco, mais plutôt le vswitch de Vmware. Ce n'est qu'en collaboration avec OpenFlow, standard visant en simplifiant à addresser la communication inter-switch (Lien 13) qu'il devient réellement distribué et permettra une virtualisation complète de l'infrastructure réseau (migration des règles entre vswitchs parrallèlement à la migration d'une machine virtuelle, administration centralisée, ...).
Libvirt:
Cette bibliothèque et démon de contrôle de machines virtuelles (Lien 14) supporte désormais les hôtes de type ESX et OpenNebula ( en sus des habitués KVM, LXC, OpenVZ, Xen, VirtualBox et UML). Elle permet de ce fait d'administrer ces différentes solutions de manière totalement homogène. Utilisée par un nombre important de projets, elle peut se targuer d'un aspect sécuritaire avancé au travers de l'initiative Svirt (Lien 15) ainsi que de son utilisation en profondeur de la bibliothèque libcap-ng (bibliothèque permettant de facilement tirer parti des capacités POSIX) et de son support de PolicyKit. Elle permet en outre de gérer le stockage ( NFS, iSCSI, USB, fibre, LVM, ...) et la configuration des interfaces via netcf (Lien 17). Elle peut enfin être gérée à distance à l'aide de son propre protocole, de QMF ( protocole d'administration applicatif basé sur AMQP, Lien 18) ou de CIM. Celle-ci vient juste de sortir en version 0.7.1 et va subir une grande restructuration de ses sources afin de pouvoir continuer sur des bases plus saines.
Ovirt:
Version libre de RHEV-M (outil d'administration d'infrastructure virtuelle, Lien 19), cette solution est pour ainsi dire le vSphere du libre. Elle comprend une image système minimale dédiée à la gestion des hôtes ( du type ESXi ) ainsi que d'un éco-système logiciel complet pour la gestion de son infrastructure virtuelle. Ce dernier se compose de FreeIPA (Lien 20), solution d'authentification centralisée comparable à AD, de cobbler (Lien 21) pour le provisionning, de collectd (Lien 22) pour le monitoring et les statistiques et d'une interface web d'administration complète rassemblant gestion habituelle et cloud. Cette dernière est réalisée en rails et innove en étant très dynamique car basée fortement sur la recherche (critères infinis avec un pseudo language SQL). Le mode maintenance, permettant en un clic de migrer automatiquement toutes les machines virtuelle d'un hôte afin de procéder à une quelconque opération apparait de même très pratique. Je vous invite à ce titre à regarder une démonstration de son pendant commercial (Lien 23). Cette solution supporte enfin le clustering, le load-balancing et possède des API externes afin de pouvoir contrôler programmaticalement tout ceci.
Libguestfs:
Petite dédicace rapide à cette bibliothèque (Lien 24) extrêmement pratique permettant d'accéder, depuis l'hôte, aux images disques des machines virtuelles (actuellement qcow, qcow2 et vmdk) de la même façon qu'en local ( l'image sera tout simplement montée dans l'arborescence) et ce au travers de divers languages de programmation ainsi qu'avec son shell dédié, guestfish. Tous les types de partions supportés par le noyau Linux le sont aussi par Libguestfs. Il est dorénavent possible d'accéder à tout fichier précis, cloner des machines virtuelles, etc très simplement.
A l'issue de ce petit tour d'horizon il est clair que le libre est en totale ébullition concernant la virtualisation, qu'elle soit système ou réseau. Cela avance très vite. Les solutions présentées ici sont toutes 'entreprise ready' ou en passe de le devenir rapidement. Les prochain mois vont être à mon avis plus qu'intéressants!
Lien 1 : [http://wiki.xensource.com/xenwiki/XenDom0Kernels]
Lien 2 : [http://fedoraproject.org/wiki/Documentation_Virtualization_B(...)]
Lien 3 : http://www.mail-archive.com/libvir-list@redhat.com/msg16027.(...)
Lien 4 : [http://www.xen.org/products/cloud_source.html]
Lien 5 : [http://avikivity.blogspot.com/2009/09/nested-vmx-support-com(...)]
Lien 6 : [http://www.linux-kvm.org/page/WindowsGuestDrivers]
Lien 7 : [http://linuxfr.org/~IsNotGood/27880.html]
Lien 8 : [http://linuxfr.org/~IsNotGood/28502.html]
Lien 9 : [http://fedoraproject.org/wiki/Qumranet#SPICE.2FSolidICE]
Lien 10 : [http://www.redhat.com/f/pdf/summit/agilboa_11_spice.pdf]
Lien 11 : [http://www.spice-space.org]
Lien 12 : [http://openvswitch.org/]
Lien 13 : [http://www.openflowswitch.org/]
Lien 14 : [http://libvirt.org/]
Lien 15 : [http://selinuxproject.org/page/SVirt]
Lien 16 : [http://freshmeat.net/projects/libcap-ng]
Lien 17 : [https://fedorahosted.org/netcf/]
Lien 18 : [http://qpid.apache.org/qmf-protocol.html]
Lien 19 : [http://ovirt.org]
Lien 20 : [http://freeipa.org/]
Lien 21 : [https://fedorahosted.org/cobbler/]
Lien 22 : [http://collectd.org/]
Lien 23 : [http://www.youtube.com/watch?v=_wY1NxM3Yc4&feature=player_em(...)]
Lien 24 : [http://libguestfs.org/]
Journal Un petit tour sur le paysage de la virtualisation Linux
17
sept.
2009
# Dépêche
Posté par Boa Treize (site web personnel) . Évalué à 10.
[^] # Re: Dépêche
Posté par Obsider . Évalué à 9.
[^] # Re: Dépêche
Posté par CrEv (site web personnel) . Évalué à 3.
(petite note perso : par contre, change un poil de style, aère un peu le texte et, mais c'est possible aussi dans les journaux hein, je trouve qu'il est toujours intéressant d'avoir les liens dans le texte et non en pas, au pire placer des ancres pour y sauter)
Perso je viens de réinstaller un serveur, comme j'avais (un peu seulement) utilisé xen j'ai voulu le remttre. Mais il n'a pas bien marché, je pense en partie à cause du 2.6.18 et de mon matos.
C'est un _énorme_ frein au développement de xen je trouve, et rien que pour ça je pense que je ne l'utiliserai plus.
Je suis donc passé sur kvm, et je dois dire que j'ai été impressionné par la facilité de mise en oeuvre (avec libvirt également), facilité à mon avis en partie due à son intégration au noyau.
D'ailleurs s'il y a encore relativement peu de temps kvm manquait de fonctionnalité, je pense que son intégration ne peut que renforcer l'ajout rapide de ce qui lui fait défaut.
Et pour ça c'est très bien.
(D'ailleurs, en lisant les contes de patrick_g - et autres - sur l'appli de perf de Molnar, {C|B}FS, etc on se rend compte que les outils simples, bien intégrés réussissent une fois intégrés en mainline car cela leur offre une visibilité très importante. Et grace à cela en général ils dépassent assez vite les solutions initialement moins performantes.
[^] # Re: Dépêche
Posté par Obsider . Évalué à 2.
Pareil pour moi j'ai abandonné Xen car ça devenait vraiment galère rien que pour s'y retrouver ( je ne parle même pas d'arriver à faire marcher un Dom0 récent...).
Et puis bon vu que je suis un fan-boy AMD la nested virtualization c'est 'top moumoute' pour les tests et ça c'est exclusivité KVM.
# Proxmox
Posté par Larry Cow . Évalué à 3.
[^] # Re: Proxmox
Posté par Obsider . Évalué à 1.
Je l'ai testé et c'est vraiment bien fait. Le seul truc qui me gêne en fait est que tu est obligé d'avoir l'interface web installée sur chaque noeud.
Mais pour qui débute ou n'a pas besoin de dizaines de machines il n'y a pas photo c'est un prétendant béton!
[^] # Re: Proxmox
Posté par Larry Cow . Évalué à 2.
# Du très très bon
Posté par mornik . Évalué à 4.
Il est difficile d'avoir une synthèse sur l'état des solutions de virtualisation, et celle-ci est vraiment interressante (comprendre simple (enfin presque parfois), facile à lire et très synthétique).
Encore merci car je cherchais ces informations.
# openvz
Posté par thomas . Évalué à 1.
merci pour cet article de très bonne facture.
Tu n'as pas parlé de OpenVZ. Quand est-il de ce genre de virtualisation (containers) ? venant du monde Solaris j'ai pas mal utilisé les containers/zones, ce genre de virtualisation me parait avoir sa place a côté des hyperviseurs comme kvm.... il semble cependant que cette solution a moins d'écho dans le monde linux, non ? pourquoi ?
- tav
[^] # Re: openvz
Posté par Obsider . Évalué à 2.
Les seuls problèmes que je vois sont que 1) il n'est pas dans la branche principale du noyau et de ce fait les versions de prod se cantonnent à l'heure actuelle au 2.6.18 et 2.6.24 ( pour proxmox ) et que 2) il y a en fait une solution de conteneur intégrée au kernel linux ( LXC http://lxc.sourceforge.net/ ). Elle est d'ailleurs codée en grande partie par l'équipe d'OpenVZ. Sauf que là niveau doc c'est assez pauvre et les possibilités sont moindre qu'avec OpenVZ.
De plus, à part pour le mutu et parce qu'il existe des solutions complètes (Parallels virtuozzo surtout qui est la version payante de OpenVZ), pas mal de gens ne captent pas la différence entre conteneurs et virtualisation totale et ne voient pas l'intérêt des conteneurs.
[^] # Re: openvz
Posté par mathgl . Évalué à 1.
J'avais bien aimé OpenVZ. La gestion est facile et ça permet un bon cloisonnement en utilisant peu de ressource comparer à de la virtualisation (Je ne considère pas OpenVZ comme une solution de virtualisation). Par contre, quand je mis était penché, j’avais trouvé le support de l'IPv6 pas terrible. Je me suis rapidement retrouver avec des problèmes qui m'ont poussé à abandonner l'IPv6 sur le serveur. (Est-ce ma faute? celle de Free? ou OpenVZ ?)
# Merci
Posté par Skunnyk (site web personnel) . Évalué à 1.
L'openswitch peut être pas mal si il a des fonctionnalité avancée par rapport au vswitch distributed "basique" de vSphere4 (parce que le nexus1000V à ~1000€/ESX est un peu cher ;-))
Et plus généralement, superbe journal qui vaut effectivement une dépêche !
# Spice
Posté par bubar🦥 (Mastodon) . Évalué à 4.
Spice a vraiment de plus en plus l'air absolument incroyable (dans le sens fa-bu-leux :p )
il tire tout d'abord parti du GPU client pour le rendement, libérant le CPU de cette tâche. Il distribue de même dynamiquement les calculs entre le serveur et le client suivant la puissance et les possibilités de ce dernier. Il supporte le chiffrement des flux, le multi-écran distant, la video HD et les flux audio bi-directionnels
Les flux audio bi-directionnels, tout seul, comme un grand \o/ c'est énorme.
Les informations sur Spice sont frugales en effet, même la page sur Emerging Technologies n'est qu'une redirection sur la page d'accueil du fameux site : http://spice.et.redhat.com/page/Main_Page Rien n'est dévoilé directement sur Spice ici ! (bon c'est peut être là qu'on aura les premières infos autres que press-release bientôt)
Bref il faut se rabattre sur http://www.qumranet.com/ et leurs press-releases, ainsi que sur les quelques vidéos disponibles sur les blogs spécialisés virtualisation. en parcourant quelques blogs de ce type, le seul reproche que j'ai pû lire à l'égard de Spice est du type "lourd sur le réseau"... logique, non ? On va pas faire du Spice avec une ligne adsl... (quoique...)
C'est vraiment encore un coup de maître pour Redhat. Cette techno va mettre une grosse claque, c'est très clair.
[^] # Re: Spice
Posté par Obsider . Évalué à 3.
C'est vrai que je suis tombé vraiment par hasard sur le pdf de présentation. C'est le premier document qui ne soit pas purement marketing d'ailleurs...
Par contre si tu regarde dans le doc il y a une diapositive intitulée 'Compression video' ( grande classe encore une fois, il detecte tout seul les flux video et les encode dynamiquement en M-JPEG ) et il y a justement un point où ils disent que ça permet d'économiser pas mal de traffic, surtout pour une configuration WAN, donc quoique peut-être bien en fait.
[^] # Re: Spice
Posté par e-t172 (site web personnel) . Évalué à 4.
J'utilise NX quasiment tous les jours. L'énorme intérêt de NX est justement de pouvoir accéder à son environement de travail de n'importe où, y compris sur des connexions pourries.
Exemple récent : utiliser NX sur une connexion mobile 3G avec 1 mbit de bande passante et surtout 150 ms de latence. C'était tout à fait utilisable et j'ai pu vraiment bosser avec. De là à dire que c'était "agréable" je n'irais pas jusque là, mais en même temps, on peut pas tout avoir...
Si t'as besoin d'une connexion haut débit voire très haut débit pour utiliser Spice, il perd tout son intérêt à mes yeux. Choisir entre la vidéo HD/l'audio bidirectionnel et pouvoir accéder à mon bureau en tout-terrain, mon choix est vite fait. Peut-être que Spice n'est en fait que pour les "clients légers" utilisés en entreprise et sur réseau local...
# Enfin quelqu'un qui relève le niveau ....
Posté par totof2000 . Évalué à 6.
[^] # Re: Enfin quelqu'un qui relève le niveau ....
Posté par fearan . Évalué à 6.
* Des journaux de bronsonisation,
* un début de troll avec le retour de Dark Polo & Winner,
* une polémique sur MS et son prix de licence, avec en prime PbPg qui intervient lui même,
* une ressussé d'IPOT,
* des journaux parlant d'Hadopi
*On a même un journal parlant d'un émulateur NES écrit en js, sans que personne ne lance un troll sur l'inutilité du bazar
Bref, les journaux sont toujours égaux à eux même...
PS: ah oui j'oubliais un journal qui aurait sa place dans les dépêches
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Enfin quelqu'un qui relève le niveau ....
Posté par zebra3 . Évalué à 6.
Presque, on a Zenitram qui l'a lancé sur l'utilité des smartphones. Heureusement qu'il est là.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Enfin quelqu'un qui relève le niveau ....
Posté par Laurent Cligny (site web personnel) . Évalué à 2.
[^] # Re: Enfin quelqu'un qui relève le niveau ....
Posté par totof2000 . Évalué à 2.
# Encore un journal pour mettre des liens
Posté par octane . Évalué à 1.
Ceci dit, pour monter des images disques j'utilise qemu-nbd.
Ca fonctionne très bien avec tous les formats supportés par qemu.
Il n'y a pas de liens vers qemu, c'est dommage, c'est vraiment une super solution de virtualisation pour le cloisonnement, tout ça.
Pour spice, ça a l'air super intéressant, effectivement.
Xen, j'ai complètement abandonné. Comme tu le dis, c'est fouilli, c'est compliqué, c'est le bronx de partout.
KVM, par contre, faut que je m'y remette.
Enfin, je conseille toujours lguest, c'est ce que j'utilise actuellement. C'est loin d'être aussi complet que les autres solutions de virtualisation, mais pour ce que je fais (test de pleins de trucs gruik en console sous linux) ça me convient très bien.
# VirtualBox
Posté par ecyrbe . Évalué à 4.
VirtualBox : pratique pour virtualiser un desktop PC, il a l'avantage d'être facile à paramétrer et à utiliser pour l'utilisateur final. Les dernières versions font état du support d'openGL directement sur la machine embarqué.
[^] # Re: VirtualBox
Posté par CrEv (site web personnel) . Évalué à 2.
En gros, VirtualBox c'est bien pour faire de l'émulation de poste temporaire, si possible en utilisant le proc au mieux, mais j'en ferais pas un serveur de vm virtualisées au contraire des produits précédents.
[^] # Re: VirtualBox
Posté par briaeros007 . Évalué à 3.
Ben techniquement, avec virtualbox, tu peux lancer tes serveurs directement sur un export RDP. Ca a l'air tout con, mais un moment j'aurais bien aimé avoir sur les vm au boulot.
Esx par exemple ne le permet pas et oblige à passer par son vmware infrastructure client.
(si je dis ça, c'est juste qu'au boulot on a des esx et chez moi j'utilise virtualbox :P).
bon ensuite j'ai pas (encore) testé les autres solutions aussi :P
# petit tuto Lenny xen/drbd/clvm/rgmanager/cman
Posté par denisb . Évalué à 1.
http://wwdeb.crdp.ac-caen.fr/mediase3/index.php/Cluster_Xen
En fait j'étais parti sur XEN car j'avais trouvé des docs décrivant assez bien ce que je voulais faire ! Je serais curieux de savoir si quelqu'un a déjà fait la même chose avec KVM, je n'ai pas trouvé de docs claires sur l'interaction de DRBD/CLVM avec type de virtualisation.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.