# [qemu || kvm || virtualbox] conseils divers

## DuF

Bonsoir,

J'ai 2 questions, voici la première :

1. Je souhaite compiler Virtualbox-ose mais il refuse car j'utilise gcc-4.3. Je me suis dit que j'allais faire un emerge de la version 4.2 directement par la commande :

```
emerge /usr/portage/sys-devel/gcc/gcc-4.2.4-r1.ebuild
```

Et là je me suis dit, il y a peut être plus propre, donc pose la question sur le forum au cas où. Mais l'idée étant que je ferai un coup de gcc-config le temps de la compilation de virtualbox et zou. Donc voilà, c'est seulement au cas ou il y aurait une meilleure solution.

2. Concernant VirtualBox-ose, j'aimerai savoir si certains connaissent d'autres solutions libres et celles qui mériteraient d'être de tester. Pour information je ne fais ça que pour ma curiosité personnelle. En effet, au boulot j'ai une Opensuse 64 bits avec virtualbox qui fait tourner un windows pour seulement 2 applications.... Mais comme c'est pour le boulot, je ne me permets pas de jouer avec car cela doit être opérationnel tous les jours. Or j'aimerai bien faire des tests et creuser un peu plus loin le sujet. Donc, les personnes qui ont déjà une pratique avancée (autre que de la simple utilisation clic-clic comme moi) je suis preneur de toute l'expérience que vous jugerez utile de m'indiquer, concernant virtualbox ou toute autre solution similaire.

Merci

DuFLast edited by DuF on Sun Nov 01, 2009 9:34 pm; edited 2 times in total

----------

## novazur

Salut,

Personnellement, je préfère prendre une version de virtualbox qui compile avec mon gcc :

```
$ grep virtualbox /etc/portage/package.keywords

# virtualbox

=app-emulation/virtualbox-ose-2.2.2 ~amd64

=app-emulation/virtualbox-modules-2.2.2 ~amd64

=app-emulation/virtualbox-ose-additions-2.2.2 ~amd64
```

Quant à ton expérimentation, je te suggère de commencer à faire mumuse avec virtualbox que tu connais un peu, et qui me semble tenir le haut du pavé. Moi, je suis passé derrière à openvz, par curiosité aussi, et par besoin futur éventuel. Ce n'est pas la même chose, mais c'est sympa aussi à explorer.

----------

## man in the hill

Salut

Récupère la dernière version de virtualbox sur leur site qui te propose le support usb en plus et facile à installer ... Virtualbox est vraiment top pour moi et très stable .

@+

----------

## ppg

Il y a bien Qemu mais la dernière fois que j'ai testé remonte à au moins 2 ans, donc ça a du bien s'améliorer depuis. Sinon Virtualbox ose c'est vraiment top, ça fonctionne vraiment bien sur pas mal d'OS différents.

----------

## kwenspc

virtualbox c'est basé... sur qemu. Le seul problème (à mon sens) étant qu'ils fournissent certains trucs non-libres (support usb à eux etc... il me semble.).

Sinon, je vais me répéter, mais qemu + un frontend (comme qemu-launcher et il yen a tout plein d'autres) ça pète. Si votre CPU possède les jeux d'instructions VT-x pour intel et SVM pour AMD je vous conseille vivement d'utiliser kvm. Avec ça votre VM tournera à une vitesse CPU native, sans parler des virtIO pour les cartes réseaux et les disques (le reste étant toujours "émulé": la CG, etc...).

Au pire il vous reste le module kqemu (qui est 100% libre oui).

Qemu est 100% libre et est à la base de quasi toutes les solutions de virtualisation sous Linux (à part openVZ, qui d'ailleurs ne concours pas du tout dans le même concept technique, ce n'est pas de la véritable virtualisation hardware.)

Le seul défaut de qemu c'est son site web qui est tout sauf vendeur, aux vues des prouesses techniques qu'il embarque.

Faut pas se leurrer hein, qemu/kvm c'est LA solution de choix pour la virtualisation, il est en train d'écraser tout. Xen par exemple est totalement à la ramasse amha (pas tant au niveau perf qu'au niveau de la simplicité d'utilisation). C'est bien simple, la compétition actuelle n'est plus entre les différentes solutions libres (ou plus ou moins) vs vmware mais seulement qemu/kvm vs vmware. C'est pas pour rien que les distros majeurs comme RedHat (qui maintient kvm maintenant) et bouhbountou sont passés à qemu/kvm.

Voilà, je me suis encore répéter pour la énième fois.

[edit]

Tiens Duf, pour un vieux routard Gentoo comme toi je m'étonne que tu nous postes un truc pareil: 

 *Quote:*   

> 
> 
> ```
> emerge /usr/portage/sys-devel/gcc/gcc-4.2.4-r1.ebuild
> ```
> ...

 

 :Wink: 

il y a plus simple: 

```

echo =sys-devel/gcc-4.2.4-r1 >> /etc/portage/package.keywords

emerge =sys-devel/gcc-4.2.4-r1

```

C'est tout de suite plus propre. (En ensuite oui gcc-config pour switcher entre versions)

[/edit]

----------

## DuF

 *kwenspc wrote:*   

> virtualbox c'est basé... sur qemu. Le seul problème (à mon sens) étant qu'ils fournissent certains trucs non-libres (support usb à eux etc... il me semble.).
> 
> Sinon, je vais me répéter, mais qemu + un frontend (comme qemu-launcher et il yen a tout plein d'autres) ça pète. Si votre CPU possède les jeux d'instructions VT-x pour intel et SVM pour AMD je vous conseille vivement d'utiliser kvm. Avec ça votre VM tournera à une vitesse CPU native, sans parler des virtIO pour les cartes réseaux et les disques (le reste étant toujours "émulé": la CG, etc...).
> 
> Au pire il vous reste le module kqemu (qui est 100% libre oui).
> ...

 

Bon je crois que j'ai bien saisi le message (je ne pensais pas que j'allais réveiller autant de passions)  :Smile: 

Je m'en vais donc tester le couple qemu/kvm, cela m'a l'air intérêssant ou devrais-je dire tu m'as fortement convaincu ! Merci pour tous ces éléments et ce petit historique qui me permet d'y voir fortement plus clair.

 *kwenspc wrote:*   

> 
> 
> [edit]
> 
> Tiens Duf, pour un vieux routard Gentoo comme toi je m'étonne que tu nous postes un truc pareil: 
> ...

 

Je ne veux pas dire que vous êtes tous de vieux barbus qui passent 24h/24 sur leur ordi (vu que je suis barbu c'est mal venu) mais en fait moi si j'utilise linux et particulièrement gentoo, c'est pour en faire le moins possible   :Laughing:  Au début ça n'était pas forcément le cas je l'avoue, mais aujourd'hui ça l'est fortement   :Very Happy: 

En effet, avant que je change de matos, mon installation avait 7 ans, rarement de prises de têtes, quand je veux un truc, ça fonctionne, en gros je suis un utilisateur qui en fait le moins possible.

Mais là, avec le core 2 Quad que je viens de me prendre, j'aimerai bien répondre à ma curiosité à la fois sur des sujets comme la virtualisation mais aussi tester des trucs sexy comme ZFS sous OpenSolaris. Et cela tombe bien, je peux faire ce dernier point avec de la virtualisation sans abîmer ma chouette gentoo ! Donc merci pour la solution "propre" d'emerge de paquets antérieur.

----------

## kwenspc

avec un core2quad en principe tous les modèles (sauf les 8xxx il me semble) ont les jeux d'instructions VT-x, fais toi plaiz!

----------

## DuF

 *kwenspc wrote:*   

> avec un core2quad en principe tous les modèles (sauf les 8xxx il me semble) ont les jeux d'instructions VT-x, fais toi plaiz!

 

Ca tombe bien c'est un Q9550s donc ça devrait le faire. 

Sinon rien à voir, est-ce qu'il y a un FS compatible avec la GPL du noyau linux qui projette d'avoir des fonctions sexy comme ZFS a (je pense notamment au TimeSlidder) ?

Cdt,

----------

## kwenspc

 *DuF wrote:*   

> 
> 
> Sinon rien à voir, est-ce qu'il y a un FS compatible avec la GPL du noyau linux qui projette d'avoir des fonctions sexy comme ZFS a (je pense notamment au TimeSlidder) ?
> 
> 

 

BRTFS il me semble. Après je sais pas si il y a exactement cette fonctionnalité TimeSlidder, peut-être au travers des snapshots?

----------

## ppg

xfs ?

Il est également possible d'utiliser ZFS sous linux, mais c'est beaucoup plus compliqué que sur OpenSolaris car le code source de ZFS n'étant pas compatible GPL donc non intégrable dans le noyau, il faut passer par fuse.

----------

## DuF

Pour ZFS je vais me contenter d'OpenSolaris en virtualisation (cela aura l'avantage de tester les outils qui vont bien avec ainsi que de pouvoir dégager le tout facilement une fois les tests finis) et je ne suis pas fan de ce qui tourne en user space pour éviter la contrainte du noyau en GPL  :Smile: 

Mais bon, je me posais la question de savoir si un FS "linux GPL friendly" était en préparation avec le même genre de nouveautés.

----------

## man in the hill

J'utilise xen et virtualbox pour deux contextes bien précis , l'un pour tout ce qui est serveur ( pas besoin de graphique ou de pilote performant) et l'autre en desktop avec un pilote graphique et souris qui rox . DuF donne tes impressions de qemu/kvm et peut être un tuto rapide si possible car ça m'interesse ... Je m'y metterais très bientôt de toute façon ...

----------

## DuF

Alors pour l'instant je n'ai pas fait grand chose et cela manque de recul pour toutes les questions se rapprochant de la "pérennité" de ce type de solution mais d'ores et déjà j'ai 2 impressions qui se dégagent : 

- Virtualbox c'est quand même cool pour le côté "user friendly" de la GUI

- le couple qemu + kvm semble plus rapide avec mon core2quad 9550s pour une même iso que j'utiliserai sous virtualbox (qui pourtant utilise qemu).

Par contre j'ai du me louper quelque part avec qemu + kvm car pour l'instant je n'arrive pas à faire tourner d'image du type sparc+solaris (peut être une limitation de kvm, j'avoue je n'ai que partiellement parcourue la documention).

Sinon autre limitation, j'ai échoué à utiliser virtio avec kvm (pourtant j'ai vérifié que les versions de noyaux linux hotes et invités étaient supérieures à 2.6.25, mais bon je retesterai cela plus tard  :Smile:  ).

----------

## kwenspc

 *DuF wrote:*   

> 
> 
> - Virtualbox c'est quand même cool pour le côté "user friendly" de la GUI
> 
> - le couple qemu + kvm semble plus rapide avec mon core2quad 9550s pour une même iso que j'utiliserai sous virtualbox (qui pourtant utilise qemu).
> ...

 

Pour le côté GUI il faut regarder du côté des front-end. perso j'utilise qemu-launcher (y a un ebuild sur le bugzilla, suffit de le renommer en 1.7.4 au lieu de 1.7.1 pour avoir la dernière version).

Sinon oui qemu/kvm c'est définitivement le plus rapide  :Wink: 

Alors pour sparc/solaris c'est tout à fait normal: KVM sert à utiliser le CPU natif de l'hôte. KVM se limite donc aux architecture de ton CPU donc: x86_32 et x86_64. Pour l'archi SPARC y a pas de miracle: aucune virtualisation possible, c'est impossible. Tout sera donc émulé. 

Ah sinon, je vous conseille d'installer app-emulation/qemu en instable. Un ptit 

```
echo app-emulation/qemu >> /etc/portage/package.keywords
```

  et hop!

Le dernière version de qemu (0.10.4 pour le moment) intègre tout le support nécessaire. Plus besoin de qemu-user et qemu-softmmu ni de kvm en stand-alone. Là tout est inclus en un paquet.Last edited by kwenspc on Sun Jun 14, 2009 1:55 pm; edited 1 time in total

----------

## DuF

Je suis en train de tester qemu comme tu l'as indiqué et effectivement, il y a une nette différence de "vitesse" comparé à Virtualbox. J'utilise vitesse car pour l'instant c'est le seul élément de performance que j'ai perçu, mais je débute dans l'utilisation donc bon.

Par contre j'ai beaucoup plus de mal à obtenir quelque chose de stable  :Smile:  En effet, là où virtualbox réalise un ensemble de paramètrage à la place de l'utilisateur, avec qemu il faut un minimum de connaissances.

Ce qui m'amène à ma question, est-ce qu'en dehors de la documenation officielle tu aurais des documentations à préconiser ?

Cdt,

----------

## kwenspc

 *DuF wrote:*   

> 
> 
> Ce qui m'amène à ma question, est-ce qu'en dehors de la documenation officielle tu aurais des documentations à préconiser ?
> 
> 

 

Pas vraiment. J'utilise qemu pour lancer des vm win (au taf, softs proprios de dev qui tourne seulement sur cet O$ oblige...), les paramètres de bases suffisent. (j'utilise même pas -std-vga ni -no-acpi). Bon après je passe par du nic pour le réseau plutôt qu'un device tap bridgé, vu que j'ai pas besoin de grand chose côté réseau dans mes VM. Je dois dire que qemu-launcher est mon front-end, je ne passe plus par la ligne de commande (pas l'occasion en fait, j'ai bossé avec pendant ~1 an sur des serveurs de developpement, pour avoir des vm à la volée. jamais eu de soucis mais elles faisaient tourner nux.

Mais quelle instabilité rencontres-tu? Et à quel niveau exactement? (son, image, usb, cdrom?)

----------

## DuF

Quand je parle d'instalabilité, je parle de trucs du genre : 

Je prends une ISO d'un liveCD d'une distribution linux ou bsd ou autre, je démarre dessus, fais l'installation dans la VM, quand je redémarre je ne peux pas booter sur l'OS nouvellement installé. Je dois enlever l'image ISO indiquée comme cdrom pour démarrer directement sur l'image de la VM installée. Grosso modo, si je boote sur un liveCD pour lui dire de démarrer le disque local, cela plante.

Rien de méchant, mais c'est étonnant tout de même.

Par contre je reviens un peu sur mes premiers commentaires, il va falloir que j'affine un peu ma manière d'utiliser qemu, car si je compare à Virtualbox, il y a des cas où c'est fortement plus rapide et d'autres où c'est plus lent.

Enfin bon ce ne sont que des tentatives à droite à gauche pas forcément très représentatives.

D'ailleurs si je prends le dernier exemple con que je viens de tester, l'installation du Mandriva sous virtualbox et qemu, bah l'image liveCD est bien plus rapide sous qemu, par contre "l'installation sur disque" au sein de la VM donc est bien plus rapide sous virtualbox, comme si les accès disques étaient très fortement optimisés. Donc voilà, je regarde un peu les documentations car je me doute qu'il doit bien y avoir quelque chose qui cloche dans la configuration par défaut.

----------

## kwenspc

 *DuF wrote:*   

> D'ailleurs si je prends le dernier exemple con que je viens de tester, l'installation du Mandriva sous virtualbox et qemu, bah l'image liveCD est bien plus rapide sous qemu, par contre "l'installation sur disque" au sein de la VM donc est bien plus rapide sous virtualbox, comme si les accès disques étaient très fortement optimisés. Donc voilà, je regarde un peu les documentations car je me doute qu'il doit bien y avoir quelque chose qui cloche dans la configuration par défaut.

 

Ouais virtualbox introduit des optimisation du type... virtio   :Wink:   Donc il faut vraiment que tu puisses utiliser ces virtio, tu verras ça change. 

Sinon pour le reboot à partir du livecd, tu peux essayer le bios bosch pour voir.  Fin j'ai jamais eu à me soucier de ça (en même temps, après l'install via un livecd, il faut en principe sortir le livecd du lecteur)

----------

## DuF

 *kwenspc wrote:*   

> 
> 
> Ouais virtualbox introduit des optimisation du type... virtio    Donc il faut vraiment que tu puisses utiliser ces virtio, tu verras ça change. 

 

Effectivement pour virtio j'étais déjà tombé dessus sur la page wikipédia (qui au passage est bien foutu pour s'imprégner des différentes technologies et des périmètres de chaque élément. D'ailleurs la je regarde virtio mais aussi kqemu.

 *kwenspc wrote:*   

> Sinon pour le reboot à partir du livecd, tu peux essayer le bios bosch pour voir.  Fin j'ai jamais eu à me soucier de ça (en même temps, après l'install via un livecd, il faut en principe sortir le livecd du lecteur)

 

Effectivement, en général on enlève le liveCD, mais là après l'installation comme on fait le redémarrage, j'ai laissé le liveCD démarré et demandé un boot sur disque local, cela évitait de stopper la VM pour la relancer sans le cdrom. Comme quoi des fois, des choses bêtes ne sont pas forcément les plus prévisibles  :Smile: 

----------

## kwenspc

kqemu tu devrais pas en avoir besoin vu que tu profites de la technologie VT  :Wink:  (kqemu c'est l'accélérateur qui est utile seulement si tu ne peux utiliser kvm)

----------

## xaviermiller

Salut,

Peux-tu nous rappeler les flags CPU de /proc/cpuinfo qui mentionnent que tu as le support pour VT ?

----------

## kwenspc

 *XavierMiller wrote:*   

> Salut,
> 
> Peux-tu nous rappeler les flags CPU de /proc/cpuinfo qui mentionnent que tu as le support pour VT ?

 

flag vmx pour Intel et svm pour AMD

----------

## DuF

 *kwenspc wrote:*   

> kqemu tu devrais pas en avoir besoin vu que tu profites de la technologie VT  (kqemu c'est l'accélérateur qui est utile seulement si tu ne peux utiliser kvm)

 

Bon beh merci pour l'information, car je ne l'avais pas compris comme ça dans la documentation.

Toujours est-il qu'il faut que je trouve pourquoi j'ai un écart de performance assez fortement en défaveur de qemu par rapport à VirtualBox actuellement.

----------

## kwenspc

 *DuF wrote:*   

> 
> 
> Toujours est-il qu'il faut que je trouve pourquoi j'ai un écart de performance assez fortement en défaveur de qemu par rapport à VirtualBox actuellement.

 

Là encore à quel niveau? CPU ça m'étonnerait. Si c'est le cas alors vérifies bien que les modules kvm et kvm-intel son chargés. Quand ta VM et lancés ils doivent être tous deux utilisés: 

```

$ lsmod | grep kvm

kvm_intel              35304  1 

kvm                   131792  1 kvm_intel

```

Si c'est pas le cas alors ton qemu ne prend pas en compte KVM. Dans ce cas tu es sur une ancienne version qui ne le gère pas. 

Pour remédier à cela soi tu utilises le paquet app-emulation/kvm en stable ou bien app-emulation/qemu en instable. (le second est plus intéressant car il doit fournir qemuctl si je me souviens bien)

Si tes perfs sont moindres comparés à virtualbox au niveau réseau et/ou disques... virtio est ton ami.  :Smile: 

tu trouveras en général plus de précisions là bas: http://www.linux-kvm.org/page/Main_Page (c'est le site officiel de kvm)

----------

## DuF

 *kwenspc wrote:*   

> Là encore à quel niveau? CPU ça m'étonnerait. Si c'est le cas alors vérifies bien que les modules kvm et kvm-intel son chargés. Quand ta VM et lancés ils doivent être tous deux utilisés:
> 
> ```
> 
> $ lsmod | grep kvm
> ...

 

Bon alors je n'ai effectivement pas kvm mais ma version de qemu est bien celle que tu suggérais précédemment : 

```
duf@genduf ~ $ emerge -pv qemu

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R   ] app-emulation/qemu-0.10.5  USE="alsa gnutls kqemu kvm ncurses sdl -bluetooth -esd -pulseaudio -vde" QEMU_SOFTMMU_TARGETS="arm cris i386 m68k mips mips64 mips64el mipsel ppc ppc64 ppcemb sh4 sh4eb sparc x86_64" QEMU_USER_TARGETS="alpha arm armeb cris i386 m68k mips mips64 mips64el mipsel ppc ppc64 ppc64abi32 sh4 sh4eb sparc sparc32plus sparc64 x86_64" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

```

Là je refais des tests en réalisant un modprobe préalable des modules. Quand je lance qemu j'ai ça au niveau des modules :

```
duf@genduf ~ $ lsmod | grep kvm

kvm_intel              34384  0 

