> Toutefois, le code le plus intéressant et le plus abouti concerne l'émulation de x86 sur x86 (32 ou 64bits).
> Il est dans ce cas possible d'utiliser un module kernel qui accélère grandement la vitesse d'émulation puisque le code n'est plus traduit, mais éxécuté directement sur le CPU hôte.
C'est KVM.
> -support des virtio-drivers
Encore du KVM, mais doit être utilisable par d'autres projets de virtualisation.
On obtient de très bonnes performances. Encore moins rapide que Xen, mais c'est récent.
Virtio prend en charge le réseau et les périphériques bloques (disques). D'autres éléments seront pris en compte afin d'offrir les performances de la paravirtualisation à la full virtualisation (KVM).
Notons que virtio peut être configuré avec libvirt ce qui est bien pratique : http://wiki.libvirt.org/page/Virtio
Je crois qu'il faut au moins un 2.6.25. Sur le host faire "modprobe virtio_net ; modprobe virtio_blk"
> Les virtio sont aussi disponibles sous windows sous forme de drivers
Que la partie guest, que pour le réseau et ce n'est pas open source.
M'enfin, ça va changer. Le support pour périphérique bloque a été développé (non encore diffusé) et Red Hat a promis de rendre virtio pour Windows libre (réseau et périphériques bloques). Je pense que ça sera fait lorsque Red Hat 5.4 sortira.
> Le but de qemu n'est pas d'avoir une architecture haute performance, ça c'est pour KVM
KVM est surtout côté noyau et bas-niveau. Qemu fournit à KVM l'environnement de la machine virtuel (le bios, l'énumération de périphérique, etc). C'est un élément important de la liaison avec le host.
Aujourd'hui KVM a besoin de Qemu. Théorique ce n'est pas indispensable, mais il coulera énormément d'eau sous les ponts avant que KVM puisse se passer de Qemu.
Bref, KVM (côté noyau) et Qemu forme un excellent couple. Il n'y a pas vraiment d'avantage à ce passer de Qemu même si théorique c'est possible.
> Le but de qemu est d'obtenir une plateforme de test la plus souple possible
Pas que test. RHEL abandonne Xen pour KVM/Qemu. Donc ça sera énormément utilisé en production. Aujourd'hui c'est Xen qui est le plus utilisé en production (et de loins), mais ça ne va pas durée très longtemps. On peut déjà trouver des hébergeurs pour KVM. Notons qu'il y a des développements récents pour entre KVM "compatible" avec Xen (par exemple par toujours un guest Xen sur un host KVM).
> il est même possible de tester qemu dans qemu (!!).
Depuis peu, on peut aussi avoir du KVM dans du KVM (c'est limité à certains CPU).
> Si vous cherchez à émuler une machine ayant un disque, une carte réseau et un écran, vous pouvez utiliser qemu, mais vous trouverez mieux ailleurs; en plus simple d'accès: virtualbox c'est tout graphique, yakacliker, et c'est relativement rapide.
Mouaif.
Ce qu'il faut voir avec Qemu, ce n'est pas que Qemu :-)
Il faut voir le tableau d'ensemble :
- Qemu : simule un PC (bios, périphériques, affichages, etc) et le relie au host. N'est pas clikodrome et ne veut pas l'être.
- KVM : virtualisation au niveau noyau pour d'excellent perfo quelque soit l'OS.
- libvirt : API de haut niveau de virtualisation pour utiliser KVM, Xen, OpenVZ, etc avec accès distant (et prise en compte de la sécurité)
- virt-manager : appli graphique utilisant libvirt pour un poste (l'équivalent graphique de virtualbox)
- ovirt pour les data-center : http://ovirt.org/
- etc
Et tout est 100 % libre ce qui n'est pas le cas de VirtualBox. VirtualBox a été très utilisé sous Linux car il marchait les doigts dans le nez pour un résultat très bon. Mais maintenant les briques Qemu, KVM, libvirt, virt-manager etc sont de mieux en mieux intégrées. Avec virtio les perfos sont excellentes. Le dernier "hic" est l'affichage. Mais Spice devrait bientôt être libéré. Ceci fera de Linux la rolls des solutions de virtualisation. OK, seulement la bmw pour certains.
# Qemu 0.10
Posté par IsNotGood . En réponse au journal qemu 0.10 is out \o/. Évalué à 3.
> Il est dans ce cas possible d'utiliser un module kernel qui accélère grandement la vitesse d'émulation puisque le code n'est plus traduit, mais éxécuté directement sur le CPU hôte.
C'est KVM.
> -support des virtio-drivers
Encore du KVM, mais doit être utilisable par d'autres projets de virtualisation.
On obtient de très bonnes performances. Encore moins rapide que Xen, mais c'est récent.
Virtio prend en charge le réseau et les périphériques bloques (disques). D'autres éléments seront pris en compte afin d'offrir les performances de la paravirtualisation à la full virtualisation (KVM).
Notons que virtio peut être configuré avec libvirt ce qui est bien pratique :
http://wiki.libvirt.org/page/Virtio
Je crois qu'il faut au moins un 2.6.25. Sur le host faire "modprobe virtio_net ; modprobe virtio_blk"
> Les virtio sont aussi disponibles sous windows sous forme de drivers
Que la partie guest, que pour le réseau et ce n'est pas open source.
M'enfin, ça va changer. Le support pour périphérique bloque a été développé (non encore diffusé) et Red Hat a promis de rendre virtio pour Windows libre (réseau et périphériques bloques). Je pense que ça sera fait lorsque Red Hat 5.4 sortira.
Beaucoup des avancées viennent de la branche KVM. C'est excellent de voir les projets fusionner.
C'était un des projets pour F11 :
https://fedoraproject.org/wiki/Features/KVM_and_QEMU_merge
> Le but de qemu n'est pas d'avoir une architecture haute performance, ça c'est pour KVM
KVM est surtout côté noyau et bas-niveau. Qemu fournit à KVM l'environnement de la machine virtuel (le bios, l'énumération de périphérique, etc). C'est un élément important de la liaison avec le host.
Aujourd'hui KVM a besoin de Qemu. Théorique ce n'est pas indispensable, mais il coulera énormément d'eau sous les ponts avant que KVM puisse se passer de Qemu.
Bref, KVM (côté noyau) et Qemu forme un excellent couple. Il n'y a pas vraiment d'avantage à ce passer de Qemu même si théorique c'est possible.
> Le but de qemu est d'obtenir une plateforme de test la plus souple possible
Pas que test. RHEL abandonne Xen pour KVM/Qemu. Donc ça sera énormément utilisé en production. Aujourd'hui c'est Xen qui est le plus utilisé en production (et de loins), mais ça ne va pas durée très longtemps. On peut déjà trouver des hébergeurs pour KVM. Notons qu'il y a des développements récents pour entre KVM "compatible" avec Xen (par exemple par toujours un guest Xen sur un host KVM).
> il est même possible de tester qemu dans qemu (!!).
Depuis peu, on peut aussi avoir du KVM dans du KVM (c'est limité à certains CPU).
> Si vous cherchez à émuler une machine ayant un disque, une carte réseau et un écran, vous pouvez utiliser qemu, mais vous trouverez mieux ailleurs; en plus simple d'accès: virtualbox c'est tout graphique, yakacliker, et c'est relativement rapide.
Mouaif.
Ce qu'il faut voir avec Qemu, ce n'est pas que Qemu :-)
Il faut voir le tableau d'ensemble :
- Qemu : simule un PC (bios, périphériques, affichages, etc) et le relie au host. N'est pas clikodrome et ne veut pas l'être.
- KVM : virtualisation au niveau noyau pour d'excellent perfo quelque soit l'OS.
- libvirt : API de haut niveau de virtualisation pour utiliser KVM, Xen, OpenVZ, etc avec accès distant (et prise en compte de la sécurité)
- virt-manager : appli graphique utilisant libvirt pour un poste (l'équivalent graphique de virtualbox)
- ovirt pour les data-center : http://ovirt.org/
- etc
Et tout est 100 % libre ce qui n'est pas le cas de VirtualBox. VirtualBox a été très utilisé sous Linux car il marchait les doigts dans le nez pour un résultat très bon. Mais maintenant les briques Qemu, KVM, libvirt, virt-manager etc sont de mieux en mieux intégrées. Avec virtio les perfos sont excellentes. Le dernier "hic" est l'affichage. Mais Spice devrait bientôt être libéré. Ceci fera de Linux la rolls des solutions de virtualisation. OK, seulement la bmw pour certains.
> KVM est intégralement basé dessus
Pas vraiment.