Cher nourjal,
qemu 0.10 is out!
Qemu est un logiciel permettant de faire de la virtualisation, sujet à la mode. L'avantage de qemu réside surtout dans sa transparence. Les OS invités n'ont nullement besoin d'être adaptés pour pouvoir fonctionner.
Qemu travaille dans le domaine de l'émulation, ce qui permet depuis un CPU x86 d'éxecuter du code MIPS par exemple. Vous pouvez par exemple utiliser debian-mips depuis votre PC. Qemu s'occupe de traduire au vol toutes les instructions pour les éxecuter.
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.
Qemu est un projet qui avance tout doucement (les releases sont éloignées dans le temps) mais qui progresse énormément.
Que peux t'on en dire aujourd'hui?
Il permet d'émuler une très grande variété de machines, et de tester sans problème tout type d'OS (une très grande variété de boot sont possibles, disque, CD, net).
Qemu traînait depuis longtemps deux casseroles:
La version 0.9.1 compilait uniquement avec gcc 3, et il était relativement lent (dû essentiellement à la traduction au vol de toutes les instructions).
La version 0.10 supporte gcc 4 (et un énorme travail a été réalisé pour réussir à s'affranchif de gcc3), et le module kqemu est vraiment plus rapide (à la louche je dirais entre 10 et 20% de gain).
Les autres améliorations sont les suivantes:
-support de KVM (pour des perfs canons, mais nécessite un CPU adapté)
-support de la live migration (je n'ai pas testé, mais ça à l'air sympathique)
-support du PCI hotplug (pour ajouter à chaud une carte son, deux disques, et sept cartes réseaux)
-support du bluetooth (pour tester, ou bien utiliser la carte du système hôte)
-support des virtio-drivers (pour des meilleurs perfs encore une fois. Les virtio sont aussi disponibles sous windows sous forme de drivers)
et pas mal de bugfixes et autres améliorations.
Les autres versions proposaient:
-support de l'USB (émulé ou accès au bus de l'hôte)
-support de plusieurs types de cartes réseaux, graphiques, sons
-support des snapshots (pour pouvoir revenir en arrière dans la machine émulée)
-accès distant aux machines émulées: VNC, réseau only, ou déport d'affichage
-support du port série et/ou parrallèle (un boot en port série par exemple)
-émulation SMP (même sur un hôte monoCPU)
-pleins d'autres petits trucs hyper pratiques, indiqués dans le site web
Enfin, je livre mon avis personnel:
Le but de qemu n'est pas d'avoir une architecture haute performance, ça c'est pour KVM et les outils qui gravitent autour (libvirt, frontends, etc..).
Le but de qemu est d'obtenir une plateforme de test la plus souple possible, et la plus proche de la réalité physique. C'est réussi, il est possible de tester tout et n'importe quoi; il est même possible de tester qemu dans qemu (!!).
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.
Si vous n'avez pas peur de la ligne de commande, et pour tester une machine avec 18 disques (pour tester du RAID 6+1) avec 4 cartes réseaux (pour tester du bonding), pour débugger le noyau (on peut utiliser gdb, et même dumper les registres du CPU), pour valider une solution dans des cas aux limites, alors qemu est fait pour vous et vous allez bénéficier de sa puissance.
Je vous invite à tester et utiliser cette release, le site web a changé, il faut aller sur:
http://www.nongnu.org/qemu
Preuve de la qualité de ce logiciel, on retrouve son nom dans a peu près tous les autres produits de virtualisation:
virtualbox a copié du code (pour booter les machines), Xen s'en inspire (la partie périphérique virtuel et I/O), KVM est intégralement basé dessus, etc..
Qemu c'est bon, mangez en!
Journal qemu 0.10 is out \o/
8
mar.
2009
# Qemu 0.10
Posté par IsNotGood . É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.
[^] # Re: Qemu 0.10
Posté par Olivier Tétard (site web personnel) . Évalué à 5.
>
> C'est KVM.
Je pense qu'il parlait plutôt de KQemu, voir en:kqemu.
Olivier;
[^] # Re: Qemu 0.10
Posté par IsNotGood . Évalué à 1.
[^] # Re: Qemu 0.10
Posté par herodiade . Évalué à 10.
> Je pense qu'il parlait plutôt de KQemu, voir en:kqemu.
Ce qui est sûr, c'est que l'essentiel du code de kvm en espace utilisateur (qui était de fait un fork de qemu) a été mergé, et qu'il est prévu de merger tout le reste au fur et à mesure. Les drivers virtio aussi ont été mergés d'ailleurs. Pour ce que j'en comprends, KVM (le logiciel userland) est censé devenir, à moyen terme, une simple branche "staging" des fonctionnalités destinés à atterir dans le qemu upstream.
Les patchs de Gerd Hoffmann amenant l'implémentation du support/émulation d'un dom0, et permettant de gérer des domU depuis qemu n'ont pas encore été mergés en revanche (les types de Xen on fait un peu de resistance, on les comprends, et on réussi à délayer l'intégration en réclamant du temps pour la relecture depuis des mois).
Quant à kqemu, il n'est désormais plus « l'accélérateur officiel » de qemu visiblement ; le mainteneur actuel de qemu ne veux pas appliquer les patchs sur ce module, et recommande aux personnes intéressées de forker.
En vrac, quelques autres nouveautés de cette release pas cités dans la dépêche ni dans le changelog (il y a eu énormément de changement entre la 0.9 et cette release, et un regain d'activité *énorme* autour du projet) :
- Le support de VDE (les virtual ethernet switchs)
- Le support du balooning (offrant la possibilité d'augmenter/réduire dynamiquement à chaud la mémoire dispo pour un guest donné).
- Le support de NBD, permettant de monter les images qcow2 (ou autre) sur l'ordi hote.
- Le support de la peste pulseaudio
- Les drivers virtio (paravirtualisation), en particulier ethernet et block, offrant d'excellentes performances
- Le support de l'IPv6
- L'option -vga (qemu -vga std, "-vga cirrus", "-vga vmware")
- Une interface curse
- Plein d'amélioration autour du support VNC : la possibilité d'avoir plusieurs clients vnc sur un même guest, de l'utiliser en même temps que le SDL, l'authentification par SASL, le support du SSL, le support de la compression tight, ...
- L'émulation en userpace marche maintenant sur les BSD (au moins OpenBSD)
- Le SCSI passtrough (comme pour l'USB, permet à un guest d'accéder directement à un périphérique physique de l'hote)
# Et pour les corrections de bug ?
Posté par Mr Kapouik (site web personnel) . Évalué à 2.
Sinon aussi les drivers réseau font souvent des erreurs ce qui peut provoquer des comportement étrange lors de gros transfert.
Voilà les deux bug récurant qui me gène vraiment encore dans qemu que j'utilise pourtant régulièrement.
[^] # Re: Et pour les corrections de bug ?
Posté par octane . Évalué à 1.
As usual dans le logiciel libre, tu prends ton éditeur de texte favori, tu corriges le code et tu soumets ;)
Blague à part, pour l'ACPI il y a du nouveau et de la finesse de configuration:
-acpitable [sig=str][,rev=n][,oem_id=str][,oem_table_id=str][,oem_rev=n][,asl_compiler_id=str][,asl_compiler_rev=n][,data=file1[:file2]...]
ACPI table description
Pour les drivers réseaux, je crois me souvenir que sous openBSD il ne faut pas utiliser le modèle de carte réseau par défaut. Tu auras sans doute plus de chance avec le e1000:
-net nic[,vlan=n][,macaddr=addr][,model=type][,name=str]
create a new Network Interface Card and connect it to VLAN 'n'
$ qemu /dev/null -net nic,model=?
Warning: vlan 0 is not connected to host network
qemu: Supported NIC models: ne2k_pci,i82551,i82557b,i82559er,rtl8139,e1000,pcnet,virtio
Ceci dit, jamais eu aucun problème de driver mais je suis sous linux en guest et en host.
# C'est quoi la différence finalement????
Posté par NickNolte . Évalué à 2.
KVM se suffit-il a lui même pour faire de la virtualisation?
KVM c'est comme QEMU excépté qu'il nécessite un CPU doté de jeux d'instructions adéquats?
Quel intérêt d'utiliser QEMU avec le support KVM si c'est pour avoir KVM au final?
Ce sont des outils que j'utilise souvent mais je n'arrive toujours pas à savoir dans cette nébuleuse qui est à l'origine de quoi!
[^] # Re: C'est quoi la différence finalement????
Posté par herodiade . Évalué à 5.
- Une module noyau pour Linux gérant l'accélération de la virtualisation
- Un fork amical et temporaire de Qemu exploitant ce module
Maintenant "KVM" devient :
- Un module noyau, toujours
- Un des "accelerator" possibles dans Qemu (avec tcg (le natif / non assisté par le noyau), kqemu, peut-être bientôt Xen, ou, qui sait, peut-être un jour l'"accelerator" de virtualbox ?)
- La branche "expérimentale" de Qemu concernant les modifications relatives à la virtualisation, et destinées à être mergées après cleanup et tests
> Quel intérêt d'utiliser QEMU avec le support KVM si c'est pour avoir KVM au final?
En gros que KVM devient la branche "bleeding edge" de la partie de qemu exploitant le module KVM de Linux. Donc dans un cas, tu aura moins de risques de bugs, dans l'autre les fonctionnalités en avant première.
[^] # Re: C'est quoi la différence finalement????
Posté par NickNolte . Évalué à -5.
Il aurait été plus judicieux de renomer le module/pilote afin de le distinguer du backend.
Encore une inéptie du libre...
# virtualbox
Posté par geb . Évalué à 4.
Je fais pas vraiment parti de ceux qui "ont peur de la ligne de commande" mais j'ai du mal à etre du même avis: virtualbox est bien pratique mais avec son interface pleine de fioritures on perd pas mal de temps à tout configurer:
Combien de clics et kilometres parcourus à la souris pour tester une simple image iso par exemple (quand il suffit de taper qemu -cdrom fichier.iso ) ?
D'autant que pour ce qui est du reseau, des qu'on sort du mode standard (pseudo nat), il faut tout faire sois même (exemple: constuire un bridge).
Bref, virtualbox a du bon, mais de la à le presenter comme le concurent ergonomique de qemu, bof :)
[^] # Re: virtualbox
Posté par Aefron . Évalué à 3.
... avec VirtualBox OSE, ce n'est pas plus rapide (ou alors, ce n'est pas sensible, dans mon cas), j'ai des problèmes avec les quotas OpenVZ (ils s'épuisent trop vite), je n'ai pas le support USB (pourtant super pratique, pour tester, puis stocker mes scripts de déploiement de serveurs - avec qemulator, je peux même partager les périphs que je veux en mode click-click) et il arrive bien souvent que les images précédentes deviennent illisibles à la moindre mise à jour de VirtualBox OSE...
Après, je veux bien reconnaître que VirtualBox OSE fonctionne bien depuis plus longtemps (notamment sur les machines sans instructions de virtualisation), et que ses icônes animées pour l'activité réseau/disque/... sont sympas... mais en dehors de ça, je n'ai trouvé que des avantages à qemulator+KVM.
[^] # Re: virtualbox
Posté par Fabien . Évalué à 1.
J'utilise actuellement virtualbox pour virtualiser un OS sale mais me permettant de créer une connexion IPSEC avec des OpenBSD (afin d'utiliser des interfaces web bourrées d'ActiveX, pas le choix).
Je suis rentré de vacances il y a quelques jours, et virtualbox sur sid ne démarre plus à cause d'un souci de compatibilité de virtualbox et du module kernel (je n'ai pas intérêt à jouer avec mon kernel, j'utilise un laptop avec chiffrement complet - /boot sur clef usb).
Ceci est peut être dû au passage à Lenny (Sid étant mis en retrait pour l'instant), mais du coup j'ai du mal à utiliser mon VPN.
L'un des avantages de vbox est aussi d'être disponible sur plusieurs OS et donc de pouvoir partager les images mais en réalité, d'obscures problèmes sont apparus lorsque j'ai voulu faire tourner des images linux grsecurity sur du windows.
Tout ceci et cette article/discussion me donne envie de passer à qemu avec un mode clickodrome. N'ayant pas envie de comparer (pour l'instant) les diverses interfaces, l'idéal serait de pouvoir switcher entre elles et virer vbox.
[^] # Re: virtualbox
Posté par Aefron . Évalué à 2.
Si on configure des machines virtuelles de la même manière dans qemulator et virt-manager, je ne vois pas de raison pour qu'il y ait un problème particulier selon qu'on bootera une image disque avec l'un, ou l'autre.
[^] # Re: virtualbox
Posté par NickNolte . Évalué à 2.
Le man/doc n'était pas très claire à ce sujet.
Mais après avoir compris son fonctionnement, sa logique en fait, ben c'est comme tout une fois qu'on connait, ça roule tout seul, mais ça aurait pu être beaucoup plus simple.
Mais cela passer, déployer des machines à l'aide de scripts est d'une facilité déconcertante pour un sysadmin.
Et quant à Qemulator, ce dernier est vraiment laid et rustique face à un Virtualbox/VMWare, donc une raison de plus de se passer de GUI.
[^] # Re: virtualbox
Posté par Aefron . Évalué à 2.
Et c'est pareil sous VirtualBox, si on veut un réseau un peu évolué... là, en effet, il y a à faire à la main (à quand les bridges et cie sous NM :p ?).
> quant à Qemulator, ce dernier est vraiment laid et rustique face à un Virtualbox/VMWare
Laid, d'accord (je ne connais pas VMWare, mais bon, gtk vs Qt... no comment)... par contre, rustique ? Qemulator me paraît plus puissant que VirtualBox OSE (gestion de l'USB, notamment).
Sans compter les problèmes avec VirtualBox (cassage de compatibilité des images entre les versions, comportements bizarres dès qu'on touche à des fonctions un peu bizarres sur les noyaux émulés, ...)... non, quand je dois émuler des choses sur ma station de travail (comme l'ensemble de mes serveurs, quand je teste des modifs), un petit qemulator, ça me le fait nickel. VirtualBox, ça fait bien depuis KVM que je n'y touche plus...
[^] # Re: virtualbox
Posté par Larry Cow . Évalué à 3.
Tu peux éventuellement regarder du côté de AQemu, alors.
# Emuler un autre systeme présent sur le disque dur ...
Posté par Calve . Évalué à 1.
Je profite du journal pour poser cette question : quelle est la solution la mieux adapté pour émuler le Vista installé a coté de l'Ubuntu sur le pc de ma copine ?
J'ai cru comprendre que VirtualBox le fesait, mais ca avait l'air d'etre expérimental.
Donc si quelqu'un peut m'orienter ....
Bonne soirée :)
[^] # Re: Emuler un autre systeme présent sur le disque dur ...
Posté par B16F4RV4RD1N . Évalué à 3.
J'avais essayé avec xp, cela fonctionnait pas trop mal, avec vista je ne sais pas si c'est possible.
Et je ne vois pas d'option dans virtualbox pour faire cela.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Emuler un autre systeme présent sur le disque dur ...
Posté par claudex . Évalué à 3.
D'après ce que j'avais lu (je ne suis plus sûr que ce soit sur dans la doc), il faut passer des options en ligne de commande car ce n'est pas possible actuellement avec l'interface graphique.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Emuler un autre systeme présent sur le disque dur ...
Posté par IsNotGood . Évalué à 2.
Actuellement la résolution de l'affichage est faible avec KVM/qemu. Le mieux est de se connecter en rdp à l'instance virtuelle et utiliser rdesktop depuis Linux.
[^] # Re: Emuler un autre systeme présent sur le disque dur ...
Posté par slubman (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Emuler un autre systeme présent sur le disque dur ...
Posté par Fabimaru (site web personnel) . Évalué à 2.
[^] # Re: Emuler un autre systeme présent sur le disque dur ...
Posté par slubman (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Emuler un autre systeme présent sur le disque dur ...
Posté par benoar . Évalué à 2.
[^] # Re: Emuler un autre systeme présent sur le disque dur ...
Posté par ndesmoul . Évalué à 0.
# Ouinnn
Posté par Sylvain Sauvage . Évalué à 4.
Sondage : êtes-vous frustrés par ces logiciels qui, bien que parfaitement fonctionnels et stables, n’atteignent jamais la fatidique 1.0 ?
[^] # Re: Ouinnn
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Ouinnn
Posté par IsNotGood . Évalué à 2.
Non.
[^] # Re: Ouinnn
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Exemple : la dernière debian, .NET3...
[^] # Re: Ouinnn
Posté par Xavier Teyssier (site web personnel) . Évalué à 1.
Après 0.9, j'attends soit 1.0, soit 0.91, mais certainement pas 0.10, qui ne devrait venir qu'après 0.0 ou 0.09...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.