kvm                   109808  1 kvm_intel
```

Je recompile aussi qemu pour enlever kqemu comme tu me l'as suggéré, vu que ça m'est inutile. Je retesterai après et te tiendrai informé au cas où.

Petite question à côté, je n'ai pas qemuctl, si tu connais quel paquet le fournit je suis preneur sinon j'irai voir par moi-même ?

De toute façon là j'ai un peu de mal à appliquer la documentation que je lis sur qemu et virtio (surtout déterminer ce dont j'ai besoin) donc voilà, c'est encore un peu frais mais à force de me casser les dents ça va venir.

Sinon dernière question  :Smile:  Connais-tu virt-manager et si oui quel est ton avis dessus ? Même si tu ne connais pas et que tu en as des échos, je suis preneur aussi  :Very Happy: 

----------

## kwenspc

Pour kvm il faut préciser "-enable-kvm" comme option à qemu. (d'ailleurs tu peux inhiber kqemu de la même manière: "-no-kqemu")

Houlà sinon j'ai déraillé pour qemuctl. C'est un soft à part et en GUI en plus   :Rolling Eyes:  et qui n'est même pas dans portage ni à ma connaissance dans un overlay  :Sad: 

(cette <@&~#! de bouhbountou qui me fait faire des conneries, tout ça parce qu'au taf ils veulent ça...)

Bah du coup je m'y collerait bien à faire un ebuild! hop hop un ptit ebuild du matin

virt-manager est un soft de gestion et de monitoring des VM fait par red-hat (les même qui maintenant possèdent et maintiennent KVM ^^). C'est surtout très intéressant si tu as de multiples VM (plus de 2-3) et qui plus est distantes. C'est pour ça que je conseillerais qemuctl qui est plus "local". 

À ma connaissance virt-manager a besoin d'un démon dans la VM pour qu'on ait accès à toutes les fonctions. c'est pas le cas pour qemuctl (mais il sert pas à monitorer lui).

----------

## kwenspc

argl, je crois que je vais laisser tomber qemuctl... l'ebuild est fait  mais le soft se lance pas. Y a un bug que j'ai réussis à corriger mais y a le problème qu'il utilise glade-2 or la gtk2-gladexml semble utiliser glade-3 et je vois pas comment lui dire d'utilise glade-2  :Sad: 

qemuctl-0.2.1.ebuild

```

# Copyright 1999-2005 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: $

MY_P="${PN}${PV}.tar"

DESCRIPTION="GUI for controlling running VM in virtual pc emulator qemu"

HOMEPAGE="http://qemuctl.sourceforge.net/"

SRC_URI="http://sunet.dl.sourceforge.net/sourceforge/qemuctl/${MY_P}.gz"

LICENSE="GPL-2"

SLOT="0"

KEYWORDS="~x86 ~amd64"

IUSE=""

DEPEND="dev-lang/perl

    >=dev-perl/gtk2-perl-1.121

    >=dev-util/glade-2.0

    >=app-emulation/qemu-0.8.1"

src_unpack() {

    mv ${DISTDIR}/${MY_P}.gz ${DISTDIR}/${MY_P}

    unpack ${MY_P}

}

src_install() {

    cd "${WORKDIR}/${PN}${PV}"

    make DESTDIR=${D} install

}

```

Bon en fait leur soft est vraiment pas propre, déjà le paquet est un fichier tar et non un tar.gz comme ils nous le filent. Ensuite le bug suivant dans /usr/bin/qemuctl:

ligne 19 remplacer:

```

use Gtk2 qw\-init -threads-init\;

```

par:

```

use Gtk2 -init -threads-init;

```

Je vais voir si y a pas une option à passer sur use Gtk2::GladeXML;  pour qu'il utilise glade-2 derrière.

----------

## kwenspc

 :Laughing:  AH AH nikaîd le qemuctl (ça fait 6 ans que j'ai pas fais de perl et j'arrive encore à débugger, snifff)

Bon je crée le patch, je postes l'ebuild sur le bugzilla et rulez!

Un ptit scrot pour la route: screenshoot

 :Wink: 

(qemuctl c'est la petite barre qui apparait en haut de la fenêtre de la vm)

Tiens Duf, si tu veux renomme ton topic pour que le titre soit plus parlant, je pense que ça en intéressera certains.

----------

## kwenspc

Ebuild pour qemuctl

Il est simple d'utiliser qemuctl avec qemulauncher.

[edit]Qui est ce qui disait déjà que sur ce forum on trouvait plus de solutions?  :Laughing:  hein novazur![edit]

----------

## DuF

J'ai renommé le titre en me disant que ça respectait globalement les différents éléments du thread.

Peut être faudrait-il en créer un autre plus représentatif de la tournure actuelle du sujet.

Sinon je prends note pour l'option à passer à qemu avec kvm et je teste ça ce soir  :Smile: 

----------

## kwenspc

 *DuF wrote:*   

> 
> 
> Peut être faudrait-il en créer un autre plus représentatif de la tournure actuelle du sujet.
> 
> 

 

Bonne idée oui, je pourrais faire ça dans la section Documentations tiens.

----------

## xaviermiller

 *kwenspc wrote:*   

>  *DuF wrote:*   
> 
> Peut être faudrait-il en créer un autre plus représentatif de la tournure actuelle du sujet.
> 
>  
> ...

 

 :Wink: 

Oui, ce sujet est très intéressant  :Very Happy: 

----------

## geekounet

Un topic regroupant les infos, explications, trucs et astuces sur les différentes techniques de virtualisation serai une bonne idée.  :Wink: 

----------

## DuF

 *kwenspc wrote:*   

> Pour kvm il faut préciser "-enable-kvm" comme option à qemu. (d'ailleurs tu peux inhiber kqemu de la même manière: "-no-kqemu")
> 
> Houlà sinon j'ai déraillé pour qemuctl. C'est un soft à part et en GUI en plus   et qui n'est même pas dans portage ni à ma connaissance dans un overlay 
> 
> (cette <@&~#! de bouhbountou qui me fait faire des conneries, tout ça parce qu'au taf ils veulent ça...)
> ...

 

Concernant l'option "-enable-kvm" elle n'est pas disponible chez moi.

Par contre en lisant la documentation, ils indiquent d'utiliser de manière nominative qemu-system-x86_64 (même pour du i386) si on veut utiliser kvm.

C'est ce que je fais, mais a priori les modules kvm ne sont toujours pas utilisés :

```
duf@genduf ~ $ lsmod | grep -i kvm

kvm_intel              34384  0 

kvm                   109808  1 kvm_intel

```

Sinon je teste virtio pour l'image disque, je verrais bien ce que ça va donner. La ligne de commande que j'utilise actuellement pour lancer qemu est donc la suivante : 

```
qemu-system-x86_64 -drive file=osol.img,if=virtio -cdrom ../../Telechargements/osol-0906-x86.iso -boot d -m 1024
```

Déjà je pourrais constater si oui ou non j'arrive aux mêmes performances lors de l'installation car la dernière fois avec qemu c'était vraiment pas terrible du tout.

----------

## DuF

Vu que rien ne fut concluant (impossibilité d'installer les os que je souhaitais avec virtio) je vais revoir ma copie  :Smile: 

En effet, quand même bien le boot sur liveCD se fait correctement, j'ai plusieurs refus d'installation sur l'image disque quand il s'agissait d'un pilote disque "virtio".

Je vais aussi regarder c'est quoi cette option virtioconsole de qemu et voir si jamais elle ne pourrait pas me servir.

----------

## DuF

Bon alors, histoire de réduire les tests et de mieux comparé le comportement entre virtualbox et qemu je me suis dit, je vais tester une seule image OS.

J'ai donc choisi OpenSolaris. 

Et là, suivant si je démarre l'iso avec Virtualbox ou qemu je n'obtiens pas le même résultat. Sous Virtualbox j'ai envie de dire que l'image démarre toujours correctement, avec qemu, suivant ce que je lui passe en paramètre, j'obtiens des choses plus ou moins étonnantes. En général j'ai droit à gdm mais forcément je ne peux me connecter car il n'y a pas de compte indiqué (comme si le liveCD ne terminait pas son processus pour m'amener sur le bureau).

J'ai ensuite choisi Mandriva.

Et là, c'est sans souci avec virtual box mais c'est l'échec pour l'installer avec qemu, soit sur le pilote du disque dur quand j'utilise virtio (même si l'installation le détecte correctement) soit sur la configuration du boot d'amorçage si je n'utilise pas virtio. Je vais donc plus loin sans virtio, mais je ne peux pas finaliser l'installation. Cela m'aura au moins permis de me rendre compte qu'il ne faut pas utiliser virtio pour booter le CD même si cela fonctionne, c'est toujours un élément de la documentation qui sera pris en compte pour les prochains tests.

J'ai ensuite choisi Fedora (étant donné que niveau virtualisation ça doit être évolué avec RH derrière).

Bon et bien même constat que plus haut, sous virtualbox ça fonctionne mais avec qemu j'échoue partiellement (à l'installation des liveCD).

Ce qu'il en ressort :

- Je ne sais toujours pas configuré qemu correctement

- J'ai quand même compris que virtio ne devait pas être utilisé lors de l'installation de l'OS, mais seulement après lors du premier boot.

- Virtualbox par défaut est plus simple d'accès et permet une prise en main bien plus rapide

- Virtualbox en version "ose" ne me permets pas de dépasser le 800*600 en résolution (faut que je trouve l'option pour corriger ça si c'est possible car c'est vraiment petit).

- Sur certains tests, qemu semble enterrer virtualbox-ose mais je ne peux jamais finaliser les installations dans ces cas là.

Conclusion finale :

- Même joueur joue encore !

----------

## kwenspc

De passage rapido (vive les connexions wifi non sécurisé...). Tu n'as pas l'option -enable-kvm car apparemment l'ebuild est pas au poil.

J'ai d'abord installé qemu (use flag kvm de mis etc...), qui a besoin des linux-headers-2.6.29. Et pareil, une fois installé pas d'option -enable-kvm. Il m'a fallut installe le noyau 2.6.29, rebooter dessus et reinstaller qemu pour que ça fonctionne. (enfin la resinstall peut se faire apres le reboot: le tout c'est que qemu soit construit autour du noyau 2.6.29)

Pour virtio, il peut y avoir aussi un soucis de compatibilité entre versions noyau et qemu. linux-2.6.29 et qemu-0.10.5 amha est la bonne combinaison.

Sinon, juste pour répéter: Il existe des FRONTEND à qemu, pour vous éviter de taper de la ligne de commande!!!  :Wink: 

----------

## DuF

Bon, je suis en 2.6.28... Je sais ce qu'il me reste à faire mais ça m'embête un peu car je voulais d'abord faire du ménage dans mon noyau actuel... Tant pis, faut que je teste avec kvm !

----------

## kwenspc

 *DuF wrote:*   

> Bon, je suis en 2.6.28... Je sais ce qu'il me reste à faire mais ça m'embête un peu car je voulais d'abord faire du ménage dans mon noyau actuel... Tant pis, faut que je teste avec kvm !

 

Oui et puis pour les virtio, ya pas mal de modules à mettre en place, ils sont éparpillés un peu partout dans le menuconfig. Je te file la liste, faudra que je la mette dans la doc mais je suis un peu trop occupé pour le moment:

 *Quote:*   

> 
> 
> Virtualization --> tu prends tout sauf le module qui n'est pas associé à ton CPU (tu laisses amd donc).
> 
> Device Drivers:
> ...

 

Bon par contre je suis un peu confus, virtio nécessite un driver dans l'os guest (celui dans la VM). Je ne l'ai utilisé que sur des linux et du coup ça marchait "from scratch", jamais noté ça. Cf: http://fr.wikipedia.org/wiki/Virtio

Ce qui est sûr c'est que ça fonctionne au poil pour des VM linux. Il y a apparament des drivers pour windows et peut-être pour d'autres OS (à fortiori si ce sont des OS open source)

----------

## man in the hill

Salut

Cela ne m'a pas l'air plus simple que xen qui est très documenté, c'est le côté serveur qui m'intéresse le plus...

Vous pouvez faire une récap de ce qui fonctionne (net, usb, pilote graphique, os, etc ...) avec même un mini tuto et des liens, si possible.

merci

@+

----------

## ppg

 *man in the hill wrote:*   

> Salut
> 
> Cela ne m'a pas l'air plus simple que xen qui est très documenté, c'est le côté serveur qui m'intéresse le plus...
> 
> Vous pouvez faire une récap de ce qui fonctionne (net, usb, pilote graphique, os, etc ...) avec même un mini tuto et des liens, si possible.
> ...

 

Ça serait pas mal. Ce qui serait bien aussi, ça serait de donner les equivalences entre Xen et qemu/kvm pour créer des machines, les lancer, les stopper…

Par exemple, quelle commande correspond à xentop avec kvm ?

Voilà dans l'idéal, après il faut avoir le temps de le faire (et ça c'est moins évident).

----------

## DuF

 *kwenspc wrote:*   

>  *DuF wrote:*   Bon, je suis en 2.6.28... Je sais ce qu'il me reste à faire mais ça m'embête un peu car je voulais d'abord faire du ménage dans mon noyau actuel... Tant pis, faut que je teste avec kvm ! 
> 
> Oui et puis pour les virtio, ya pas mal de modules à mettre en place, ils sont éparpillés un peu partout dans le menuconfig. Je te file la liste, faudra que je la mette dans la doc mais je suis un peu trop occupé pour le moment:
> 
> 

 

Bon je vais juste répondre sur cette partie là afin de donner l'avancement.

Alors le passage au noyau 2.6.29-r5 au lieu du 2.6.28-r5 a eu un effet positif plus que conséquent sur le démarrage des liveCD, que ce soit pour OpenSolaris, Fedora ou Mandriva.

Je précise que les modules kvm ne sont toujours pas chargés et qu'il faut absolument que je résolve ce point. Mais pour l'instant, le passage au noyau 2.6.29 me permet d'obtenir les mêmes performances pour ces 3 liveCD qu'avec VirtualBox. Et il y a un autre point positif, j'ai pu réaliser l'installation de la Mandriva 2009 Spring. Par contre pour fedora c'est toujours bancal et l'OpenSolaris c'est encore plus bizarre, elle démarre comme si ça n'était pas un liveCD...

Prochaine étape, démarrage de la Mandriva installée avec les pilotes virtio et surtout, utilisation de kvm ce qui pour l'instant reste pour moi une énigme totalement capilotractée !

----------

## kwenspc

 *DuF wrote:*   

> 
> 
> Prochaine étape, démarrage de la Mandriva installée avec les pilotes virtio et surtout, utilisation de kvm ce qui pour l'instant reste pour moi une énigme totalement capilotractée !

 

Pour kvm, as tu suivis mon conseil plus haut? c'est à dire re-emerger qemu? (en étant sûr que le use flag kvm est là). J'ai eu le même soucis. Apparemment l'ebuild est mal fichu sur ce point. C'est à dire que tu as beau avoir le use flag kvm, qemu au configure détecte lui même si c'est possible de l'utiliser ou non. Et de fait, il se peut qui compile sans le support kvm, d'où l'inexistence de l'option -enable-kvm permettant de l'utiliser. Enfin bref la solution, maintenant que tu es en 2.6.29 c'est juste de le re-emerger.

----------

## man in the hill

Salut

Je me lance !

Petite lecture ici

----------

## DuF

 *kwenspc wrote:*   

>  *DuF wrote:*   
> 
> Prochaine étape, démarrage de la Mandriva installée avec les pilotes virtio et surtout, utilisation de kvm ce qui pour l'instant reste pour moi une énigme totalement capilotractée ! 
> 
> Pour kvm, as tu suivis mon conseil plus haut? c'est à dire re-emerger qemu? (en étant sûr que le use flag kvm est là). J'ai eu le même soucis. Apparemment l'ebuild est mal fichu sur ce point. C'est à dire que tu as beau avoir le use flag kvm, qemu au configure détecte lui même si c'est possible de l'utiliser ou non. Et de fait, il se peut qui compile sans le support kvm, d'où l'inexistence de l'option -enable-kvm permettant de l'utiliser. Enfin bref la solution, maintenant que tu es en 2.6.29 c'est juste de le re-emerger.

 

En fait c'est juste que quand je fais mes tests tard le soir je suis un gros idiot  :Smile: 

En fait j'avais bien suivi tes conseils, sauf que quand j'ai lancé qemu, j'ai utilisé l'historique de mes commandes et j'ai pas vérifié que la commande que j'avais choisi était bien ma dernière tentative avec l'option -enable-kvm dans la ligne de commande....

Donc là je viens de retester et c'est ok :

```
duf@genduf ~ $ lsmod | grep kvm

kvm_intel              31128  3 

kvm                   113512  1 kvm_intel

```

Voilà, fallait juste que je sois un peu plus vigilant....

Là je relances l'installation de Mandriva car c'était la seule totalement opérationnelle. Déjà rien que l'interface graphique de l'installeur est hautement plus réactive. Je n'ai pas utilisé virtio pour l'image disque car dans la doc de kvm ils indiquent de plutot faire les installations sans et de modifier ensuite pour l'utiliser quand l'OS est installé. Ce sera la prochaine étape ainsi que la tentative de retester les autres liveCD.

Encore merci pour les "bons" conseils (c'est juste que je n'avais pas tout bien suivi   :Wink:  )

EDIT : C'est définitivement le jour et la nuit avec les liveCD avec ou sans KVM.

EDIT 2 :

 *kwenspc wrote:*   

> linux-2.6.29 et qemu-0.10.5 amha est la bonne combinaison

 

Je confirme, pendant que je fais l'installation de la Mandriva 2009, j'ai lancé une 2ème machine virtuel pour OpenSolaris et là 2 constats : 

- démarrage ultra rapide du liveCD (environ 20 secondes contre 3-4 minutes sans kvm et sans le noyau 2.6.29)

- fin du bug de chargement d'OpenSolaris qui empêchait d'aboutir au bureau (je précise que j'utilise la même image liveCD depuis le début).

Donc il n'y a pas photo  :Smile: 

----------

## man in the hill

 *kwenspc wrote:*   

> Bon par contre je suis un peu confus, virtio nécessite un driver dans l'os guest (celui dans la VM). Je ne l'ai utilisé que sur des linux et du coup ça marchait "from scratch", jamais noté ça. Cf: http://fr.wikipedia.org/wiki/Virtio
> 
> Ce qui est sûr c'est que ça fonctionne au poil pour des VM linux. Il y a apparament des drivers pour windows et peut-être pour d'autres OS (à fortiori si ce sont des OS open source)

 

Est-ce que j'ai bien compris que virtio est utile que pour le noyau  du système invité pour accélérer les accès disque, réseau et pour l'augmentation/diminution de mémoire de façon dynamique de la vm ?

Est-ce que l'on peu comme Xen dédié une partition au lieu d'un fichier image pour le disque dur pour augmenter la rapidité de la vm ?

Y a t'il une interface d'admin pour faire des snapshots à chaud via le réseau ?

Est-ce que l'usb est pris en charge d'après vos tests ?

Oui j'ai lu qu'il y a un pilote windows mais que pour l'interface réseau ici

----------

## kwenspc

 *man in the hill wrote:*   

> 
> 
> Est-ce que j'ai bien compris que virtio est utile que pour le noyau  du système invité pour accélérer les accès disque, réseau et pour l'augmentation/diminution de mémoire de façon dynamique de la vm ?
> 
> 

 

C'est ce qu'il semble oui, il faut des drivers des 2 côtés. Je n'avais pas tilté jusqu'alors car mes VM sont des linux ubuntu (dslé c'était voulu par le client ...) qui fournit le module par défaut. Du coup j'ai pas eu à me poser de questions. 

 *man in the hill wrote:*   

> 
> 
> Est-ce que l'on peu comme Xen dédié une partition au lieu d'un fichier image pour le disque dur pour augmenter la rapidité de la vm ?
> 
> 

 

C'est apparemment possible mais nettement moins souple que Xen, il faut passer le disque en entier à qemu (et donc les OS sur les partoches doivent être pris en compte par le boot loader sur ce disque)

Cela dit les partitions c'est jamais aussi souple que des images.  (qui permettent un transfert de la vm sans l'éteindre des trucs comme ça  :Smile:  )

 *man in the hill wrote:*   

> 
> 
> Y a t'il une interface d'admin pour faire des snapshots à chaud via le réseau ?
> 
> 

 

Via le réseau? virt-manager peut-être, sans doute même. Après localement il y a une GUI qemuctl (j'ai posté l'ebuild sur le bugzilla) sinon tu as les raccourcis claviers: Ctrl-Alt+1/2/ ou pour respectivement: display (la vue par défaut donc), monitor (celle qui permet des demander un snapshot etc...) et serial. un man qemu expliques tout ça sinon la doc officielle.

 *man in the hill wrote:*   

> 
> 
> Est-ce que l'usb est pris en charge d'après vos tests ?
> 
> 

 

Ça marche oui, faut juste dire à qemu d'utiliser un port bien précis pour ça. Ça reste encore pas aussi souple que virtualbox, mais c'est d'ailleurs le seul avantage de virtualbox à mon sens (et d'ailleurs ce code bien précis dans virtualbox est un de code proprio, si mes souvenirs sont bons) :wnik:

Faut pas s'y fier, qemu semble être un émulateur/virtualizeur pour quelques vm, et bien pas du tout. Il excelle sur le marché de vmware et de Xen. Je suis d'ailleurs passé qemu/kvm dès lors que kvm était stable il y a un peu plus d'un an à mon travail (entre 30 et 50 vm sur 2 machines dédiés): on a eu *aucun* problème, contrairement à Xen qui nous a fait nous arracher les cheveux. 

Je le dis sérieusement, pour moi qemu/KVM est la killer app libre dans le segment de l'émulation/virtualization. 

je ne sais plus qui sur ce forum (je crois que c'est un de nos quelques BSDistes convaincus) a posté il y a quelques mois un lien sur un projet permettant d'utiliser qemu/kvm dans les mêmes conditions que vmware eax ou Xen, c-a-d un gros parc que VM sur plein de serveurs avec tout ce que sa suppose derrière (fairover, déplacement de vm sans extinction de celle ci etc...)

----------

## man in the hill

 *kwenspc wrote:*   

> Faut pas s'y fier, qemu semble être un émulateur/virtualizeur pour quelques vm, et bien pas du tout. Il excelle sur le marché de vmware et de Xen. Je suis d'ailleurs passé qemu/kvm dès lors que kvm était stable il y a un peu plus d'un an à mon travail (entre 30 et 50 vm sur 2 machines dédiés): on a eu *aucun* problème, contrairement à Xen qui nous a fait nous arracher les cheveux. 
> 
> Je le dis sérieusement, pour moi qemu/KVM est la killer app libre dans le segment de l'émulation/virtualization. 

 

J'ai commencer:

-L'installe de windows super lent et le bureau super lent.

- Linstall debian un peu plus fluide mais plante sur la fin

- L'install ubuntu tres lent et pas encore arrivé sur le bureau.

En bref, c'est assez decevant ...

Je lance l'installe avec:

```

/usr/bin/qemu-system-x86_64 -localtime -m 1G -k fr -net nic -net tap,ifname=tap0,script=no -usb -boot d -hda linux.qcow2 -cdrom  debian-501-i386-CD-1.iso

```

 *kwenspc wrote:*   

> 
> 
> je ne sais plus qui sur ce forum (je crois que c'est un de nos quelques BSDistes convaincus) a posté il y a quelques mois un lien sur un projet permettant d'utiliser qemu/kvm dans les mêmes conditions que vmware eax ou Xen, c-a-d un gros parc que VM sur plein de serveurs avec tout ce que sa suppose derrière (fairover, déplacement de vm sans extinction de celle ci etc...)

 

C'est ça qu'il me faut ... Au moins pouvoir lancer plusieurs vm (windows, bsd, linux) sur une machine dédié, faire des snaps et être prêt a redémarrer ces snap ds les meilleurs delais sur une autre machine

----------

## DuF

 *man in the hill wrote:*   

> 
> 
> J'ai commencer:
> 
> -L'installe de windows super lent et le bureau super lent.
> ...

 

En faisant ainsi tu n'as pas activé kvm. Il faut rajouter l'option -enable-kvm, sinon point de salut !

----------

## man in the hill

 *DuF wrote:*   

>  *man in the hill wrote:*   
> 
> J'ai commencer:
> 
> -L'installe de windows super lent et le bureau super lent.
> ...

 

J'avais zappé cela pendant la lecture !

Je test de suite !

[EDIT] Avec l'option -enable-kvm ds la ligne de commande ci-dessus les accès disques étaient plus rapide mais il y avait un bloquage du système pendant l'installe windows ou linux et j'ai installé  app-emulation/kvm  et lancer la même commande  qu'avec qemu-system-x86_64 sans -enable-kvm car c'est par défault 

```
 kvm -localtime -m 1G -k fr -net nic -net tap,ifname=tap0,script=no -usb -boot d -hda linux.qcow2 -cdrom  xp.iso
```

  et ça passe   :Cool:  et j'ai retrouver le sourire. 

J'ai le net avec le mode pont que j'ai configuré qui me semble rapide mais je vais quand même tester le virtio net pour windows. Il me reste à trouver la conf pour l'usb . 

Maintenant je veux bien croire que qemu/kvm soit un killer d'app émulation/virtualisation dixit kwenspc . [/EDIT]

----------

## DuF

Alors par contre là je vais avoir une question bête pour kwenspc : 

c'est quoi la différence entre "qemu + enable kvm" et app-emulation/kvm ?

Cdt,

----------

## kwenspc

 *DuF wrote:*   

> 
> 
> c'est quoi la différence entre "qemu + enable kvm" et app-emulation/kvm ?
> 
> 

 

Jusqu'à il y a peut l'équipe de qumranet, qui a fait kvm, à forker le qemu pour utiliser leur modules. Depuis ça a été "mergé" au code original. app-emulation/kvm est voué à disparaître amha.

----------

## mrpouet

 *kwenspc wrote:*   

>  *DuF wrote:*   
> 
> c'est quoi la différence entre "qemu + enable kvm" et app-emulation/kvm ?
> 
>  
> ...

 

je plussoie   :Smile: 

----------

## DuF

OK, tout est clair, je reste donc avec ce que j'ai  :Smile: 

----------

## DuF

Bon j'ai un petit souci avec virtio et ma version de qemu :

```
duf@genduf ~ $ qemu-system-x86_64 -enable-kvm -boot c -drive file=Documents/OSimages/fedora.img,if=virtio,boot=on -m 1024

qemu: unknown parameter 'boot' in 'file=Documents/OSimages/fedora.img,if=virtio,boot=on'

```

Je me suis basé sur la doc suivante : http://www.linux-kvm.org/page/Boot_from_virtio_block_device

Le souci, c'est qu'une fois que je change :

```
qemu-system-x86_64 -enable-kvm -hda Documents/OSimages/fedora.img -boot c -m 1024
```

par :

```
qemu-system-x86_64 -enable-kvm -boot c -drive file=Documents/OSimages/fedora.img,if=virtio,boot=on -m 1024
```

J'observe que seul un lecteur cdrom est émulé lors du boot, en gros, lors du premier écran de la machine virtuelle que lance qemu, je n'ai plus de disque local.

Je ne comprends pas trop ce qui se passe. J'ai aussi regardé la doc suivante : http://www.linux-kvm.org/page/Virtio ainsi que la doc de qemu : http://www.nongnu.org/qemu/qemu-doc.html mais il n'y a qu'une référence à virtio, donc rien de bien probant...

Si quelqu'un a déjà expérimenté, je suis preneur d'aide  :Smile: 

----------

## man in the hill

 *DuF wrote:*   

> Bon j'ai un petit souci avec virtio et ma version de qemu :
> 
> ```
> duf@genduf ~ $ qemu-system-x86_64 -enable-kvm -boot c -drive file=Documents/OSimages/fedora.img,if=virtio,boot=on -m 1024
> 
> ...

 

Il n'y a pas d'option boot ds le manuel de qemu/kvm donc c'est normal, aucune idée pourquoi cette option ce trouve sur le site de kvm .

[edit] kvm gère l'option boot, ensuite faut sûrement activer les virtio ds le kernel de la vm pour que cela roule [/edit]

 *DuF wrote:*   

> 
> 
> Le souci, c'est qu'une fois que je change :
> 
> ```
> ...

 

idem pour moi, je ferais des recherches plus tard ...

Mon host est une gentoo testing avec un kernel 2.6.30-gentoo-r2 64bit et il n'y a que kvm qui passe chez moi.

----------

## DuF

Pour info, je n'ai toujours pas réussi à avancer sur virtio. J'ai toujours le même souci, à savoir qu'il m'est impossible de démarrer une VM qui ait un disque déclaré lors du boot.

En gros, 

- avec virtio j'ai un ata1 master qui est le QEMU DVDROM

- sans virtio j'ai un ata0 qui est de type QEMU HARDDISK ATA-7 en plus du ATA1 QEMU DVDROM

J'essaye donc toujours de voir côté qemu la marche à suivre pour obtenir la prise en charge lors du boot d'un disque de type ata "virtio". Après effectivement je m'assurerai que l'os de la VM invitée a bien virtio dans son noyau, mais pour l'instant je n'en suis pas encore à cette étape là  :Smile: 

Dans les trucs étonnants j'ai aussi ça : 

```
No SMP KVM support, use '-smp 1'

```

Alors que la doc suivante # 1.4.15 Does kvm support SMP guests? laisse supposer le contraire. Et l'ebuild actuel ne présente pas d'éléments indiquant une limitation sur ce sujet, étonnant donc.

----------

## man in the hill

 *DuF wrote:*   

> Pour info, je n'ai toujours pas réussi à avancer sur virtio. J'ai toujours le même souci, à savoir qu'il m'est impossible de démarrer une VM qui ait un disque déclaré lors du boot.
> 
> En gros, 
> 
> - avec virtio j'ai un ata1 master qui est le QEMU DVDROM
> ...

 

on est d'accord ! J'ai fais pas mal de recherche et de test et je n'ai pas encore trouvé la solution . J'ai aussi installé virt-manager pour faire une installe en mode graphique et voir les commandes derrière et il n'y a pas de mystère car virtio est utilisé d'office et le même problème de non détection du disque de boot virtio.

 *DuF wrote:*   

> Dans les trucs étonnants j'ai aussi ça : 
> 
> ```
> No SMP KVM support, use '-smp 1'
> 
> ...

 

 Le support smp est pris en charge .

Je lance ma machine virtuelle comme ceci avec virtio:

```

kvm  -smp 2 -m 1024 -localtime -k fr -drive file=debian.qcow2,media=disk,if=virtio,index=0,boot=on -net nic,model=virtio -net tap,ifname=tap0,script=no

```

Il semble qu'il n'y a que l'interface ide qui fonctionne correctement.

```

kvm  -smp 2 -m 1024 -localtime -k fr -drive file=debian.qcow2,media=disk,if=ide,index=0,boot=on -net nic,model=virtio -net tap,ifname=tap0,script=no

```

C'est quoi ta config de ton host car kvm continu à être développé ici et il serait intéressant de tester les dernières versions mais je ne vois que du 32bit et je suis en 64 ...

----------

## kwenspc

man_in_the_hill tu utilises le paquet app-emulation/kvm au lieu de app-emulation/qemu? 

SMP est bien supporté sous kvm. 

Pour virtio j'ai rien à testé là, mais vous êtes sûr d'avoir virtio, virtio-pci, virtio-net et virtio-blk de chargés tous sans exception?

----------

## DuF

 *kwenspc wrote:*   

> SMP est bien supporté sous kvm. 
> 
> Pour virtio j'ai rien à testé là, mais vous êtes sûr d'avoir virtio, virtio-pci, virtio-net et virtio-blk de chargés tous sans exception?

 

Pour kvm et smp, chez moi ça ne fonctionne pas (j'ai notamment vérifié avec nmon, que lorsque je charge une VM, elle n'utilise jamais plus d'un CPU à la fois); je continue de chercher pourquoi même si dans l'immédiat ce n'est pas prioritaire.

Quand tu parles d'avoir virtio et la suite de chargé, tu parles de l'hôte ou du système invité ? A mons avis tu parles du système invité, enfin je l'espère car c'est ainsi que j'ai compris la documentation : 

 *http://www.linux-kvm.org/page/Virtio wrote:*   

> The host implementation is in userspace - qemu, so no driver is needed in the host. 

 

Sinon au niveau des tests, voilà où j'en suis : 

```
qemu-system-x86_64 -cpu core2duo -vga std -enable-kvm -boot d -drive file=Documents/OSimages/fedora_virtio.img,if=virtio,index=0,media=disk -drive file=Telechargements/Fedora-11-i686-Live-KDE.iso,index=1,media=cdrom -m 1024

```

==> Avec ça, j'obtiens 2 fois un QEMU DVDROM au boot (pas vraiment ce que je cherche)

```
qemu-system-x86_64 -cpu core2duo -vga std -enable-kvm -boot d -drive file=Documents/OSimages/fedora_virtio.img,if=virtio -drive file=Telechargements/Fedora-11-i686-Live-KDE.iso -m 1024

```

==> Avec celle là, j'obtiens un QEMU DVDROM mais en premier lieu QEMU HARDDISK ATA-7, donc plutôt pas mal. Mais chose étrange, il indique qu'il fait 685Mo... J'ai donc l'impression que le QEMU DVDROM c'est l'image disque, et le QEMU ATA-7 l'image iso...

D'ailleurs, si je modifie la valeur d'index à 2 par exemple pour l'image iso, je me retrouve avec seulement un QEMU DVDROM...

Pour l'instant je n'arrive absolument pas à utiliser qemu+kvm+virtio pour l'image disque locale, échec total !

----------

## kwenspc

 *DuF wrote:*   

> 
> 
> Quand tu parles d'avoir virtio et la suite de chargé, tu parles de l'hôte ou du système invité ? A mons avis tu parles du système invité, enfin je l'espère car c'est ainsi que j'ai compris la documentation : 
> 
>  *http://www.linux-kvm.org/page/Virtio wrote:*   The host implementation is in userspace - qemu, so no driver is needed in the host.  
> ...

 

Oui l'invité uniquement. 

Sinon faut bien installer via -hda et ensuite faire tourner via virtio, le guest demandant quelques modifs: http://www.linux-kvm.org/page/Boot_from_virtio_block_device

----------

## DuF

 *kwenspc wrote:*   

> Oui l'invité uniquement. 
> 
> Sinon faut bien installer via -hda et ensuite faire tourner via virtio, le guest demandant quelques modifs: http://www.linux-kvm.org/page/Boot_from_virtio_block_device

 

Ca je l'ai tenté aussi, le problème est toujours le même, quand je veux démarrer en remplaçant -hda par -drive avec if=virtio la VM n'a pas de disque du type QEMU HARDDISK. Donc le boot plante car il me dit que je n'ai pas de disque de boot ou que le disque de boot ne permet pas de booter.

A mon avis, je dois avoir un souci dans ma ligne de commande pour démarrer la VM, mais pour l'instant je n'ai pas encore trouvé...

----------

## kwenspc

Ou alors le guest qui n'a pas virtio en dur et/ou virtio en modules dans son initird?

----------

## man in the hill

 *kwenspc wrote:*   

> man_in_the_hill tu utilises le paquet app-emulation/kvm au lieu de app-emulation/qemu? 

 

J'utilise app-emulation/kvm sans modules avec les uses -modules havekernel car obligé d'utiliser les modules du noyau . Les modules kvm-kvmd ne sont pas compatible avec mon noyau 2.6.30-r2, qemu freeze la vm pendant l'install chez moi .

 *Duf wrote:*   

> A mon avis, je dois avoir un souci dans ma ligne de commande pour démarrer la VM, mais pour l'instant je n'ai pas encore trouvé...

 

Comme j'ai dis ds mon avant dernier post, j'ai lancer une VM  avec virt-manager + la libvirt et il utilise quasiment la même ligne de commande que nous que voici :

```

/usr/bin/kvm -S -M pc -m 1024 -smp 2 -name DEB -uuid 5b8deb59-ef4c-19fa-814d-9727482c8766 -monitor pty -boot c -drive file=,if=ide,media=cdrom,index=2 -drive file=debian.qcow2,if=virtio,index=0,boot=on -net nic,macaddr=54:52:00:7a:33:3c,vlan=0,model=virtio -net tap,fd=17,vlan=0 -serial -parallel none -usb -vnc 127.0.0.1:0 -k fr 
```

et pas de détection du disque de boot ....

Je pencherais plûtot vers une question de version  qemu/kvm ...

J'ai lu que certains mettais 2 dd, 1 en virtio + 1 en ide ou inversement :

```

kvm -localtime -k fr -M pc -m 1024 -smp 2 -drive file=debian.qcow2,media=disk,index=0,if=virtio,boot=on -drive file=debian.qcow2,media=disk,index=0,if=ide  -net nic,model=virtio -net tap,ifname=tap0,script=no 
```

 Tu retrouves ainsi le dd de boot ... Ds la console ctrl +alt + 2 en tapant info block , tu retrouvres les deux dd :

```
(qemu) info block

virtio0: type=hd removable=0 file=debian.qcow2 ro=0 drv=qcow2 encrypted=0

ide0-hd0: type=hd removable=0 file=debian.qcow2 ro=0 drv=qcow2 encrypted=0

```

mais ds la vm quand tu fais un lsmod, il n'y a aucun module virtio d'utilisé et un lspci ne te donne aucun périphérique virtio . (voir ici )

Finallement, moi qui pensait utiliser au moins la virtio net ...

----------

## kwenspc

Essayez une image dédié au boot (kernel + initrd avec les bon drivers) en le disques système en virtio. 

Sinon man in the hill pour qemu c'est peut-être le noyau qui est trop récent.

----------

## DuF

Encore une fois, le problème est réellement au boot de la VM, je vais essayer de donner un cas basique avec le maximum d'informations pour imager au mieux ce qui se produit.

Voici par exemple une ligne de commande plutot simple :

```
qemu-system-x86_64 -enable-kvm -boot c -drive file=Documents/OSimages/fedora_virtio.img,if=virtio,index=0,media=disk -m 1024
```

Mais j'obtiens les éléments suivants :

```
Plex6/Bochs VGABIOS (PCI) current-cvs 10 Dec 2008

This VGA/VBE Bios is released under the GNU LGPL

Please visit : 

. http://bochs.sourceforge.net

. http://www.nongnu.org/vgabios

cirrus-compatible VGA is detected

QEMU BIOS - build : 05/08/09

$revision$ $date$

Options: apmbios pcibios eltorito rombios32

ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-ROM

Press F12 for boot menu

Booting from Hard Disk....

Boot failed: could not read the boot disk

FATAL: No bootable device
```

Il interprète donc le paramètre media=disk en tant que QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-ROM, c'est ça qui me gêne.

Car en fait j'ai réussi par exemple à installer la Fedora sur une image disque locale de 10Go alors que boot de la VM il indiquait un disque de 685M, mais ça me parait tellement illogique. Et mes expérimentations, même si pour l'instant elles sont personelles, il n'empêche que si je pouvais, je basculerais sur qemu au boulot, mais pour l'instant j'en suis loin.

GROS EDIT : Bon fait peut être que j'arrête de me braquer sur ce qu'indique QEMU au boot de la VM, car à l'instant je viens de refaire un test avec la ligne suivante : 

```
qemu-system-x86_64 -cpu core2duo -vga std -enable-kvm -boot d -drive file=Documents/OSimages/fedora_virtio.img,if=virtio,index=0,media=disk -drive file=Telechargements/Fedora-11-i686-Live-KDE.iso,if=ide,index=1,media=cdrom -m 1024

```

Au boot de la VM j'ai les 2 lignes suivantes : 

```
ata0 slave: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-ROM

ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-ROM
```

Le liveCD boot correctement et quand je fais l'installation, il me détecte bien un disque vda de 10Go, donc ça semble bon.

Il ne me reste qu'a finir l'installation et à modifier les données de boot dans le système invité pour indiquer que c'est un disque vda et pas hda. Mais bon, je ne suis pas sûr de réussir de toute façon, car il me semble déjà avoir testé de cette manière, et la VM ne démarrait toujours pas pour cause de "disque non bootable", mais ça vaut le coup de retenter.

EDIT 2 : Même joueur joue encore   :Laughing: 

----------

## kwenspc

Essais avec un disque dédié au boot: c-a-d un image que tu lui refiles en if=ide et sur lequel se trouve le kernel et l'initrd, ainsi que grub ou lilo.

----------

## DuF

 *kwenspc wrote:*   

> Essais avec un disque dédié au boot: c-a-d un image que tu lui refiles en if=ide et sur lequel se trouve le kernel et l'initrd, ainsi que grub ou lilo.

 

Je vais peut être dire une bêtise si je fais ça, ça revient à tester avec un -hda (pour moi if=ide est équivalent de -hda, là où if=virtio correspond à vda) et ça ça fonctionne. Ou alors j'ai pas compris l'idée du test que tu souhaites que je réalise (dont je suis de toute façon preneur  :Smile:  ).

Cdt,

----------

## man in the hill

Salut,

Bon, j'ai installé une debian lenny sur une de mes partitions et kvm fonctionne avec virtio !

Faut pas se fier a ce que le bios de qemu/kvm affiche car il me détecte soit disant que le graveur mais boot quand même sur le bon dd en utilisant virtio . On vérifie avec la console alt + ctrl + 2

info kvm

info block

Je vais installer une gentoo 32 stable pour tester .

----------

## kwenspc

 *DuF wrote:*   

> 
> 
> Je vais peut être dire une bêtise si je fais ça, ça revient à tester avec un -hda (pour moi if=ide est équivalent de -hda, là où if=virtio correspond à vda) et ça ça fonctionne. Ou alors j'ai pas compris l'idée du test que tu souhaites que je réalise (dont je suis de toute façon preneur  ).
> 
> Cdt,

 

Je parle de 2 disques: un en if=ide (celui qui aura /boot) et l'autre (le reste du système etc...) en if=virtio.

----------

## man in the hill

 *kwenspc wrote:*   

>  *DuF wrote:*   
> 
> Je vais peut être dire une bêtise si je fais ça, ça revient à tester avec un -hda (pour moi if=ide est équivalent de -hda, là où if=virtio correspond à vda) et ça ça fonctionne. Ou alors j'ai pas compris l'idée du test que tu souhaites que je réalise (dont je suis de toute façon preneur  ).
> 
> Cdt, 
> ...

 

J'ai testé ça et expliqué sur 2 post plus haut mais cette methode boot effectivement car tu as une interface en ide mais n'utilise pas les virtio ! C'est juste une illusion   :Wink: 

----------

## man in the hill

 *man in the hill wrote:*   

> Salut,
> 
> Bon, j'ai installé une debian lenny sur une de mes partitions et kvm fonctionne avec virtio !
> 
> Faut pas se fier a ce que le bios de qemu/kvm affiche car il me détecte soit disant que le graveur mais boot quand même sur le bon dd en utilisant virtio . On vérifie avec la console alt + ctrl + 2
> ...

 

Test sur gentoo 32 bit stable positif puis retour sur gentoo 64 bit testing tjrs positif avec kvm !

En résumé, l'install se fait correctement même si le bios de qemu ne détecte pas le dd virtio de boot  mais ds la console on peut vérifier que virtio est utilisé pour le dd.

Ensuite le boot sur la vm se fait correctement, idem pour l'install ... On vérifie que la vm utilise virtio avec un lsmod .

virt-manager fonctionne aussi.

Donc de mon côté c'est résolu, je vais commencer à tester les fonctionnalitées comme les snapshots, les migrations, etc ...

ps: Duf, tu devrais tester kvm avec les modules du noyau sans kvm-kmod avec les uses -modules havekernel.

je pense que mon soucis venait du fait que je n'avais pas installé la vm avec virtio et ça bloquais mais le bios m'a tjrs lancé grub donc le disque tjrs trouvé ...

----------

## DuF

Hello,

J'ai un peu laché l'affaire avec virtio car j'avais l'impression de me perdre dans la compréhension que j'en avais. Au final je me retrouvais à faire des tests et 5min après à me dire que je faisais n'importe quoi.

Et moi le souci, c'est qu'il ne me lance jamais grub, en fait systématiquement il me dit que mon disque n'est pas bootable...

Mais dès que je trouve la connerie qui me bloque, je vous préviens  :Smile: 

----------

## man in the hill

 *DuF wrote:*   

> Hello,
> 
> J'ai un peu laché l'affaire avec virtio car j'avais l'impression de me perdre dans la compréhension que j'en avais. Au final je me retrouvais à faire des tests et 5min après à me dire que je faisais n'importe quoi.
> 
> Et moi le souci, c'est qu'il ne me lance jamais grub, en fait systématiquement il me dit que mon disque n'est pas bootable...
> ...

 

 *man in the hill wrote:*   

> ps: Duf, tu devrais tester kvm avec les modules du noyau sans kvm-kmod avec les uses -modules havekernel.

 

La dernière version de kvm est passé ds portage testing et fonctionne nikel.

```
emerge -pv kvm

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R   ] app-emulation/kvm-88-r1  USE="alsa bluetooth esd havekernel ncurses sdl -gnutls -modules -pulseaudio -vde" 0 kB

```

----------

## man in the hill

Est-il possible de faire des snapshots incrémental pour optimiser les sauvegardes des machines virtuelles ?

----------

## kwenspc

 *man in the hill wrote:*   

> Est-il possible de faire des snapshots incrémental pour optimiser les sauvegardes des machines virtuelles ?

 

Je crois pas malheureusement. J'en suis pas sûr mais si c'est le cas ça reste une feature un peu en retrait comparé aux autres solutions.

----------

## DuF

Un petit up pour dire que je bloque toujours sur la partie virtio avec qemu (version 0.10.5 et noyau gentoo 2.6.30-r4) et qu'avec l'ebuild app-emulation/kvm ce n'est pas beaucoup mieux, mais c'est différent, donc peut être que je trouverai l'élément qui ne va pas.

Ce qui me chagrine toujours autant c'est le boot impossible sur un disque déclaré en virtio.

Pour le reste j'aurai une question, comment faire pour avoir une résolution X de l'invité supérieure à 800*600 ? J'ai essayé cirrus et std et jamais de succès.... Donc si quelqu'un a une piste je suis preneur  :Smile: 

----------

## ppg

Moi je me bat avec virt-manager pour faire des VM de plus d'un 1G il veut pas me faire autre chose   :Crying or Very sad: 

Je vais déjà essayer de faire fonctionner virt-manager + libvirt et après je m'attaque aux virtio. Sinon KVM tout seul pour l'instant ça fonctionne, mis à part que mon bridge est bancal pour le réseau (enfin en NAT ça fonctionne sans aucun soucis).

Enfin c'est pas pire que se farcir les confs des kernels pour xen.

(Snif sous debian virt-manager c'est OOTB avec zéro config, si sous debian ça fonctionne pourquoi est-ce que je galère autant   :Question:  )

----------

## man in the hill

 *DuF wrote:*   

> Ce qui me chagrine toujours autant c'est le boot impossible sur un disque déclaré en virtio

 

Le boot impossible ou seulement le disque virtio non affiché par le bios au demarrage comme c'est mon cas ci-dessous...

 *man in the hill wrote:*   

> Salut,
> 
> Faut pas se fier a ce que le bios de qemu/kvm affiche car il me détecte soit disant que le graveur mais boot quand même sur le bon dd en utilisant virtio . On vérifie avec la console alt + ctrl + 2
> 
> info kvm
> ...

 

 *DuF wrote:*   

> Pour le reste j'aurai une question, comment faire pour avoir une résolution X de l'invité supérieure à 800*600 ? J'ai essayé cirrus et std et jamais de succès.... Donc si quelqu'un a une piste je suis preneur 

 

std me met plein écran chez moi. Par contre tu peux modifier le xorg.conf de la vm avec le pilote  vesa (1024x768 fonctionne chez moi)

 *ppg wrote:*   

> Moi je me bat avec virt-manager pour faire des VM de plus d'un 1G il veut pas me faire autre chose 

 

Masque la dernière version de virt-manager !

C'est quoi ton problème de réseau ?

[EDIT] On peut monter la  résolution en utilisant l'optiopn -vga std et le pilote vesa ds la vm (je suis monté jusqu'a 1920x1200)[/EDIT]

----------

## DuF

 *man in the hill wrote:*   

> Salut,
> 
> Faut pas se fier a ce que le bios de qemu/kvm affiche car il me détecte soit disant que le graveur mais boot quand même sur le bon dd en utilisant virtio . On vérifie avec la console alt + ctrl + 2
> 
> info kvm
> ...

 

Tout le problème est justement qu'il ne boot pas du tout, le bios refuse de démarrer sur le disque. D'ailleurs dans cette configuration, si je boot sur un liveCD, toutes les distributions que j'ai testé détectes un disque mais en général refuse de s'installer dessus (en même temps c'est normal, la doc de qemu dit bien de faire l'installation en ide et le boot en virtio moyennant 2-3 modifications). Mais si au moins le bios acceptait de booter sur le disque...

----------

## engil

Salut tout le monde. J'ai une question bête, j'ai installé Qemu et crée un WinXP en VM, mais il y a une chose que je comprend pas.

Quand je vais dans les infos système du XP, il voit bien le go de ram que j'ai alloué, mais au niveau processeur il ne voit qu'un Pentium II à 369MHz ....

J'ai un C2D P8700 à 2.5GHz, j'aimerais en profiter un peu quand meme ... pour info j'ai mis le "system type" en 32bits dans qemu-launcher, est-ce que ca pourrait venir de la ? (cpu natif 64bits et guest en 32bits donc émulé ??)

----------

## kwenspc

 *engil wrote:*   

> (cpu natif 64bits et guest en 32bits donc émulé ??)

 

Non les cpu x86_64 arrive à faire tourner du 32bits nativement. 

Vérifies plutôt ta config: as-tu réussis à avoir le module kvm qui fonctionne etc... ? (suis ce topic)

----------

## engil

Bon ok, au temps pour moi ... J'avais pourtant lu le topic en entier   :Mr. Green: 

Du coup j'ai une question, les modules kvm et kvm_intel étaient déja compilés dans mon kernel, ça pas de soucis. Si je passe par qemu-launcher (en utilisateur donc), il n'utilise pas kvm. Si j'essaie via la ligne de commande, toujours en user, il me met un permission denied pour charger le module kvm (je passe -enable-kvm dans la commande). Et effectivement, via "info kvm" il est bien désactivé.

Si je lance via ligne de commande en root, avec enable-kvm, il n'arrive pas a charger tout seul le module.

```
Could not access KVM kernel module: No such file or directory
```

Une fois les modules chargés, lancement par qemu-launcher -> kvm disabled et CPU à 200MHz.

Si je lance en root avec enable-kvm, le kvm est activé mais toujours CPU à 200MHz ...

J'ai du rater quelquechose ... L'idée de base c'est quand même de pouvoir lancer une VM avec toutes les fonctions (donc usage de kvm) en tant qu'utilisateur non ? Enfin via qemu-launcher, ca devrait etre possible.

Ou alors il faut lancer qemu-launcher en root ? De toute facon je n'ai pas vu d'option équivalente à "enable-kvm" dans la GUI de qemu-launcher.

C'est un peu confus pour moi la, un peu d'éclairage sur le "comment ça devrais fonctionner" serait le bienvenu ...

----------

## kwenspc

En root faut juste : modrobe kvm et kvm_intel

Ensuite en user, qemu (iva qemu-launcher) va pouvoir l'utiliser. Sinon le cpu à 200mhz dans winodws c'est pas significatif. Tu dois le sentir tout de suite si tu as kvm ou non: sans c'est lent, avec c'est le jour et la nuit.

----------

## engil

Ok merci pour les explications  :Smile: 

Bon j'ai fait le modprobe et lancé mon XP via qemu-launcher, mais bon j'ai rien d'installé dessus et pas le net donc je vois pas trop de miracle en perf.

J'ai lancé le même après avoir déchargé les modules et il y a pas grande différence, je vais creuser un peu et je reviendrais voir ici plus tard ...

Merci kwenspc pour ton aide.

----------

## DuF

Juste pour faire un petit retour depuis tout ce temps (beaucoup de boulot et quelques semaines de vacances   :Laughing:  ).

Donc voilà, ça faisait un petit moment que j'avais pas essayé mes machines virtuelles mais comme récemment le paquet qemu a été mis à jour dans sa version 11, je me suis dit que j'allais tester de nouveau tout ça. Et bien ça fonctionne niquel. Alors bon, j'ai toujours pas le virtio, mais pour le coup je pense qu'il faudrait que reparte de zéro mais pour le reste c'est du tout bon.

La fedora 11 met moins de 30s à démarrer et à m'afficher KDE, il faudrait que je chronomètre précisément entre le moment où je lance la ligne de commande, le moment où je saisi mon mot de passe de connexion et le moment où le bureau est opérationnel car là je compte le tout, mais en tout cas c'est bien plus rapide qu'avant. L'autre point important, c'est que le pilote vidéo "vmware" me permet de choisir une résolution supérieure au 1024*768, donc ça aussi c'est une très bonne chose.

En tout cas, qemu-0.11.0 avec un noyau gentoo-sources-2.6.30-r4 pour l'hôte et un 2.6.29 pour la fedora 11 invitée c'est du tout bon.

Les seuls problèmes que j'ai noté pour l'instant, c'est la souris qui de temps en temps accélère de manière intempestive et le débit de l'interface réseau qui semble un peu en dessous de ce que l'hôte peut avoir. 

EDIT : Je viens de chronométrer le temps de démarrage de la fedora 11 chez moi. Il a fallu 11s pour obtenir l'écran de connexion et 10s supplémentaire après que j'ai eu tapé mon mot de passe pour avoir le bureau kde opérationnel. Quand je dis opérationnel, c'est avec les pop-ups et les différentes notifications qui ont finis de s'afficher. Pour info, j'ai fait ce test sur le lancement d'une seconde VM de 512Mo de ram, la première VM étant aussi une fedora 11 avec 2Go de ram lui étant allouée.

----------

## man in the hill

 *man in the hill wrote:*   

> 
> 
> [EDIT] On peut monter la  résolution en utilisant l'optiopn -vga std et le pilote vesa ds la vm (je suis monté jusqu'a 1920x1200)[/EDIT]

 

je passe aussi pour dire que n'ai pas laché l'affaire puisque j'ai mis mon premier server xeon quad core gentoo hardened avec kvm/qemu/virt-manager en prod qui virtualise un serveur sous xp pro avec le driver réseau virtio pour un logiciel d'optique.

La dernière version de virt-manager propose la fonction clonage qui est très intéressante ...

Que pensez vous de  hardened + kvm ?

@+

----------

## Leander256

Petit retour de mes aventures avec qemu + KVM.

Pour commencer j'avais un bug avec la carte réseau par défaut (ne2k_pci). Au bout d'un certain volume de données transféré, le périphérique tap ne semblait plus fonctionner correctement (il envoyait des requêtes ARP mais ne semblait pas lire les réponses). Je lance donc maintenant avec l'émulation d'une e1000 et tout se passe pour le mieux.

J'ai surtout un gros problème avec les pilotes vidéo. D'abord pour me mettre en situation, j'ai un écran en 1280x800 et une carte i965, ce qui signifie d'après ce que j'ai trouvé que le firmware ne connaît pas le mode VESA pour la résolution native. En client dans la VM j'ai une Lenny (pas besoin de plus récent). J'ai donc essayé:

vga cirrus : je n'ai pas réussi à dépasser le 800x600

vga std : j'ai du 1024x768 après avoir sélectionné le pilote vesa dans le xorg.conf (merci man in the hill pour l'avoir suggéré) mais le 1280x800 ne passe pas. D'autre part, quand je passe l'application en plein écran c'est le drame (affichage complètement corrompu).

vga vmware : j'ai du 1280x800 mais au bout d'un temps aléatoire qemu part dans une boucle infinie dans le pilote (j'ai fait un backtrace et je tenterai de gérer ça avec l'upstream ce soir). En plus de ça il arrive que les changements de résolution corrompent l'affichage et que je doive alterner plusieurs fois entre la VM et le shell de qemu (celui avec ctrl+alt+2) pour qu'enfin l'affichage soit correct.

Mis à part ça, je suis vraiment emballé par les performances et j'essaye de finaliser des scripts pour gérer de manière plus automatique les VMs. Les deux principales différences entre ma config et celle qu'on trouve sur le wiki (ou le net, en général):

qemu utilise une partition au lieu d'un fichier image: c'est faisable si l'utilisateur a les droits d'écriture sur les partitions, je préfère cette solution parce que j'ai un système déjà un poil compliqué (LVM2/cryptfs) donc je n'avais pas envie de rajouter une couche lors des accès disque (mais il faudrait que je compare avec un fichier image pour être certain d'y gagner)

le bridge n'intègre pas ma carte réseau: je fais un masquerading des familles parce que je n'ai pas envie d'exposer toutes mes VMs au monde extérieur, en plus ça me permet de faire tourner des services uniquement sur l'interface du bridge (dnsmasq pour le DNS et le DHCP par exemple). Je suis parfois branché sur eth0, parfois sur wlan0, il me faudra trouver un moyen efficace de changer la règle iptables à chaque fois que je me connecte

----------

## Possum

À moi d'exhumer ce post fort intéressant.

Replaçons le contexte.

J'utilise kvm à la maison et au boulot.  Bien sûr, en utilisant Gentoo comme hôte, ~arch à la maison, kvm et la libvirt démasqués au boulot.

Au boulot, nous virtualisons des FreeBSD, c'est con, du coup, on ne peut pas profiter des pilotes virtio, mais bon, ça marche quand même plus que correctement.

À la maison, j'utilise principalement kvm pour tester les nouvelles distributions ou certaines configs spécifiques.

Enfin, tout ce blabla pour dire que nulle part je ne vous ai vu aborder l'outil fort sympathique qu'est virt-install qui permet de rapidement installer une machine avec la libvirt.

Exemple d'une commande que je viens de passer à l'instant pour installer un OpenSolaris:

```

virt-install --connect qemu:///system \

--name opensolaris \

--ram 2048 \

--vcpus=2 \

--os-type=solaris \

--os-variant=opensolaris \

--hvm \

--virt-type kvm \

--cdrom /mnt/repository/isos/OpenSolaris/osol-0906-x86.iso \

--disk path=/mnt/repository/VMs/opensolaris.img \

--network=bridge=br0,model=rtl8139 \

--keymap=fr
```

Ceci m'amène à deux tips pour ceux qui voudraient utiliser virt-install:

Si comme moi, vous êtes en arch, il faut faire un lien symbolique /usr/bin/qemu-kvm -> /usr/bin/qemu-system-x86_64 Bug #294169

Pour utiliser virt-viewer pour afficher la console, il faut un USE="-nsplugin" voir  Bug #280167

Je n'ai pas encore vraiment fait mumuse avec les options graphiques contrairement à Leander juste au dessus, vu que, en général, ce sont des serveurs que j'installe, mais un jour, ça viendra  :Smile: 

Bref, tout ça pour dire, kvm, que du bonheur.

----------

## man in the hill

Je n'ai pas encore eu le temps d'expérimenté virt-install ...

 *Possum wrote:*   

> [*]Si comme moi, vous êtes en arch, il faut faire un lien symbolique /usr/bin/qemu-kvm -> /usr/bin/qemu-system-x86_64 Bug #294169

 

Avec le passage qemu-kvm, tu m'as enlevé une vrai épine du pied , thx .

 *Possum wrote:*   

> 
> 
> Bref, tout ça pour dire, kvm, que du bonheur.

 

D'accord avec toi !

----------

## kwenspc

Avez vous l'usb qui fonctionne sans problème?

Voilà où j'en suis rendu: qemu "nécessiterait" usbfs, qui est déprécié dans le kernel. Sans cet usbfs, pas d'arborescence /proc/bus/usb. 

En fait, même sans cet usbfs dans le noyau qemu arrive bien à lister les usb host. Cependant (et oui je fais bien parti du groupe usb, qemu et kvm) pas moyen d'ajouter un device dans le guest. Voici le message:

 *Quote:*   

> 
> 
> husb: open device 2.2
> 
> husb: config #1 need -1
> ...

 

Donc à mon avis c'est plus une erreur d'interfacage qemu avec usbdevfs. 

Vous avez réussis vous?

[edit] toujours la même erreur avec qemu-kvm en ~arch. Le mieux c'est qu'on trouve strictement rien sur le net au sujet de ce message d'erreur...[/edit]

----------

## Possum

 *kwenspc wrote:*   

> Avez vous l'usb qui fonctionne sans problème?
> 
> Vous avez réussis vous?
> 
> [edit] toujours la même erreur avec qemu-kvm en ~arch. Le mieux c'est qu'on trouve strictement rien sur le net au sujet de ce message d'erreur...[/edit]

 

J'avoue ne pas avoir essayé du tout.

Mais rapide recherche, avec la libvirt, as-tu déclaré ton machin usb comme ceci:

```

<hostdev mode='subsystem' type='usb'>

    <source>

        <vendor id='0x1234'/>

        <product id='0xbeef'/>

    </source>

</hostdev>

```

En remplaçant bien sûr par les vendor id et product id de ton périph usb ?

----------

## kwenspc

 *Possum wrote:*   

> 
> 
> Mais rapide recherche, avec la libvirt, as-tu déclaré ton machin usb comme ceci:
> 
> 

 

la libvirt n'est qu'un "frontend", et je ne l'utilise pas (je ne gère pax n VM sur mon desktop, juste une de temps à autre...)

Donc ça ne change rien au problème qui vient de l'interfaçage qemu vs usbdevfs  :Wink: 

----------

## man in the hill

 *kwenspc wrote:*   

>  *Possum wrote:*   
> 
> Mais rapide recherche, avec la libvirt, as-tu déclaré ton machin usb comme ceci:
> 
>  
> ...

 

D'ailleurs libvirt peut foutre la mer** ... car cela rajoute encore une couche d'abstraction entre  kvm/qemu.

J'ai  3 serveurs gentoo hardened-patché-grsec xeon quad en prod avec chacun une vm serveur et j'ai constaté que libvirt plantait la vm de temps en temps et depuis que je suis passé en total qemu-kvm en ligne de commande via mes scripts , mes vm ne plante plus .

@kwenspc: J'avais essayé il y a un certain temps et ça n'était pas convainquant donc je m'étais résolu à utiliser que le réseau, je ferais qques tests bientôt. 

ps: pour ceux qui veulent les pilotes virtio pour ms windows

http://www.linux-kvm.com/

----------

## kwenspc

 *man in the hill wrote:*   

> 
> 
> @kwenspc: J'avais essayé il y a un certain temps et ça n'était pas convainquant donc je m'étais résolu à utiliser que le réseau, je ferais qques tests bientôt. 
> 
> 

 

Apparemment c'est un problème uniquement au niveau du host. Je vais mettre à jour mon noyau (je tourne encore sur un 2.6.29...) ça va peut être résoudre le problème.

----------

## kwenspc

Bon ça marche parfaitement, reemerge de la libusb, version 0.12.2-r2 de qemu-kvm et rulez  :Smile: 

----------

## Winnt

Salut,

 *kwenspc wrote:*   

> Bon ça marche parfaitement, reemerge de la libusb, version 0.12.2-r2 de qemu-kvm et rulez 

 

Ben vous avez de la chance parce que moi la version 0.12.2-r2 de qemu-kvm plante lamentablement à la compilation. Je me suis pourtant pris la tête à démasquer tout ce qu'il fallait mais rien à faire.

Enfin j'ai tout de même réussi à installer virtualbox 3.0.12 à défaut cela fera l'affaire.

----------

## kwenspc

tu peux copier le message d'erreur à la compil?

----------

## Winnt

Salut,

 *kwenspc wrote:*   

> tu peux copier le message d'erreur à la compil?

 

Bien sûr mais pas avant être rentré chez moi ce soir.

----------

## Winnt

Bonsoir,

Voici ce que me sort la compil comme message d'erreur

```
 LINK  mips-softmmu/qemu-system-mips

  LINK  mipsel-softmmu/qemu-system-mipsel

  LINK  arm-softmmu/qemu-system-arm

 * ERROR: app-emulation/qemu-kvm-0.12.2-r2 failed:

 *   emake failed

 * 

 * Call stack:

 *     ebuild.sh, line   54:  Called src_compile

 *   environment, line 3568:  Called _eapi2_src_compile

 *     ebuild.sh, line  646:  Called die

 * The specific snippet of code:

 *         emake || die "emake failed"

 * 

 * If you need support, post the output of 'emerge --info =app-emulation/qemu-kvm-0.12.2-r2',

 * the complete build log and the output of 'emerge -pqv =app-emulation/qemu-kvm-0.12.2-r2'.

 * The complete build log is located at '/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/temp/build.log'.

 * The ebuild environment file is located at '/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/temp/environment'.

 * S: '/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2'

>>> Failed to emerge app-emulation/qemu-kvm-0.12.2-r2, Log file:

>>>  '/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/temp/build.log'

 * Messages for package net-misc/bridge-utils-1.4:

 * This package no longer provides a separate init script.

 * Please utilize the new bridge support in baselayout.

 * Messages for package app-emulation/qemu-kvm-0.12.2-r2:

 * ERROR: app-emulation/qemu-kvm-0.12.2-r2 failed:

 *   emake failed

 * 

 * Call stack:

 *     ebuild.sh, line   54:  Called src_compile

 *   environment, line 3568:  Called _eapi2_src_compile

 *     ebuild.sh, line  646:  Called die

 * The specific snippet of code:

 *         emake || die "emake failed"

 * 

 * If you need support, post the output of 'emerge --info =app-emulation/qemu-kvm-0.12.2-r2',

 * the complete build log and the output of 'emerge -pqv =app-emulation/qemu-kvm-0.12.2-r2'.

 * The complete build log is located at '/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/temp/build.log'.

 * The ebuild environment file is located at '/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/temp/environment'.

 * S: '/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2'

```

----------

## kwenspc

Emerge qui quitte c'est jamais très parlant, tu peux nous passer genre les 50 ou 100 dernières lignes de: 

 *Quote:*   

> emerge -pqv =app-emulation/qemu-kvm-0.12.2-r2

 

Ou du fichier  *Quote:*   

> /var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/temp/build.log

 

----------

## Winnt

Bonsoir,

voici "/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/temp/build.log" comme demandé.

```
 * CPV:  app-emulation/qemu-kvm-0.12.2-r2

 * REPO: gentoo

 * USE:  aio alsa amd64 bluetooth elibc_glibc esd fdt kernel_linux multilib ncurses pulseaudio qemu_softmmu_targets_arm qemu_softmmu_targets_cris qemu_softmmu_targets_i386 qemu_softmmu_targets_m68k qemu_softmmu_targets_microblaze qemu_softmmu_targets_mips qemu_softmmu_targets_mips64 qemu_softmmu_targets_mips64el qemu_softmmu_targets_mipsel qemu_softmmu_targets_ppc qemu_softmmu_targets_ppc64 qemu_softmmu_targets_ppcemb qemu_softmmu_targets_sh4 qemu_softmmu_targets_sh4eb qemu_softmmu_targets_sparc qemu_softmmu_targets_sparc64 qemu_softmmu_targets_x86_64 qemu_user_targets_alpha qemu_user_targets_arm qemu_user_targets_armeb qemu_user_targets_cris qemu_user_targets_i386 qemu_user_targets_m68k qemu_user_targets_microblaze qemu_user_targets_mips qemu_user_targets_mipsel qemu_user_targets_ppc qemu_user_targets_ppc64 qemu_user_targets_ppc64abi32 qemu_user_targets_sh4 qemu_user_targets_sh4eb qemu_user_targets_sparc qemu_user_targets_sparc32plus qemu_user_targets_sparc64 qemu_user_targets_x86_64 sdl userland_GNU vde

 * Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Found kernel object directory:

 *     /lib/modules/2.6.32-gentoo-r7/build

 * Found sources for kernel version:

 *     2.6.32-gentoo-r7

>>> Unpacking source...

>>> Unpacking qemu-kvm-0.12.2.tar.gz to /var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work

>>> Source unpacked in /var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work

>>> Preparing source in /var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2 ...

 * Applying qemu-0.11.0-mips64-user-fix.patch ...                                             [ ok ]

 * Applying qemu-kvm-0.12.2-virtio-large-iovecs.patch ...                                     [ ok ]

>>> Source prepared.

>>> Configuring source in /var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2 ...

 * Building the following softmmu targets:  i386-softmmu x86_64-softmmu arm-softmmu cris-softmmu m68k-softmmu microblaze-softmmu mips-softmmu mipsel-softmmu ppc-softmmu ppc64-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu sparc64-softmmu mips64-softmmu mips64el-softmmu ppcemb-softmmu

 * Building the following user targets:  i386-linux-user x86_64-linux-user arm-linux-user cris-linux-user m68k-linux-user microblaze-linux-user mips-linux-user mipsel-linux-user ppc-linux-user ppc64-linux-user sh4-linux-user sh4eb-linux-user sparc-linux-user sparc64-linux-user alpha-linux-user armeb-linux-user ppc64abi32-linux-user sparc32plus-linux-user

Install prefix    /usr

BIOS directory    /usr/share/qemu

binary directory  /usr/bin

Manual directory  /usr/share/man

ELF interp prefix /usr/gnemul/qemu-%M

Source path       /var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2

C compiler        x86_64-pc-linux-gnu-gcc

Host C compiler   x86_64-pc-linux-gnu-gcc

CFLAGS            -O2 -g -O2 -march=native -pipe

QEMU_CFLAGS       -m64 -Wold-style-definition -Wold-style-declaration -I. -I$(SRC_PATH) -U_FORTIFY_SOURCE -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wendif-labels -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing 

LDFLAGS           -Wl,--warn-common -m64 -g -Wl,-z,execheap -Wl,-O1

make              make

install           install

host CPU          x86_64

host big endian   no

target list        i386-softmmu x86_64-softmmu arm-softmmu cris-softmmu m68k-softmmu microblaze-softmmu mips-softmmu mipsel-softmmu ppc-softmmu ppc64-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu sparc64-softmmu mips64-softmmu mips64el-softmmu ppcemb-softmmu  i386-linux-user x86_64-linux-user arm-linux-user cris-linux-user m68k-linux-user microblaze-linux-user mips-linux-user mipsel-linux-user ppc-linux-user ppc64-linux-user sh4-linux-user sh4eb-linux-user sparc-linux-user sparc64-linux-user alpha-linux-user armeb-linux-user ppc64abi32-linux-user sparc32plus-linux-user

tcg debug enabled no

gprof enabled     no

sparse enabled    no

strip binaries    no

profiler          no

static build      no

-Werror enabled   no

SDL support       yes

curses support    yes

curl support      no

check support     no

mingw32 support   no

Audio drivers     sdl pa esd alsa oss

Extra audio cards ac97 es1370 sb16

Block whitelist   

Mixer emulation   no

VNC TLS support   no

VNC SASL support  no

xen support       no

CPU emulation     yes

brlapi support    no

bluez  support    yes

Documentation     yes

NPTL support      yes

GUEST_BASE        yes

PIE user targets  no

vde support       yes

IO thread         no

Linux AIO support yes

Install blobs     yes

KVM support       yes

KVM PIT support   yes

KVM device assig. yes

KVM trace support no

fdt support       yes

preadv support    yes

fdatasync         yes

uuid support      yes

>>> Source configured.

>>> Compiling source in /var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2 ...

make -j7 

  GEN   i386-softmmu/config-devices.mak

  GEN   x86_64-softmmu/config-devices.mak

  GEN   arm-softmmu/config-devices.mak

  GEN   cris-softmmu/config-devices.mak

  GEN   m68k-softmmu/config-devices.mak

  GEN   microblaze-softmmu/config-devices.mak

  GEN   mips-softmmu/config-devices.mak

  GEN   mipsel-softmmu/config-devices.mak

  GEN   ppc-softmmu/config-devices.mak

  GEN   ppc64-softmmu/config-devices.mak

  GEN   sh4-softmmu/config-devices.mak

  GEN   sh4eb-softmmu/config-devices.mak

  GEN   sparc-softmmu/config-devices.mak

  GEN   sparc64-softmmu/config-devices.mak

  GEN   mips64-softmmu/config-devices.mak

  GEN   mips64el-softmmu/config-devices.mak

  GEN   ppcemb-softmmu/config-devices.mak

  GEN   i386-linux-user/config-devices.mak

  GEN   x86_64-linux-user/config-devices.mak

  GEN   arm-linux-user/config-devices.mak

  GEN   cris-linux-user/config-devices.mak

  GEN   m68k-linux-user/config-devices.mak

  GEN   microblaze-linux-user/config-devices.mak

  GEN   mips-linux-user/config-devices.mak

  GEN   mipsel-linux-user/config-devices.mak

  GEN   ppc-linux-user/config-devices.mak

  GEN   ppc64-linux-user/config-devices.mak

  GEN   sh4-linux-user/config-devices.mak

  GEN   sh4eb-linux-user/config-devices.mak

  GEN   sparc64-linux-user/config-devices.mak

  GEN   sparc-linux-user/config-devices.mak

  GEN   alpha-linux-user/config-devices.mak

  GEN   armeb-linux-user/config-devices.mak

  GEN   ppc64abi32-linux-user/config-devices.mak

  GEN   sparc32plus-linux-user/config-devices.mak

  GEN   config-all-devices.mak

  GEN   qemu-options.texi

  GEN   qemu-monitor.texi

  GEN   qemu-img-cmds.texi

  GEN   qemu-tech.html

  GEN   qemu-nbd.8

  GEN   config-host.h

  GEN   qemu-img-cmds.h

  GEN   qemu-img.1

  AS    optionrom/multiboot.o

  CC    qemu-nbd.o

  CC    qemu-tool.o

  AS    optionrom/linuxboot.o

  AS    optionrom/extboot.o

  AS    optionrom/vapic.o

  Building optionrom/multiboot.img

  Building optionrom/linuxboot.img

  Building optionrom/extboot.img

  CC    cutils.o

  Building optionrom/vapic.img

  Building optionrom/multiboot.raw

  CC    cache-utils.o

  CC    qemu-malloc.o

  Building optionrom/linuxboot.raw

  Building optionrom/extboot.raw

  Building optionrom/vapic.raw

  Signing optionrom/multiboot.bin

  CC    qemu-option.o

  CC    module.o

  Signing optionrom/linuxboot.bin

  CC    nbd.o

  CC    block.o

  Signing optionrom/extboot.bin

  CC    aio.o

  CC    aes.o

  Signing optionrom/vapic.bin

  CC    osdep.o

  CC    posix-aio-compat.o

  CC    linux-aio.o

  CC    compatfd.o

  CC    block/cow.o

  CC    block/qcow.o

  CC    block/vdi.o

  CC    block/vmdk.o

  CC    block/cloop.o

  CC    block/dmg.o

  CC    block/bochs.o

  CC    block/vpc.o

  CC    block/vvfat.o

  CC    block/qcow2.o

  CC    block/qcow2-refcount.o

  CC    block/qcow2-cluster.o

  CC    block/qcow2-snapshot.o

  CC    block/parallels.o

  CC    block/nbd.o

  CC    block/raw-posix.o

  CC    qint.o

  CC    qstring.o

  CC    qdict.o

  CC    qlist.o

  CC    qfloat.o

  CC    qbool.o

  CC    json-lexer.o

  CC    json-streamer.o

  CC    qjson.o

  CC    json-parser.o

  CC    qerror.o

  CC    qemu-img.o

  CC    qemu-io.o

  CC    cmd.o

  CC    libhw64/loader.o

  CC    libhw64/virtio.o

  CC    libhw64/fw_cfg.o

  CC    libhw64/watchdog.o

  CC    libhw64/ecc.o

  CC    libhw64/nand.o

  CC    net.o

  CC    libhw64/m48t59.o

  CC    net/queue.o

  CC    libhw64/escc.o

  CC    net/checksum.o

  CC    libhw64/wdt_i6300esb.o

  CC    libhw64/ne2000.o

  CC    net/util.o

  CC    libhw64/smc91c111.o

  CC    net/socket.o

  CC    net/dump.o

  CC    libhw64/lan9118.o

  CC    net/tap.o

  CC    libhw64/lsi53c895a.o

  CC    libhw64/esp.o

  CC    net/tap-linux.o

  CC    net/slirp.o

  CC    libhw64/dma-helpers.o

  CC    libhw64/sysbus.o

  CC    libhw64/isa-bus.o

  CC    net/vde.o

  CC    readline.o

  CC    console.o

  CC    libhw64/qdev-addr.o

  CC    tcg-runtime.o

  CC    host-utils.o

  CC    irq.o

  CC    ioport.o

  CC    ptimer.o

  AR    libhw64/libqemuhw64.a

  CC    max7310.o

  CC    wm8750.o

  CC    twl92230.o

  CC    tsc2005.o

  CC    lm832x.o

  CC    tmp105.o

  CC    stellaris_input.o

  CC    ads7846.o

  CC    ds1338.o

  CC    max111x.o

  CC    i2c.o

  CC    smbus.o

  CC    smbus_eeprom.o

  CC    eeprom93xx.o

  CC    scsi-disk.o

  CC    cdrom.o

  CC    scsi-generic.o

  CC    scsi-bus.o

  CC    usb.o

  CC    usb-hub.o

  CC    usb-linux.o

  CC    usb-hid.o

  CC    usb-msd.o

  CC    usb-wacom.o

  CC    usb-serial.o

  CC    usb-net.o

  CC    usb-bus.o

  CC    ssi.o

  CC    ssi-sd.o

  CC    sd.o

  CC    bt.o

  CC    bt-host.o

  CC    bt-vhci.o

  CC    bt-l2cap.o

  CC    bt-sdp.o

  CC    bt-hci.o

  CC    bt-hid.o

  CC    usb-bt.o

  CC    bt-hci-csr.o

  CC    buffered_file.o

  CC    migration.o

  CC    migration-tcp.o

  CC    qemu-sockets.o

  CC    qemu-char.o

  CC    savevm.o

  CC    msmouse.o

  CC    ps2.o

  CC    qdev.o

  CC    qdev-properties.o

  CC    qemu-config.o

  CC    block-migration.o

  CC    migration-exec.o

  CC    migration-fd.o

  CC    migration-unix.o

  CC    audio/audio.o

  CC    audio/noaudio.o

  CC    audio/wavaudio.o

  CC    audio/mixeng.o

  CC    audio/sdlaudio.o

  CC    audio/ossaudio.o

  CC    audio/alsaaudio.o

  CC    audio/esdaudio.o

  CC    audio/paaudio.o

  CC    audio/audio_pt_int.o

  CC    audio/wavcapture.o

  CC    keymaps.o

  CC    sdl.o

  CC    sdl_zoom.o

  CC    x_keymap.o

  CC    curses.o

  CC    vnc.o

  CC    acl.o

  CC    d3des.o

  CC    slirp/cksum.o

  CC    slirp/if.o

  CC    slirp/ip_icmp.o

  CC    slirp/ip_input.o

  CC    slirp/ip_output.o

  CC    slirp/slirp.o

  CC    slirp/mbuf.o

  CC    slirp/misc.o

  CC    slirp/sbuf.o

  CC    slirp/socket.o

  CC    slirp/tcp_input.o

  CC    slirp/tcp_output.o

  CC    slirp/tcp_subr.o

  CC    slirp/tcp_timer.o

  CC    slirp/udp.o

  CC    slirp/bootp.o

  CC    slirp/tftp.o

  CC    libuser/envlist.o

  GEN   qemu-doc.html

  CC    libuser/path.o

  CC    libuser/tcg-runtime.o

  CC    libuser/host-utils.o

  GEN   qemu.1

  CC    libuser/cutils.o

  CC    libuser/cache-utils.o

  LINK  qemu-nbd

  LINK  qemu-img

  LINK  qemu-io

  AR    libuser/libuser.a

  AR    libqemu_common.a

  GEN   config-target.h

  CC    i386-linux-user/main.o

  GEN   config-target.h

  GEN   config-target.h

  GEN   arm-linux-user/gdbstub-xml.c

  CC    x86_64-linux-user/main.o

  GEN   config-target.h

  CC    cris-linux-user/main.o

  CC    i386-linux-user/syscall.o

  CC    arm-linux-user/main.o

  CC    cris-linux-user/syscall.o

  CC    x86_64-linux-user/syscall.o

  GEN   config-target.h

  GEN   m68k-linux-user/gdbstub-xml.c

  CC    m68k-linux-user/main.o

  CC    arm-linux-user/syscall.o

  CC    m68k-linux-user/syscall.o

  CC    cris-linux-user/strace.o

  CC    i386-linux-user/strace.o

  CC    cris-linux-user/mmap.o

  CC    x86_64-linux-user/strace.o

  CC    m68k-linux-user/strace.o

  CC    arm-linux-user/strace.o

  CC    arm-linux-user/mmap.o

  CC    x86_64-linux-user/mmap.o

  GEN   config-target.h

  CC    microblaze-linux-user/main.o

  CC    i386-linux-user/mmap.o

  CC    cris-linux-user/signal.o

  CC    x86_64-linux-user/signal.o

  CC    arm-linux-user/signal.o

  CC    m68k-linux-user/mmap.o

  CC    cris-linux-user/thunk.o

  CC    microblaze-linux-user/syscall.o

  CC    x86_64-linux-user/thunk.o

  CC    arm-linux-user/thunk.o

  CC    cris-linux-user/elfload.o

  CC    arm-linux-user/elfload.o

  CC    m68k-linux-user/signal.o

  CC    i386-linux-user/signal.o

  CC    x86_64-linux-user/elfload.o

  CC    microblaze-linux-user/strace.o

  CC    cris-linux-user/linuxload.o

  CC    arm-linux-user/linuxload.o

  CC    m68k-linux-user/thunk.o

  CC    x86_64-linux-user/linuxload.o

  CC    i386-linux-user/thunk.o

  CC    arm-linux-user/uaccess.o

  CC    cris-linux-user/uaccess.o

  CC    microblaze-linux-user/mmap.o

  CC    m68k-linux-user/elfload.o

  CC    i386-linux-user/elfload.o

  CC    i386-linux-user/linuxload.o

  CC    m68k-linux-user/linuxload.o

  CC    x86_64-linux-user/uaccess.o

  CC    arm-linux-user/gdbstub.o

  CC    cris-linux-user/gdbstub.o

  CC    microblaze-linux-user/signal.o

  CC    i386-linux-user/uaccess.o

  CC    x86_64-linux-user/gdbstub.o

  CC    m68k-linux-user/uaccess.o

  CC    cris-linux-user/exec.o

  CC    i386-linux-user/gdbstub.o

  CC    microblaze-linux-user/thunk.o

  CC    m68k-linux-user/gdbstub.o

  CC    x86_64-linux-user/ioport-user.o

  CC    arm-linux-user/flatload.o

  CC    microblaze-linux-user/elfload.o

  CC    x86_64-linux-user/exec.o

  CC    arm-linux-user/gdbstub-xml.o

  CC    microblaze-linux-user/linuxload.o

  CC    i386-linux-user/vm86.o

  CC    x86_64-linux-user/cpu-exec.o

  CC    m68k-linux-user/flatload.o

  CC    arm-linux-user/nwfpe/fpa11.o

  CC    m68k-linux-user/gdbstub-xml.o

  CC    arm-linux-user/nwfpe/fpa11_cpdo.o

  CC    m68k-linux-user/m68k-sim.o

  CC    microblaze-linux-user/uaccess.o

  CC    cris-linux-user/cpu-exec.o

  CC    x86_64-linux-user/translate-all.o

  CC    i386-linux-user/ioport-user.o

  CC    m68k-linux-user/m68k-semi.o

  CC    microblaze-linux-user/gdbstub.o

  CC    i386-linux-user/exec.o

  CC    x86_64-linux-user/translate.o

  CC    cris-linux-user/translate-all.o

  CC    arm-linux-user/nwfpe/fpa11_cpdt.o

  CC    microblaze-linux-user/flatload.o

  CC    m68k-linux-user/exec.o

  CC    cris-linux-user/translate.o

  CC    arm-linux-user/nwfpe/fpa11_cprt.o

  CC    microblaze-linux-user/exec.o

  CC    i386-linux-user/cpu-exec.o

  CC    cris-linux-user/tcg/tcg.o

  CC    arm-linux-user/nwfpe/fpopcode.o

  CC    arm-linux-user/nwfpe/single_cpdo.o

  CC    i386-linux-user/translate-all.o

  CC    m68k-linux-user/cpu-exec.o

  CC    microblaze-linux-user/cpu-exec.o

  CC    arm-linux-user/nwfpe/double_cpdo.o

  CC    i386-linux-user/translate.o

  CC    microblaze-linux-user/translate-all.o

  CC    microblaze-linux-user/translate.o

  CC    i386-linux-user/tcg/tcg.o

  CC    cris-linux-user/fpu/softfloat-native.o

  CC    arm-linux-user/nwfpe/extended_cpdo.o

  CC    m68k-linux-user/translate-all.o

  CC    microblaze-linux-user/tcg/tcg.o

  CC    x86_64-linux-user/tcg/tcg.o

  CC    cris-linux-user/op_helper.o

  CC    i386-linux-user/fpu/softfloat-native.o

  CC    microblaze-linux-user/fpu/softfloat.o

  CC    arm-linux-user/arm-semi.o

  CC    arm-linux-user/exec.o

  CC    microblaze-linux-user/op_helper.o

  CC    cris-linux-user/helper.o

  CC    m68k-linux-user/translate.o

  CC    i386-linux-user/op_helper.o

  CC    i386-linux-user/helper.o

  CC    microblaze-linux-user/helper.o

  CC    x86_64-linux-user/fpu/softfloat-native.o

  CC    arm-linux-user/cpu-exec.o

  CC    m68k-linux-user/tcg/tcg.o

  CC    microblaze-linux-user/disas.o

  CC    x86_64-linux-user/op_helper.o

  CC    i386-linux-user/disas.o

  CC    arm-linux-user/translate-all.o

  CC    cris-linux-user/disas.o

  CC    i386-linux-user/i386-dis.o

  CC    microblaze-linux-user/i386-dis.o

  CC    arm-linux-user/translate.o

  CC    cris-linux-user/cris-dis.o

  CC    m68k-linux-user/fpu/softfloat.o

  CC    cris-linux-user/i386-dis.o

  CC    m68k-linux-user/op_helper.o

  CC    x86_64-linux-user/helper.o

  AR    i386-linux-user/libqemu.a

  LINK  i386-linux-user/qemu-i386

  CC    x86_64-linux-user/disas.o

  CC    microblaze-linux-user/microblaze-dis.o

  CC    x86_64-linux-user/i386-dis.o

  CC    m68k-linux-user/helper.o

  GEN   config-target.h

  AR    cris-linux-user/libqemu.a

  CC    mips-linux-user/main.o

  LINK  cris-linux-user/qemu-cris

  AR    x86_64-linux-user/libqemu.a

  LINK  x86_64-linux-user/qemu-x86_64

  CC    m68k-linux-user/disas.o

  CC    m68k-linux-user/i386-dis.o

  CC    arm-linux-user/tcg/tcg.o

  CC    arm-linux-user/fpu/softfloat.o

  CC    mips-linux-user/syscall.o

  CC    arm-linux-user/op_helper.o

  GEN   config-target.h

  CC    mipsel-linux-user/main.o

  CC    mips-linux-user/strace.o

  CC    mipsel-linux-user/syscall.o

  CC    m68k-linux-user/m68k-dis.o

  AR    microblaze-linux-user/libqemu.a

  LINK  microblaze-linux-user/qemu-microblaze

  CC    mips-linux-user/mmap.o

  GEN   config-target.h

  GEN   ppc-linux-user/gdbstub-xml.c

  CC    mips-linux-user/signal.o

  CC    mipsel-linux-user/strace.o

  CC    ppc-linux-user/main.o

  AR    m68k-linux-user/libqemu.a

  LINK  m68k-linux-user/qemu-m68k

  CC    ppc-linux-user/syscall.o

  CC    arm-linux-user/helper.o

  CC    mips-linux-user/thunk.o

  CC    arm-linux-user/neon_helper.o

  CC    arm-linux-user/iwmmxt_helper.o

  CC    mipsel-linux-user/mmap.o

  CC    mipsel-linux-user/signal.o

  CC    mipsel-linux-user/thunk.o

  CC    mips-linux-user/elfload.o

  CC    ppc-linux-user/strace.o

  GEN   config-target.h

  GEN   ppc64-linux-user/gdbstub-xml.c

  CC    mips-linux-user/linuxload.o

  CC    mips-linux-user/uaccess.o

  CC    ppc64-linux-user/main.o

  CC    ppc64-linux-user/syscall.o

  CC    mipsel-linux-user/elfload.o

  CC    mips-linux-user/gdbstub.o

  CC    arm-linux-user/disas.o

  CC    ppc-linux-user/mmap.o

  CC    arm-linux-user/arm-dis.o

  CC    mips-linux-user/exec.o

  CC    mipsel-linux-user/linuxload.o

  CC    ppc64-linux-user/strace.o

  CC    mips-linux-user/cpu-exec.o

  CC    ppc-linux-user/signal.o

  CC    mips-linux-user/translate-all.o

  CC    ppc-linux-user/thunk.o

  CC    arm-linux-user/i386-dis.o

  CC    ppc64-linux-user/mmap.o

  CC    mipsel-linux-user/uaccess.o

  CC    mips-linux-user/translate.o

  CC    mipsel-linux-user/gdbstub.o

  CC    ppc64-linux-user/signal.o

  CC    ppc64-linux-user/thunk.o

  CC    ppc-linux-user/elfload.o

  CC    mipsel-linux-user/exec.o

  CC    mipsel-linux-user/cpu-exec.o

  CC    mips-linux-user/tcg/tcg.o

  AR    arm-linux-user/libqemu.a

  CC    ppc-linux-user/linuxload.o

  LINK  arm-linux-user/qemu-arm

  CC    mipsel-linux-user/translate-all.o

  CC    ppc64-linux-user/elfload.o

  GEN   config-target.h

  CC    sh4-linux-user/main.o

  CC    ppc64-linux-user/linuxload.o

  CC    sh4-linux-user/syscall.o

  CC    ppc-linux-user/uaccess.o

  CC    sh4-linux-user/strace.o

  CC    mips-linux-user/fpu/softfloat.o

  CC    mips-linux-user/op_helper.o

  CC    mipsel-linux-user/translate.o

  CC    ppc64-linux-user/uaccess.o

  CC    ppc-linux-user/gdbstub.o

  CC    sh4-linux-user/mmap.o

  CC    ppc-linux-user/gdbstub-xml.o

  CC    ppc-linux-user/exec.o

  CC    mipsel-linux-user/tcg/tcg.o

  CC    ppc64-linux-user/gdbstub.o

  CC    ppc64-linux-user/gdbstub-xml.o

  CC    ppc64-linux-user/exec.o

  CC    sh4-linux-user/signal.o

  CC    mips-linux-user/helper.o

  CC    mips-linux-user/disas.o

  CC    mipsel-linux-user/fpu/softfloat.o

  CC    mips-linux-user/i386-dis.o

  CC    sh4-linux-user/thunk.o

  CC    ppc64-linux-user/translate-all.o

  CC    ppc64-linux-user/cpu-exec.o

  CC    ppc-linux-user/cpu-exec.o

  CC    sh4-linux-user/elfload.o

  CC    ppc-linux-user/translate-all.o

  CC    ppc64-linux-user/translate.o

  CC    mips-linux-user/mips-dis.o

  CC    sh4-linux-user/linuxload.o

  CC    mipsel-linux-user/op_helper.o

  CC    ppc-linux-user/translate.o

rm extboot.img vapic.o multiboot.o extboot.o linuxboot.raw linuxboot.img vapic.raw vapic.img multiboot.raw extboot.raw multiboot.img linuxboot.o

  CC    ppc-linux-user/tcg/tcg.o

  CC    sh4-linux-user/uaccess.o

  CC    sh4-linux-user/gdbstub.o

  GEN   config-target.h

  CC    mipsel-linux-user/helper.o

  AR    mips-linux-user/libqemu.a

  GEN   config-target.h

  LINK  mips-linux-user/qemu-mips

  CC    sh4eb-linux-user/main.o

  CC    sparc-linux-user/main.o

  CC    sh4-linux-user/flatload.o

  CC    sh4-linux-user/exec.o

  CC    mipsel-linux-user/disas.o

  CC    sparc-linux-user/syscall.o

  CC    mipsel-linux-user/i386-dis.o

  CC    mipsel-linux-user/mips-dis.o

  CC    ppc64-linux-user/tcg/tcg.o

  CC    ppc64-linux-user/fpu/softfloat.o

  CC    sh4eb-linux-user/syscall.o

  CC    ppc64-linux-user/op_helper.o

  CC    ppc64-linux-user/helper.o

  CC    ppc64-linux-user/disas.o

  CC    ppc64-linux-user/i386-dis.o

  CC    sh4-linux-user/cpu-exec.o

  GEN   config-target.h

  CC    sparc64-linux-user/main.o

  CC    ppc64-linux-user/ppc-dis.o

  AR    mipsel-linux-user/libqemu.a

  LINK  mipsel-linux-user/qemu-mipsel

  CC    sparc64-linux-user/syscall.o

  CC    ppc-linux-user/fpu/softfloat.o

  CC    sh4eb-linux-user/strace.o

  CC    sh4eb-linux-user/mmap.o

  CC    sparc64-linux-user/strace.o

  AR    ppc64-linux-user/libqemu.a

  CC    sparc64-linux-user/mmap.o

  CC    sparc-linux-user/strace.o

  CC    ppc-linux-user/op_helper.o

  CC    sh4-linux-user/translate-all.o

  CC    sparc-linux-user/mmap.o

  LINK  ppc64-linux-user/qemu-ppc64

  CC    ppc-linux-user/helper.o

  CC    sh4-linux-user/translate.o

  CC    sh4eb-linux-user/signal.o

  CC    sparc64-linux-user/signal.o

  CC    sparc-linux-user/signal.o

  CC    ppc-linux-user/disas.o

  CC    sh4eb-linux-user/thunk.o

  CC    sparc64-linux-user/thunk.o

  CC    sh4eb-linux-user/elfload.o

  CC    sparc64-linux-user/elfload.o

  CC    sh4eb-linux-user/linuxload.o

  CC    ppc-linux-user/i386-dis.o

  CC    sh4-linux-user/tcg/tcg.o

  CC    sparc-linux-user/thunk.o

  CC    ppc-linux-user/ppc-dis.o

  CC    sparc-linux-user/elfload.o

  CC    sh4eb-linux-user/uaccess.o

  GEN   config-target.h

  CC    alpha-linux-user/main.o

  CC    alpha-linux-user/syscall.o

  CC    sparc64-linux-user/linuxload.o

  AR    ppc-linux-user/libqemu.a

  LINK  ppc-linux-user/qemu-ppc

  CC    sh4eb-linux-user/gdbstub.o

  CC    sparc64-linux-user/uaccess.o

  CC    sh4eb-linux-user/exec.o

  CC    sh4eb-linux-user/flatload.o

  CC    sparc-linux-user/linuxload.o

  CC    sh4-linux-user/fpu/softfloat-native.o

  CC    sparc-linux-user/uaccess.o

  CC    alpha-linux-user/strace.o

  CC    alpha-linux-user/mmap.o

  CC    sparc64-linux-user/gdbstub.o

  CC    sparc-linux-user/gdbstub.o

  CC    sparc64-linux-user/elfload32.o

  CC    sparc-linux-user/exec.o

  CC    sh4-linux-user/op_helper.o

  CC    sh4-linux-user/helper.o

  CC    sh4eb-linux-user/cpu-exec.o

  GEN   config-target.h

  CC    alpha-linux-user/signal.o

  GEN   armeb-linux-user/gdbstub-xml.c

  CC    sparc-linux-user/cpu-exec.o

  CC    sh4eb-linux-user/translate-all.o

  CC    alpha-linux-user/thunk.o

  CC    armeb-linux-user/main.o

  CC    sh4eb-linux-user/translate.o

  CC    sh4eb-linux-user/tcg/tcg.o

  CC    sparc64-linux-user/exec.o

  CC    sh4-linux-user/disas.o

  CC    sparc-linux-user/translate-all.o

  CC    alpha-linux-user/elfload.o

  CC    sparc-linux-user/translate.o

  CC    sh4-linux-user/i386-dis.o

  CC    sh4-linux-user/sh4-dis.o

  CC    armeb-linux-user/syscall.o

  CC    sparc64-linux-user/cpu-exec.o

  CC    alpha-linux-user/linuxload.o

  CC    alpha-linux-user/uaccess.o

  CC    sh4eb-linux-user/fpu/softfloat-native.o

  CC    sparc-linux-user/tcg/tcg.o

  CC    sparc-linux-user/fpu/softfloat.o

  CC    armeb-linux-user/strace.o

  CC    sparc64-linux-user/translate-all.o

  AR    sh4-linux-user/libqemu.a

  CC    alpha-linux-user/gdbstub.o

  CC    sparc64-linux-user/translate.o

  CC    sh4eb-linux-user/op_helper.o

  CC    armeb-linux-user/mmap.o

  CC    armeb-linux-user/signal.o

  CC    sparc64-linux-user/tcg/tcg.o

  CC    sh4eb-linux-user/helper.o

  CC    sparc-linux-user/op_helper.o

  CC    sparc-linux-user/helper.o

  LINK  sh4-linux-user/qemu-sh4

  CC    sh4eb-linux-user/disas.o

  CC    sh4eb-linux-user/i386-dis.o

  CC    armeb-linux-user/thunk.o

  CC    sparc64-linux-user/fpu/softfloat.o

  CC    sparc-linux-user/disas.o

  CC    sparc64-linux-user/op_helper.o

  CC    sparc-linux-user/i386-dis.o

  CC    armeb-linux-user/elfload.o

  CC    sparc-linux-user/sparc-dis.o

  CC    sparc64-linux-user/helper.o

  CC    sh4eb-linux-user/sh4-dis.o

  GEN   config-target.h

  CC    sparc64-linux-user/disas.o

  GEN   ppc64abi32-linux-user/gdbstub-xml.c

  CC    armeb-linux-user/linuxload.o

  CC    alpha-linux-user/exec.o

  AR    sh4eb-linux-user/libqemu.a

  CC    ppc64abi32-linux-user/main.o

  LINK  sh4eb-linux-user/qemu-sh4eb

  CC    ppc64abi32-linux-user/syscall.o

  CC    alpha-linux-user/cpu-exec.o

  AR    sparc-linux-user/libqemu.a

  LINK  sparc-linux-user/qemu-sparc

  CC    ppc64abi32-linux-user/strace.o

  CC    sparc64-linux-user/i386-dis.o

  CC    alpha-linux-user/translate-all.o

  CC    sparc64-linux-user/sparc-dis.o

  CC    alpha-linux-user/translate.o

  CC    armeb-linux-user/uaccess.o

  CC    alpha-linux-user/tcg/tcg.o

  CC    armeb-linux-user/gdbstub.o

  CC    alpha-linux-user/fpu/softfloat-native.o

  CC    ppc64abi32-linux-user/mmap.o

  GEN   config-target.h

  CC    armeb-linux-user/flatload.o

  CC    sparc32plus-linux-user/main.o

  AR    sparc64-linux-user/libqemu.a

  CC    ppc64abi32-linux-user/signal.o

  LINK  sparc64-linux-user/qemu-sparc64

  CC    sparc32plus-linux-user/syscall.o

  CC    sparc32plus-linux-user/strace.o

  CC    sparc32plus-linux-user/mmap.o

  CC    armeb-linux-user/gdbstub-xml.o

  CC    alpha-linux-user/op_helper.o

  CC    alpha-linux-user/helper.o

  CC    sparc32plus-linux-user/signal.o

  CC    alpha-linux-user/alpha_palcode.o

  CC    alpha-linux-user/disas.o

  GEN   config-target.h

  CC    ppc64abi32-linux-user/thunk.o

  GEN   i386-softmmu/qemu-options.h

  CC    armeb-linux-user/nwfpe/fpa11.o

  CC    ppc64abi32-linux-user/elfload.o

  CC    armeb-linux-user/nwfpe/fpa11_cpdo.o

  CC    alpha-linux-user/alpha-dis.o

  CC    armeb-linux-user/nwfpe/fpa11_cpdt.o

  GEN   i386-softmmu/qemu-monitor.h

  CC    alpha-linux-user/i386-dis.o

  CC    i386-softmmu/vl.o

  CC    i386-softmmu/async.o

  CC    sparc32plus-linux-user/thunk.o

  CC    ppc64abi32-linux-user/linuxload.o

  CC    armeb-linux-user/nwfpe/fpa11_cprt.o

  CC    sparc32plus-linux-user/elfload.o

  CC    sparc32plus-linux-user/linuxload.o

  CC    ppc64abi32-linux-user/uaccess.o

  CC    sparc32plus-linux-user/uaccess.o

  CC    i386-softmmu/monitor.o

  CC    armeb-linux-user/nwfpe/fpopcode.o

  CC    armeb-linux-user/nwfpe/single_cpdo.o

  CC    ppc64abi32-linux-user/gdbstub.o

  CC    ppc64abi32-linux-user/gdbstub-xml.o

  CC    armeb-linux-user/nwfpe/double_cpdo.o

  AR    alpha-linux-user/libqemu.a

  LINK  alpha-linux-user/qemu-alpha

  CC    i386-softmmu/pci.o

  CC    armeb-linux-user/nwfpe/extended_cpdo.o

  CC    armeb-linux-user/arm-semi.o

  CC    ppc64abi32-linux-user/exec.o

  CC    armeb-linux-user/exec.o

  CC    sparc32plus-linux-user/gdbstub.o

  CC    armeb-linux-user/cpu-exec.o

  CC    ppc64abi32-linux-user/cpu-exec.o

  CC    ppc64abi32-linux-user/translate-all.o

  CC    armeb-linux-user/translate-all.o

  CC    armeb-linux-user/translate.o

  CC    i386-softmmu/pci_host.o

  CC    ppc64abi32-linux-user/translate.o

  CC    sparc32plus-linux-user/exec.o

  GEN   config-target.h

  CC    sparc32plus-linux-user/cpu-exec.o

  CC    i386-softmmu/pcie_host.o

  CC    i386-softmmu/machine.o

  GEN   x86_64-softmmu/qemu-options.h

  CC    i386-softmmu/gdbstub.o

  GEN   x86_64-softmmu/qemu-monitor.h

  CC    x86_64-softmmu/vl.o

  CC    x86_64-softmmu/async.o

  CC    armeb-linux-user/tcg/tcg.o

  CC    armeb-linux-user/fpu/softfloat.o

  CC    sparc32plus-linux-user/translate-all.o

  CC    sparc32plus-linux-user/translate.o

  CC    x86_64-softmmu/monitor.o

  CC    ppc64abi32-linux-user/tcg/tcg.o

  CC    i386-softmmu/virtio-blk.o

  CC    i386-softmmu/virtio-balloon.o

  CC    i386-softmmu/virtio-net.o

  CC    x86_64-softmmu/pci.o

  CC    sparc32plus-linux-user/tcg/tcg.o

  CC    x86_64-softmmu/pci_host.o

  CC    ppc64abi32-linux-user/fpu/softfloat.o

  CC    ppc64abi32-linux-user/op_helper.o

  GEN   config-target.h

  CC    armeb-linux-user/op_helper.o

  GEN   arm-softmmu/qemu-options.h

  GEN   arm-softmmu/qemu-monitor.h

  CC    armeb-linux-user/helper.o

  GEN   arm-softmmu/gdbstub-xml.c

  CC    sparc32plus-linux-user/fpu/softfloat.o

  CC    i386-softmmu/virtio-console.o

  CC    arm-softmmu/vl.o

  CC    sparc32plus-linux-user/op_helper.o

  CC    sparc32plus-linux-user/helper.o

  CC    x86_64-softmmu/pcie_host.o

  CC    x86_64-softmmu/machine.o

  CC    i386-softmmu/virtio-pci.o

  CC    ppc64abi32-linux-user/helper.o

  CC    i386-softmmu/kvm.o

  CC    arm-softmmu/async.o

  CC    armeb-linux-user/neon_helper.o

  CC    sparc32plus-linux-user/disas.o

  CC    x86_64-softmmu/gdbstub.o

  CC    ppc64abi32-linux-user/disas.o

  CC    sparc32plus-linux-user/i386-dis.o

  CC    x86_64-softmmu/virtio-blk.o

  CC    sparc32plus-linux-user/sparc-dis.o

  CC    armeb-linux-user/iwmmxt_helper.o

  CC    arm-softmmu/monitor.o

  CC    arm-softmmu/pci.o

  CC    i386-softmmu/kvm-all.o

  CC    x86_64-softmmu/virtio-balloon.o

  CC    ppc64abi32-linux-user/i386-dis.o

  AR    sparc32plus-linux-user/libqemu.a

  LINK  sparc32plus-linux-user/qemu-sparc32plus

  CC    ppc64abi32-linux-user/ppc-dis.o

  CC    x86_64-softmmu/virtio-net.o

  CC    i386-softmmu/msix.o

  CC    armeb-linux-user/disas.o

  CC    i386-softmmu/eepro100.o

  CC    i386-softmmu/pcnet.o

  CC    i386-softmmu/rtl8139.o

  CC    arm-softmmu/pci_host.o

  CC    x86_64-softmmu/virtio-console.o

  CC    x86_64-softmmu/virtio-pci.o

  CC    armeb-linux-user/arm-dis.o

  AR    ppc64abi32-linux-user/libqemu.a

  CC    armeb-linux-user/i386-dis.o

  LINK  ppc64abi32-linux-user/qemu-ppc64abi32

  GEN   config-target.h

  GEN   cris-softmmu/qemu-options.h

  GEN   cris-softmmu/qemu-monitor.h

  AR    armeb-linux-user/libqemu.a

  LINK  armeb-linux-user/qemu-armeb

  CC    x86_64-softmmu/kvm.o

  CC    arm-softmmu/pcie_host.o

  CC    i386-softmmu/e1000.o

  CC    x86_64-softmmu/kvm-all.o

  CC    x86_64-softmmu/msix.o

  CC    cris-softmmu/vl.o

  CC    cris-softmmu/async.o

  CC    cris-softmmu/monitor.o

  CC    arm-softmmu/machine.o

  CC    arm-softmmu/gdbstub.o

  CC    arm-softmmu/virtio-blk.o

  CC    x86_64-softmmu/eepro100.o

  CC    i386-softmmu/ide/core.o

  CC    arm-softmmu/virtio-balloon.o

  CC    cris-softmmu/pci.o

  GEN   config-target.h

  GEN   config-target.h

  GEN   m68k-softmmu/qemu-options.h

  GEN   microblaze-softmmu/qemu-options.h

  CC    i386-softmmu/ide/qdev.o

  CC    cris-softmmu/pci_host.o

  CC    x86_64-softmmu/pcnet.o

  GEN   m68k-softmmu/qemu-monitor.h

  GEN   microblaze-softmmu/qemu-monitor.h

  CC    i386-softmmu/ide/isa.o

  CC    arm-softmmu/virtio-net.o

  GEN   m68k-softmmu/gdbstub-xml.c

  CC    microblaze-softmmu/vl.o

  CC    m68k-softmmu/vl.o

  CC    m68k-softmmu/async.o

  CC    x86_64-softmmu/rtl8139.o

  CC    arm-softmmu/virtio-console.o

  CC    cris-softmmu/pcie_host.o

  CC    m68k-softmmu/monitor.o

  CC    i386-softmmu/ide/pci.o

  CC    microblaze-softmmu/async.o

  CC    m68k-softmmu/pci.o

  CC    microblaze-softmmu/monitor.o

  CC    x86_64-softmmu/e1000.o

  CC    m68k-softmmu/pci_host.o

  CC    m68k-softmmu/pcie_host.o

  CC    cris-softmmu/machine.o

  CC    arm-softmmu/virtio-pci.o

  CC    i386-softmmu/ide/piix.o

  CC    microblaze-softmmu/pci.o

  CC    i386-softmmu/pckbd.o

  CC    x86_64-softmmu/ide/core.o

  CC    arm-softmmu/msix.o

  CC    cris-softmmu/gdbstub.o

  CC    cris-softmmu/virtio-blk.o

  CC    arm-softmmu/isa_mmio.o

  CC    i386-softmmu/sb16.o

  CC    m68k-softmmu/machine.o

  CC    x86_64-softmmu/ide/qdev.o

  CC    arm-softmmu/usb-ohci.o

  CC    i386-softmmu/es1370.o

  CC    microblaze-softmmu/pci_host.o

  CC    microblaze-softmmu/pcie_host.o

  CC    cris-softmmu/virtio-balloon.o

  CC    x86_64-softmmu/ide/isa.o

  CC    m68k-softmmu/gdbstub.o

  CC    arm-softmmu/eepro100.o

  CC    i386-softmmu/ac97.o

  CC    cris-softmmu/virtio-net.o

  CC    x86_64-softmmu/ide/pci.o

  CC    m68k-softmmu/virtio-blk.o

  CC    microblaze-softmmu/machine.o

  CC    i386-softmmu/dma.o

  CC    x86_64-softmmu/ide/piix.o

  CC    cris-softmmu/virtio-console.o

  CC    cris-softmmu/virtio-pci.o

  CC    x86_64-softmmu/pckbd.o

  CC    arm-softmmu/pcnet.o

  CC    microblaze-softmmu/gdbstub.o

  CC    microblaze-softmmu/virtio-blk.o

  CC    i386-softmmu/vga.o

  CC    m68k-softmmu/virtio-balloon.o

  CC    cris-softmmu/msix.o

  CC    m68k-softmmu/virtio-net.o

  CC    cris-softmmu/eepro100.o

  CC    cris-softmmu/pcnet.o

  CC    cris-softmmu/rtl8139.o

  CC    microblaze-softmmu/virtio-balloon.o

  CC    m68k-softmmu/virtio-console.o

  CC    arm-softmmu/rtl8139.o

  CC    microblaze-softmmu/virtio-net.o

  CC    microblaze-softmmu/virtio-console.o

  CC    arm-softmmu/e1000.o

  CC    x86_64-softmmu/sb16.o

  CC    m68k-softmmu/virtio-pci.o

  CC    i386-softmmu/vga-pci.o

  CC    i386-softmmu/vga-isa.o

  CC    i386-softmmu/fdc.o

  CC    microblaze-softmmu/virtio-pci.o

  CC    cris-softmmu/e1000.o

  CC    x86_64-softmmu/es1370.o

  CC    m68k-softmmu/msix.o

  CC    arm-softmmu/gdbstub-xml.o

  CC    x86_64-softmmu/ac97.o

  CC    x86_64-softmmu/dma.o

  CC    m68k-softmmu/eepro100.o

  CC    i386-softmmu/mc146818rtc.o

  CC    microblaze-softmmu/msix.o

  CC    arm-softmmu/integratorcp.o

  CC    cris-softmmu/cris_pic_cpu.o

  CC    x86_64-softmmu/vga.o

  CC    cris-softmmu/etraxfs.o

  CC    x86_64-softmmu/vga-pci.o

  CC    cris-softmmu/axis_dev88.o

  CC    microblaze-softmmu/eepro100.o

  CC    cris-softmmu/etraxfs_dma.o

  CC    arm-softmmu/versatilepb.o

  CC    m68k-softmmu/pcnet.o

  CC    i386-softmmu/serial.o

  CC    i386-softmmu/i8259.o

  CC    microblaze-softmmu/pcnet.o

  CC    arm-softmmu/arm_pic.o

  CC    x86_64-softmmu/vga-isa.o

  CC    cris-softmmu/etraxfs_pic.o

  CC    i386-softmmu/i8254.o

  CC    m68k-softmmu/rtl8139.o

  CC    i386-softmmu/pcspk.o

  CC    cris-softmmu/etraxfs_eth.o

  CC    x86_64-softmmu/fdc.o

  CC    x86_64-softmmu/mc146818rtc.o

  CC    arm-softmmu/arm_timer.o

  CC    cris-softmmu/etraxfs_timer.o

  CC    m68k-softmmu/e1000.o

  CC    cris-softmmu/etraxfs_ser.o

  CC    i386-softmmu/pc.o

  CC    x86_64-softmmu/serial.o

  CC    microblaze-softmmu/rtl8139.o

  CC    arm-softmmu/arm_boot.o

  CC    microblaze-softmmu/e1000.o

  CC    x86_64-softmmu/i8259.o

  CC    x86_64-softmmu/i8254.o

  CC    cris-softmmu/pflash_cfi02.o

  CC    cris-softmmu/exec.o

  CC    i386-softmmu/cirrus_vga.o

  CC    m68k-softmmu/gdbstub-xml.o

  CC    microblaze-softmmu/petalogix_s3adsp1800_mmu.o

  CC    x86_64-softmmu/pcspk.o

  CC    m68k-softmmu/an5206.o

  CC    x86_64-softmmu/pc.o

  CC    arm-softmmu/pl011.o

  CC    cris-softmmu/cpu-exec.o

  CC    m68k-softmmu/mcf5206.o

  CC    arm-softmmu/pl031.o

  CC    cris-softmmu/translate-all.o

  CC    i386-softmmu/apic.o

  CC    cris-softmmu/translate.o

  CC    i386-softmmu/ioapic.o

  CC    arm-softmmu/pl050.o

  CC    m68k-softmmu/mcf_uart.o

  CC    microblaze-softmmu/microblaze_pic_cpu.o

  CC    x86_64-softmmu/cirrus_vga.o

  CC    x86_64-softmmu/apic.o

  CC    m68k-softmmu/mcf_intc.o

  CC    microblaze-softmmu/xilinx_intc.o

  CC    i386-softmmu/parallel.o

  CC    arm-softmmu/pl080.o

  CC    arm-softmmu/pl110.o

  CC    microblaze-softmmu/xilinx_timer.o

  CC    m68k-softmmu/mcf5208.o

  CC    cris-softmmu/tcg/tcg.o

  CC    i386-softmmu/acpi.o

  CC    microblaze-softmmu/xilinx_uartlite.o

  CC    m68k-softmmu/mcf_fec.o

  CC    m68k-softmmu/m68k-semi.o

  CC    arm-softmmu/pl181.o

  CC    i386-softmmu/piix_pci.o

  CC    microblaze-softmmu/xilinx_ethlite.o

  CC    arm-softmmu/pl190.o

  CC    i386-softmmu/usb-uhci.o

  CC    microblaze-softmmu/pflash_cfi02.o

  CC    microblaze-softmmu/device_tree.o

  CC    cris-softmmu/fpu/softfloat-native.o

  CC    cris-softmmu/op_helper.o

  CC    i386-softmmu/vmmouse.o

  CC    i386-softmmu/vmport.o

  CC    arm-softmmu/versatile_pci.o

/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2/device_tree.c: In function ‘load_device_tree’:

/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2/device_tree.c:63: attention : implicit declaration of function ‘fdt_check_header’

/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2/device_tree.c: In function ‘qemu_devtree_setprop_cell’:

/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2/device_tree.c:97: attention : implicit declaration of function ‘fdt_setprop_cell’

  CC    microblaze-softmmu/exec.o

  CC    microblaze-softmmu/cpu-exec.o

  CC    i386-softmmu/vmware_vga.o

  CC    cris-softmmu/helper.o

  CC    i386-softmmu/hpet.o

  CC    x86_64-softmmu/ioapic.o

  CC    m68k-softmmu/dummy_m68k.o

  CC    arm-softmmu/realview_gic.o

  CC    microblaze-softmmu/translate-all.o

  CC    microblaze-softmmu/translate.o

  CC    m68k-softmmu/exec.o

  CC    cris-softmmu/mmu.o

  CC    arm-softmmu/realview.o

  CC    x86_64-softmmu/parallel.o

  CC    i386-softmmu/device-hotplug.o

  CC    i386-softmmu/pci-hotplug.o

  CC    microblaze-softmmu/tcg/tcg.o

  CC    m68k-softmmu/cpu-exec.o

  CC    cris-softmmu/disas.o

  CC    arm-softmmu/arm_sysctl.o

  CC    m68k-softmmu/translate-all.o

  CC    m68k-softmmu/translate.o

  CC    i386-softmmu/smbios.o

  CC    microblaze-softmmu/fpu/softfloat.o

  CC    cris-softmmu/cris-dis.o

  CC    m68k-softmmu/tcg/tcg.o

  CC    x86_64-softmmu/acpi.o

  CC    arm-softmmu/arm11mpcore.o

  CC    i386-softmmu/wdt_ib700.o

  CC    cris-softmmu/i386-dis.o

  AR    cris-softmmu/libqemu.a

  LINK  cris-softmmu/qemu-system-cris

  CC    microblaze-softmmu/op_helper.o

  CC    microblaze-softmmu/helper.o

  CC    i386-softmmu/extboot.o

  CC    x86_64-softmmu/piix_pci.o

  CC    arm-softmmu/a9mpcore.o

  CC    microblaze-softmmu/mmu.o

  CC    m68k-softmmu/fpu/softfloat.o

  CC    m68k-softmmu/op_helper.o

  CC    microblaze-softmmu/disas.o

  CC    i386-softmmu/ne2000-isa.o

  CC    arm-softmmu/armv7m.o

  CC    microblaze-softmmu/i386-dis.o

  CC    microblaze-softmmu/microblaze-dis.o

  CC    x86_64-softmmu/usb-uhci.o

  CC    m68k-softmmu/helper.o

  CC    x86_64-softmmu/vmmouse.o

  CC    i386-softmmu/testdev.o

  CC    arm-softmmu/armv7m_nvic.o

  CC    x86_64-softmmu/vmport.o

  CC    x86_64-softmmu/vmware_vga.o

  CC    arm-softmmu/stellaris.o

  CC    i386-softmmu/i8254-kvm.o

  CC    m68k-softmmu/disas.o

  GEN   config-target.h

  GEN   mips-softmmu/qemu-options.h

  CC    m68k-softmmu/i386-dis.o

  AR    microblaze-softmmu/libqemu.a

  CC    x86_64-softmmu/hpet.o

  CC    i386-softmmu/device-assignment.o

  CC    m68k-softmmu/m68k-dis.o

  LINK  microblaze-softmmu/qemu-system-microblaze

  CC    arm-softmmu/pl022.o

  GEN   mips-softmmu/qemu-monitor.h

  CC    i386-softmmu/exec.o

  CC    mips-softmmu/vl.o

  CC    mips-softmmu/async.o

  GEN   config-target.h

  AR    m68k-softmmu/libqemu.a

  GEN   mipsel-softmmu/qemu-options.h

  CC    x86_64-softmmu/device-hotplug.o

  LINK  m68k-softmmu/qemu-system-m68k

  CC    mips-softmmu/monitor.o

  CC    i386-softmmu/cpu-exec.o

  CC    arm-softmmu/stellaris_enet.o

  GEN   mipsel-softmmu/qemu-monitor.h

device_tree.o: In function `load_device_tree':

/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2/device_tree.c:63: undefined reference to `fdt_check_header'

device_tree.o: In function `qemu_devtree_setprop_cell':

/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2/device_tree.c:97: undefined reference to `fdt_setprop_cell'

collect2: ld a retourné 1 code d'état d'exécution

make[1]: *** [qemu-system-microblaze] Erreur 1

make: *** [subdir-microblaze-softmmu] Erreur 2

make: *** Attente des tâches non terminées....

  CC    i386-softmmu/translate-all.o

  CC    mips-softmmu/pci.o

  CC    mipsel-softmmu/vl.o

  CC    x86_64-softmmu/pci-hotplug.o

  CC    arm-softmmu/pl061.o

  CC    mipsel-softmmu/async.o

  CC    i386-softmmu/translate.o

  CC    mips-softmmu/pci_host.o

  CC    arm-softmmu/arm-semi.o

  CC    x86_64-softmmu/smbios.o

  CC    x86_64-softmmu/wdt_ib700.o

  CC    mipsel-softmmu/monitor.o

  CC    mipsel-softmmu/pci.o

  CC    mips-softmmu/pcie_host.o

  CC    arm-softmmu/pxa2xx.o

  CC    mips-softmmu/machine.o

  CC    x86_64-softmmu/extboot.o

  CC    arm-softmmu/pxa2xx_pic.o

  CC    x86_64-softmmu/ne2000-isa.o

  CC    x86_64-softmmu/testdev.o

  CC    mipsel-softmmu/pci_host.o

  CC    mipsel-softmmu/pcie_host.o

  CC    i386-softmmu/tcg/tcg.o

  CC    mips-softmmu/gdbstub.o

  CC    mips-softmmu/virtio-blk.o

  CC    arm-softmmu/pxa2xx_gpio.o

  CC    arm-softmmu/pxa2xx_timer.o

  CC    mipsel-softmmu/machine.o

  CC    i386-softmmu/fpu/softfloat-native.o

  CC    x86_64-softmmu/i8254-kvm.o

  CC    i386-softmmu/op_helper.o

  CC    x86_64-softmmu/device-assignment.o

  CC    x86_64-softmmu/exec.o

  CC    mipsel-softmmu/gdbstub.o

  CC    mips-softmmu/virtio-balloon.o

  CC    mipsel-softmmu/virtio-blk.o

  CC    mipsel-softmmu/virtio-balloon.o

  CC    arm-softmmu/pxa2xx_dma.o

  CC    mipsel-softmmu/virtio-net.o

  CC    arm-softmmu/pxa2xx_lcd.o

  CC    mips-softmmu/virtio-net.o

  CC    mips-softmmu/virtio-console.o

  CC    i386-softmmu/helper.o

  CC    x86_64-softmmu/cpu-exec.o

  CC    i386-softmmu/kvm-tpr-opt.o

  CC    arm-softmmu/pxa2xx_mmci.o

  CC    i386-softmmu/qemu-kvm-helper.o

  CC    arm-softmmu/pxa2xx_pcmcia.o

  CC    x86_64-softmmu/translate-all.o

  CC    mips-softmmu/virtio-pci.o

  CC    arm-softmmu/pxa2xx_keypad.o

  CC    x86_64-softmmu/translate.o

  CC    i386-softmmu/disas.o

  CC    x86_64-softmmu/tcg/tcg.o

  CC    mipsel-softmmu/virtio-console.o

  CC    mips-softmmu/msix.o

  CC    arm-softmmu/pflash_cfi01.o

  CC    mipsel-softmmu/virtio-pci.o

  CC    i386-softmmu/i386-dis.o

  CC    mips-softmmu/isa_mmio.o

  CC    mips-softmmu/eepro100.o

  AR    i386-softmmu/libqemu.a

  LINK  i386-softmmu/qemu

  CC    arm-softmmu/gumstix.o

  CC    mips-softmmu/pcnet.o

  CC    mips-softmmu/rtl8139.o

  CC    mipsel-softmmu/msix.o

  CC    mipsel-softmmu/isa_mmio.o

  CC    mipsel-softmmu/eepro100.o

  CC    arm-softmmu/zaurus.o

  CC    x86_64-softmmu/fpu/softfloat-native.o

  CC    x86_64-softmmu/op_helper.o

  CC    mipsel-softmmu/pcnet.o

  CC    arm-softmmu/ide/core.o

  CC    mips-softmmu/e1000.o

  CC    mips-softmmu/mips_r4k.o

  CC    mips-softmmu/mips_jazz.o

  CC    mipsel-softmmu/rtl8139.o

  CC    x86_64-softmmu/helper.o

  CC    x86_64-softmmu/kvm-tpr-opt.o

  CC    mips-softmmu/mips_malta.o

  CC    mipsel-softmmu/e1000.o

  CC    mips-softmmu/mips_mipssim.o

  CC    mipsel-softmmu/mips_r4k.o

  CC    mipsel-softmmu/mips_jazz.o

  CC    mipsel-softmmu/mips_malta.o

  CC    x86_64-softmmu/qemu-kvm-helper.o

  CC    mips-softmmu/mips_timer.o

  CC    x86_64-softmmu/disas.o

  CC    arm-softmmu/ide/microdrive.o

  CC    mipsel-softmmu/mips_mipssim.o

  CC    mips-softmmu/mips_int.o

  CC    mipsel-softmmu/mips_timer.o

  CC    arm-softmmu/serial.o

  CC    arm-softmmu/spitz.o

  CC    arm-softmmu/tosa.o

  CC    arm-softmmu/tc6393xb.o

  CC    mipsel-softmmu/mips_int.o

  CC    mipsel-softmmu/dma.o

  CC    arm-softmmu/omap1.o

  CC    mipsel-softmmu/vga.o

  CC    x86_64-softmmu/i386-dis.o

  CC    arm-softmmu/omap_lcdc.o

  CC    mips-softmmu/dma.o

  CC    arm-softmmu/omap_dma.o

  CC    arm-softmmu/omap_clk.o

  CC    mipsel-softmmu/serial.o

  CC    mipsel-softmmu/i8254.o

  CC    mipsel-softmmu/i8259.o

  CC    arm-softmmu/omap_mmc.o

  CC    mips-softmmu/vga.o

  CC    mips-softmmu/serial.o

  AR    x86_64-softmmu/libqemu.a

  CC    mips-softmmu/i8254.o

  LINK  x86_64-softmmu/qemu-system-x86_64

  CC    arm-softmmu/omap_i2c.o

  CC    arm-softmmu/omap2.o

  CC    arm-softmmu/omap_dss.o

  CC    mips-softmmu/i8259.o

  CC    arm-softmmu/soc_dma.o

  CC    mips-softmmu/rc4030.o

  CC    mips-softmmu/vga-pci.o

  CC    mipsel-softmmu/rc4030.o

  CC    mipsel-softmmu/vga-pci.o

  CC    mipsel-softmmu/vga-isa.o

  CC    mips-softmmu/vga-isa.o

  CC    mips-softmmu/vga-isa-mm.o

  CC    mipsel-softmmu/vga-isa-mm.o

  CC    arm-softmmu/omap_sx1.o

  CC    mips-softmmu/g364fb.o

  CC    mipsel-softmmu/g364fb.o

  CC    mips-softmmu/jazz_led.o

  CC    mipsel-softmmu/jazz_led.o

  CC    arm-softmmu/palm.o

  CC    mips-softmmu/dp8393x.o

  CC    arm-softmmu/tsc210x.o

  CC    mips-softmmu/ide/core.o

  CC    mips-softmmu/ide/qdev.o

  CC    mipsel-softmmu/dp8393x.o

  CC    mipsel-softmmu/ide/core.o

  CC    mips-softmmu/ide/isa.o

  CC    arm-softmmu/nseries.o

  CC    mips-softmmu/ide/pci.o

  CC    mips-softmmu/ide/piix.o

  CC    arm-softmmu/blizzard.o

  CC    arm-softmmu/onenand.o

  CC    arm-softmmu/vga.o

  CC    mipsel-softmmu/ide/qdev.o

  CC    mips-softmmu/gt64xxx.o

  CC    mipsel-softmmu/ide/isa.o

  CC    mipsel-softmmu/ide/pci.o

  CC    mipsel-softmmu/ide/piix.o

  CC    mips-softmmu/pckbd.o

  CC    arm-softmmu/cbus.o

  CC    arm-softmmu/tusb6010.o

  CC    mipsel-softmmu/gt64xxx.o

  CC    mipsel-softmmu/pckbd.o

  CC    mipsel-softmmu/fdc.o

  CC    mips-softmmu/fdc.o

  CC    arm-softmmu/usb-musb.o

  CC    arm-softmmu/mst_fpga.o

  CC    arm-softmmu/mainstone.o

  CC    arm-softmmu/musicpal.o

  CC    mips-softmmu/mc146818rtc.o

  CC    arm-softmmu/pflash_cfi02.o

  CC    mipsel-softmmu/mc146818rtc.o

  CC    mips-softmmu/usb-uhci.o

  CC    arm-softmmu/bitbang_i2c.o

  CC    mips-softmmu/acpi.o

  CC    mipsel-softmmu/usb-uhci.o

  CC    mipsel-softmmu/acpi.o

  CC    mips-softmmu/ds1225y.o

  CC    arm-softmmu/marvell_88w8618_audio.o

  CC    arm-softmmu/framebuffer.o

  CC    arm-softmmu/syborg.o

  CC    arm-softmmu/syborg_fb.o

  CC    mipsel-softmmu/ds1225y.o

  CC    mipsel-softmmu/piix4.o

  CC    mips-softmmu/piix4.o

  CC    mips-softmmu/parallel.o

  CC    arm-softmmu/syborg_interrupt.o

  CC    mips-softmmu/cirrus_vga.o

  CC    arm-softmmu/syborg_keyboard.o

  CC    mips-softmmu/pcspk.o

  CC    mipsel-softmmu/parallel.o

  CC    mipsel-softmmu/cirrus_vga.o

  CC    mips-softmmu/sb16.o

  CC    mips-softmmu/es1370.o

  CC    arm-softmmu/syborg_serial.o

  CC    arm-softmmu/syborg_timer.o

  CC    mipsel-softmmu/pcspk.o

  CC    mips-softmmu/ac97.o

  CC    mipsel-softmmu/sb16.o

  CC    mipsel-softmmu/es1370.o

  CC    mipsel-softmmu/ac97.o

  CC    mips-softmmu/mipsnet.o

  CC    mips-softmmu/ne2000-isa.o

  CC    mips-softmmu/pflash_cfi01.o

  CC    arm-softmmu/syborg_pointer.o

  CC    mipsel-softmmu/mipsnet.o

  CC    arm-softmmu/syborg_rtc.o

  CC    arm-softmmu/syborg_virtio.o

  CC    mips-softmmu/vmware_vga.o

  CC    mips-softmmu/exec.o

  CC    mips-softmmu/cpu-exec.o

  CC    mips-softmmu/translate-all.o

  CC    mipsel-softmmu/ne2000-isa.o

  CC    arm-softmmu/exec.o

  CC    arm-softmmu/cpu-exec.o

  CC    mipsel-softmmu/pflash_cfi01.o

  CC    mipsel-softmmu/vmware_vga.o

  CC    mips-softmmu/translate.o

  CC    mips-softmmu/tcg/tcg.o

  CC    arm-softmmu/translate-all.o

  CC    mips-softmmu/fpu/softfloat.o

  CC    mips-softmmu/op_helper.o

  CC    mipsel-softmmu/exec.o

  CC    mipsel-softmmu/cpu-exec.o

  CC    arm-softmmu/translate.o

  CC    mipsel-softmmu/translate-all.o

  CC    mipsel-softmmu/translate.o

  CC    mipsel-softmmu/tcg/tcg.o

  CC    mips-softmmu/helper.o

  CC    mipsel-softmmu/fpu/softfloat.o

  CC    mipsel-softmmu/op_helper.o

  CC    arm-softmmu/tcg/tcg.o

  CC    arm-softmmu/fpu/softfloat.o

  CC    mipsel-softmmu/helper.o

  CC    mips-softmmu/disas.o

  CC    arm-softmmu/op_helper.o

  CC    arm-softmmu/helper.o

  CC    arm-softmmu/neon_helper.o

  CC    mipsel-softmmu/disas.o

  CC    arm-softmmu/iwmmxt_helper.o

  CC    mips-softmmu/i386-dis.o

  CC    mips-softmmu/mips-dis.o

  CC    arm-softmmu/disas.o

  CC    mipsel-softmmu/i386-dis.o

  CC    arm-softmmu/arm-dis.o

  CC    mipsel-softmmu/mips-dis.o

  CC    arm-softmmu/i386-dis.o

  AR    mips-softmmu/libqemu.a

  AR    mipsel-softmmu/libqemu.a

  AR    arm-softmmu/libqemu.a

  LINK  mips-softmmu/qemu-system-mips

  LINK  mipsel-softmmu/qemu-system-mipsel

  LINK  arm-softmmu/qemu-system-arm

 * ERROR: app-emulation/qemu-kvm-0.12.2-r2 failed:

 *   emake failed

 * 

 * Call stack:

 *     ebuild.sh, line   54:  Called src_compile

 *   environment, line 3568:  Called _eapi2_src_compile

 *     ebuild.sh, line  646:  Called die

 * The specific snippet of code:

 *         emake || die "emake failed"

 * 

 * If you need support, post the output of 'emerge --info =app-emulation/qemu-kvm-0.12.2-r2',

 * the complete build log and the output of 'emerge -pqv =app-emulation/qemu-kvm-0.12.2-r2'.

 * The complete build log is located at '/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/temp/build.log'.

 * The ebuild environment file is located at '/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/temp/environment'.

 * S: '/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2'

```

PS : merci de ton aide. Je ne suis pas encore assez bon pour m'en sortir seul   :Evil or Very Mad: 

----------

## xaviermiller

et pas d'erreur plus haut encore ?

----------

## Winnt

Bonsoir,

Non aucune erreur plus haut. Les 6 autres programmes dépendants qui se compilent avant le font sans erreur.

Toutefois une information qui a peut être son importance. J'utilise ccache pour compiler. Au cas ou...

----------

## Leander256

```
/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2/device_tree.c: In function ‘load_device_tree’:

/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2/device_tree.c:63: attention : implicit declaration of function ‘fdt_check_header’

/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2/device_tree.c: In function ‘qemu_devtree_setprop_cell’:

/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2/device_tree.c:97: attention : implicit declaration of function ‘fdt_setprop_cell’

device_tree.o: In function `load_device_tree':

/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2/device_tree.c:63: undefined reference to `fdt_check_header'

device_tree.o: In function `qemu_devtree_setprop_cell':

/var/tmp/portage/app-emulation/qemu-kvm-0.12.2-r2/work/qemu-kvm-0.12.2/device_tree.c:97: undefined reference to `fdt_setprop_cell'

collect2: ld a retourné 1 code d'état d'exécution

make[1]: *** [qemu-system-microblaze] Erreur 1

make: *** [subdir-microblaze-softmmu] Erreur 2
```

C'est là l'erreur de compilation, quand il écrit Erreur  :Wink: 

----------

## Winnt

Et si je tentais d'emerger une version 0.12.2 à la place de la  0.12.2-r2 ?

----------

## kwenspc

Ton erreur est dû au use flag fdt, vires le. 

 *Quote:*   

> [-    ] fdt (app-emulation/qemu-kvm):
> 
> Enables firmware device tree support
> 
> 

 

Je pense pas que tu en ais besoin. je l'ai pas perso (je n'ai pas non plus vde ni bluez.)

----------

## Winnt

Ben j'ai fait l'emerge de la 0.12.2 sans toucher aux USE flags et c'est passer comme une lettre à la poste.

----------

## man in the hill

 *Winnt wrote:*   

> Et si je tentais d'emerger une version 0.12.2 à la place de la  0.12.2-r2 ?

 

Tu peux tjrs essayer ...

As-tu refais une synchro ?

Tu peux aussi vider le cache .

Je l'ai installé today sur ma machine de bureau et pas de problème .

```
emerge -pv  qemu-kvm

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R   ] app-emulation/qemu-kvm-0.12.2-r2  USE="aio alsa bluetooth esd ncurses sdl -curl -fdt -gnutls -hardened -kvm-trace -pulseaudio -sasl -static -vde" QEMU_SOFTMMU_TARGETS="arm cris i386 m68k microblaze mips mips64 mips64el mipsel ppc ppc64 ppcemb sh4 sh4eb sparc sparc64 x86_64" QEMU_USER_TARGETS="alpha arm armeb cris i386 m68k microblaze mips mipsel ppc ppc64 ppc64abi32 sh4 sh4eb sparc sparc32plus sparc64 x86_64" 0 kB
```

----------

## Winnt

J'ai fait l'emerge sans faire de synchro.

J'ai mis cela dans /etc/portage/package.keywords

```
=app-emulation/qemu-kvm-0.12.2 ~amd64
```

Mais je vais refaire le test en modifiants les USE flags comme indiqué plus haut par kwenspc.

Je vous tient au courant.

----------

## Winnt

Je viens de tester en enlevant ce flag comme conseillé 

 *kwenspc wrote:*   

> Ton erreur est dû au use flag fdt, vires le. 

 

Et bien ca passe nickel.

Après une synchro et un emerge -uDN system et world. Je n'ai eu aucun souci.

Grand merci à toi kwenspc.

Par curiosité comment as tu su pour ce flag ?

PS : Le kernel 2.6.33 est déjà dans les bacs   :Very Happy: 

----------

## kwenspc

 *Winnt wrote:*   

> 
> 
> Par curiosité comment as tu su pour ce flag ?
> 
> 

 

Bah en fait les erreurs dons ton log sont dû à tes nom de fonctions non résolues, qui porte pour préfixe: fdt. Comme j'ai pas le problème (ce genre de soucis à la compilation, sous gentoo c'est assez rare qu'une personne l'ait et pas d'autres) je me suis dis que ça venait des supports que tu as demandés, et bingo dans la liste y avait fdt, que moi je n'avais pas.

Content que ça ait résolu ton soucis.

Dans le meilleur des mondes faudrait faire un rapport de bug etc... mais, flemme ce soir.

----------

## Winnt

Merci de ton aide.

Et j'ai au  moins grace à cela appris comment trouver une erreur de ce genre.

Je ne doute pas que cela me serve encore à un moment ou un autre.

----------

## man in the hill

 *Winnt wrote:*   

> PS : Le kernel 2.6.33 est déjà dans les bacs  

 

Très bon article ici + des infos sur kvm et son fork que je ne connaissais pas d'ailleurs.

----------

## Winnt

Salut,

Oui les articles de DLFP sont toujours très intéressants à lire. Même si parfois je ne comprends pas tout   :Mr. Green: 

----------

## mannoula_ou

Bonjour, 

j'aimerai savoir s'il est possible de faire une image d'une machine virtuelle avec qemu, l'image de la machine est ce qu'elle peut se faire d'une maniere incrémentale et la sauvegarde est-il possible qu'elle soit sur un support de stockage comme une clé usb ou un disque dur externe 

merci beaucoup pour votre aide.

----------

## kwenspc

Tu peux faire un snapshot oui. Après je crois pas que ce soit incrémental, à chaque fois faut virer l'ancien et faire le nouveau. Mais je me trompe peut-être, depuis le temps ça a peut être été amélioré.

----------

## DuF

Bonjour,

Il faut plutôt regarder du côté du format d'image QCOW2 qui semble le supporter même si je n'ai jamais testé : http://people.gnome.org/~markmc/qcow-image-format.html

Et notamment les passages suivants :  *Quote:*   

> A QCOW image can be used to store the changes to another disk image, without actually affecting the contents of the original image. The image, known as a copy-on-write image, looks like a standalone image to the user but most of its data is obtained from the original image.

  *Quote:*   

> A snapshot is created by adding one of these headers, making a copy of the L1 table and incrementing the reference counts of all L2 tables and data clusters referenced by the L1 table.

 

----------

## man in the hill

Salut à tous ,

Je ne lâche tjrs pas la virtualisation avec kvm en ligne de commande ( je reste au plus basique, pas de surcouche).

En ce moment, je cherche vraiment a optimiser les accès disque en urgence car je n'obtiens guère plus de ~2Mo/s en copie en réseau et en local (Plus au demarrage de la copie mais cela retombe rapidement à ~2Mo/s).

J'ai ouvert le man qemu et fais des recherches et des tests, il en ressort que qemu-kvm gère plusieurs types de caches et selon cette option, les performances disques sont très différentes.

Types de caches:

```

Host: Linux wild 2.6.35-rc6 #1 SMP Sun Jul 25 21:19:50 AST 2010 x86_64 AMD Phenom(tm) II X4 955 Processor AuthenticAMD GNU/Linux

8Go de RAM

1 velociraptor de 150Go

Guest: Windows 2008 server r2

2Go de RAM

qemu-kvm -m 2048M -smp 4 -enable-kvm -name "2008 SERVER R2" -localtime -k fr -drive file=2008_server.qcow2,if=virtio,cache=unsafe,index=0,boot=on -net nic,model=virtio,macaddr=52:54:00:12:34:60 -net tap,ifname=tap20,script=no -usb -usbdevice tablet &

Copie d'un fichier .iso de 2,5Go

cache=writethrough : ~1,100Mo/s. ( c'est précisé ds le man que les performance sont désastreuses avec le format qcow2)

cache=none : ~1,500Mo/s. ( Commence à 13Mo/s mais chute rapidement)

cache=writeback : ~2Mo/s (Commence à 70Mo/s mais chute rapidement vers 4% du fichier à ~2Mo/s)

cache=unsafe : Commence très fort et Oscille entre 40 - 60 ( une fichier qui ce copie en qques seconde contrairement au autres modes)

 
```

Il n'a pas photos le mode cache=unsafe est le plus rapide mais il est soit disant dangereux et c'est ce dangereux à quel point que j'ai besoin de savoir en faisant appel à vos connaissances de fonctionnement d'OS. 

D'après ce que j'ai compris, qemu ne va pas commander d'écrire les données sur le disque et que si entre temps les données n'ont pas été synchronisé sur le disque et qu'il y a un arrêt brutal du pc, il y a risque de corruption de donnée. Mais est-ce qu'il y a plus de risque de corruption qu'un arrêt brutale avec un système hôte.

C'est un peu bas niveau et j'ai un peu de mal à y voir clair ...

Si il y a qqu'un qui s'y connait bien gestion de cache par l'OS ...

----------

## DuF

Bon suis dégouté, j'étais en train d'écrire un pavé de XX lignes et mon firefox a planté (j'avais oublié ce que ça faisait une application qui plante...).

Bon vais quand même reprendre mais très vite (je passe sur les différents niveaux de cache FS suivant le type de FS).

Normalement, une écriture sur disque ça va être : 

- commande écriture système invité => attente acquittement

- commande écriture système hôte => attente acquittement

- écriture disque => acquittement envoyé

Avec le unsafe ça va plutôt être : 

- commande écriture système invité => acquitté

- commande écriture système hôte => attente acquittement disque mais l'invité lui sans fou, c'est déjà acquitté

- écriture disque => acquittement envoyé à l'hôte

Donc s'il y a une coupure électrique après la 1ère étape, ton système croit qu'il a réellement écrit mais ça n'a jamais été le cas, il y a corruption de données ou perte d'intégrité.

Sinon je pense que ton test est incomplet, en effet l'écriture de gros fichiers est fortement impacté par la taille des caches FS et la mémoire disponible (et là t'en as 2 cache FS, un sur l'invité et un sur l'hôte) en plus en général la copie de gros fichiers c'est une très faible proportion des IOs. 

A ta place je ferai un test plus représentatif d'une activité habituelle, à savoir des plus petits fichiers et en plus grand nombre, style copie d'une partie de l'arborescence /usr par exemple et je comparerai les résultats. Surtout pour le mode none (moi je suis plutôt partisan de faire le moins d'empilement possible de niveau de cache) qui pour le coup devrait s'en sortir un peu mieux.

Sinon il y a aussi des tests à faire avec différents type de FS, je ne sais pas si ZFS sous linux c'est opérationnel et je n'ai pas trop suivi BRTFS, mais s'il y a un FS qui peut faire du primary cache (et secondary cache) comme ZFS, ça pourrait être intéressant de forcer ton KVM à monter en mémoire, si t'en as suffisamment de disponible bien sûr.

Il serait intéressant d'avoir aussi le comportement mémoire du système hôte pendant les tests (un vmstat et un top suffisent, le premier pour le swap et io et le top pour le cache FS).

Un peu dégouté d'avoir perdu mon précédent message qui était beaucoup plus précis sur les fonctionnement de cache (FS, disque, etc.) mais bon j'essairai de compléter mon message ce mardi (après je suis en congés loin loin loin de tout clavier  :Smile:  ).

----------

## man in the hill

Salut Duf,

je compatis avec toi pour le plantage de firefox, du coup son système de "cache" n'est pas terrible ...

C'est très intéressant ce que tu m'as écris et je vais refaire mes tests avec un hôte redémarré sans logiciel de lancé à part la vm. Faire avec gros, petits fichiers et observer côté vm et hôte.

Je reviens d'ici aujourd'hui ou demain.

Merci.

@ Bientôt.

----------

## DuF

Hello,

Si jamais t'as des résultats, comme je suis de retour de congés et que j'ai retrouvé "souris et clavier" je suis preneur de ton retour ou d'informations qui auraient pu expliquer ce que tu décrivais.

@+

----------

