qemu sur CentOS

Mise en eouvre de qemu sur CentOS 4.4

Alternative libre à VMware®


Auteur : Joseph BERAUD (jibe, jibe74)
Sources : QEMU : le site officiel, diverses pages web sur le sujet (voir l'annexe "Autres documents sur le sujet")
Testé sur CentOS 4.4 GPL
Mise à jour : 19 Mars 2006
Licence : GPL/GFDL


Permission est donnée de copier, diffuser et/ou modifier le présent document en vertu des conditions de la licence GPL, Version 2 ou toute autre version plus récente publiée par la fondation pour le logiciel ouvert « Free Software Foundation ». Permission accordée pour la production de copies mot à mot sans les textes de couverture et avec maintien des mentions de copyright et des auteurs. Une copie de la licence GFDL est disponible sur le site de la Free Software Foundation à l'adresse http://www.fsf.org/copyleft/fdl.html .

Tous les noms et marques de commerce sont la propriété de leurs titulaires respectifs.


1. But de ce document

1.1. A Propos de ce guide

Qemu est un émulateur permettant de créer des machines virtuelles. Il est donc une alternative, sous licence GPL, au produit propriétaire leader en ce domaine, VMware.

Disponible sous CentOS, utilisé non seulement comme base pour SME et donc FreeEOS, mais aussi souvent comme poste de développement pour ces distributions, Qemu peut donc être utilisé soit à des fins de tests lors du développement, soit pour divers autres buts s'il est installé sur FreeEOS ou SME.

Sa mise en oeuvre étant un peu particulière, ce petit guide devrait pouvoir aider ceux qui veulent l'utiliser à le mettre en place de telle sorte que les machines virtuelles qu'il supportera puissent accéder au réseau et aux partage Samba, ceci sans passer trop de temps à trouver la bonne marche à suivre parmi toutes celles proposées sur Internet.

Ce guide évoluera au fur et à mesure de mes essais, aussi n'hésitez pas à revenir régulièrement voir s'il a été complété. Vos remarques sur sa présentation et son contenu seront bien sûr les bienvenues.

1.2. Avertissement

Ce guide est réalisé après coup, et non pas pendant les essais. Il se peut donc que ma mémoire me trahisse et me fasse faire quelques oublis, confusions ou inversions chronologiques. Merci de me tenir au courant de ce que vous pourriez constater afin que je puisse le corriger.

En particulier, je risque fort d'oublier quelques paquets à installer : il y en a plusieurs que j'ai ajoutés au fur et à mesure des besoins. Ne soyez donc pas surpris si vous avez quelques messages indiquant soit qu'il manque une dépendance, soit qu'une commande est inconnue. En principe, vous devriez retrouver facilement ce qui manque. Merci là encore de me le signaler de façon à ce que je complète ce document.

1.3. Présentation

Si, pour une quelconque raison, la présentation de ce document ne vous convenait pas, sachez que vous pouvez en sélectionner une autre si vous disposez d'un navigateur conforme aux normes.

Avec Firefox, allez dans le menu "Affichage" puis "Style de la page" et sélectionnez celui que vous préférez.

Avec Opera, allez dans le menu "Afficher" puis "Style" et sélectionnez celui que vous préférez.

2. A savoir...

2.1. Prérequis

Etant moi-même un véritable newbie en matière de virtualisation et émulation, j'ai conçu ce guide de manière qu'il soit accessible au débutant. Le lecteur est malgré tout supposé connaitre les bases de linux et les commandes courantes. Il est aussi supposé avoir des bases en matière de réseau. Quelques connaissances en matière de sécurité, sans être indispensables, seront bien utiles également. Et pour pratiquer, il faut un quelconque ordinateur, pas trop ancien et avec un peu de mémoire afin de ne pas être trop lent, avec installé dessus une distribution CentOS 4.4 et quelques Go de libres dans le répertoire /home pour y installer les OS à émuler.

Mais je pense qu'une condition nécessaire et suffisante pour lire et utiliser ce guide est d'avoir envie d'apprendre par soi-même et par la pratique.

Ceux qui auraient un peu de mal à suivre ce guide pourront compléter leurs connaissances grâce au site Lea et du Léa book ou à l'excellent document "L'Internet rapide et permanent

2.2. Terminologie et abréviations

L'émulation est définie ainsi par Wikipédia : Un émulateur est un artefact logiciel qui remplace une base matériel existante ou ayant existé. Typiquement un émulateur sera un programme qui simulera un ordinateur, que ce soit un mainframe ou une console de jeux vidéo. Dans ce cadre, il est possible d'executer tous les programmes, systèmes d'exploitations inclus, prévu pour une machine donnée, sur son émulateur.

La virtualisation est l'ensemble des technologies matérielles et/ou logicielles permettant de faire fonctionner plusieurs applications, parties d'applications ou systèmes d'exploitation complets sur une même machine de manière isolée. (Wikipédia)

Un système d'exploitation (SE ou OS en anglais pour Operating System) est un ensemble cohérent de logiciels permettant d'utiliser un ordinateur et tous ses éléments (ou périphériques). Il assure le démarrage de celui-ci et fournit aux programmes applicatifs les interfaces pour contrôler les éléments de l'ordinateur. (Wikipédia). Les plus connus sont Windows® XP ou autres versions, les différentes distributions Linux, Mac OS.

La machine hôte est l'ordinateur équipé dans le cas de ce guide de CentOS 4.4 et de qemu, sur lequel seront installés les différents OS émulés.

Le système hôte (OS hôte) est l'OS installé sur la machine hôte, soit dans le cas de ce guide CentOS 4.4.

Le système virtuel (OS virtuel) est l'OS émulé par qemu sur la machine hôte.

Le disque virtuel est un fichier utilisé par qemu émulant le disque principal utilisé par l'OS virtuel.

2.3. Un peu de théorie

Pour expliquer en quelques mots à quoi sert qemu, disons que l'enjeu est le suivant : on voudrait, sans quitter notre OS favori que nous appellerons OS hôte, pouvoir disposer sur le même ordinateur d'un autre OS. Cela peut soit servir à faire l'économie d'un nouveau matériel, soit de mieux profiter de celui dont on dispose, l'OS hôte n'en utilisant pas pleinement toutes les ressources. Cela peut aussi servir à faire fonctionner un logiciel conçu pour un OS différent sans monopoliser pour lui seul un ensemble matériel complet.

Pour faire cela, nous allons utiliser un logiciel (qemu dans notre cas, il en existe d'autres dont le plus connu est VMware®) qui va émuler un matériel donné, c'est à dire simuler un matériel réel. L'émulateur simulera ainsi un ou plusieurs disques, une carte mère avec un processeur, une ou plusieurs cartes réseau etc. Chacun de ces éléments pouvant d'ailleurs être totalement différents du matériel hôte. On pourra ainsi par exemple simuler une plateforme alpha sur un matériel équipé d'un Pentium.

2.4. Les "accélérateurs"

Supposons, comme ce sera notre cas dans ce guide, que le matériel émulé soit le même que celui servant d'hôte. Plutôt qu'utiliser une couche logicielle recréant de toutes pièces un matériel virtuel, on peut se contenter de gérer un partage du matériel entre les OS hôte et virtuel. On gagne ainsi beaucoup en rapidité d'exécution.

Fabrice Bellard, l'auteur de qemu, a conçu un "accélérateur" qui réalise cela et augmente très nettement les performances de qemu. Malheureusement, il a choisi pour diverses raisons (principalement pour financer le développement de qemu) de ne pas mettre cet accélérateur sous licence GPL et d'en rêglementer l'utilisation. Je n'en parlerai donc pas dans ce guide.

Il existe par contre un logiciel libre : qvm86, développé principalement par Paul Brook. Son installation et son utilisation feront probablement partie d'une future version de ce guide.

2.5. Réseau d'essai

Il est important, pour bien comprendre et utiliser ce guide, de bien connaitre le réseau sur lequel il est basé. Un bon schéma valant mieux qu'une longue littérature, le voici en image :

schéma du réseau

3. Mise en oeuvre

3.1. Installation de qemu

Commençons par installer les paquets nécessaires à la mise en place de nos machines virtuelles. Certains sont directement liés à qemu (dépendances diverses) et d'autres sont nécessaires pour donner la possibilité aux machines virtuelles d'accéder au réseau.

Les paquets dont la liste suit sont installés avec "yum extender". Bien sûr, ceux qui estiment inutile de gaspiller les magnifiques couleurs de leur écran pour dessiner des cases à cocher pourront utiliser yum en ligne de commande qui ne nécessite normalement que du noir et du blanc ;-). On installera donc :

  • bridge-utils
  • qemu
  • uml-utilities

3.2. repositories

Ayant installé quelques repositories supplémentaires, j'avoue ne plus savoir exactement quels paquets font effectivement partie de la suite CentOS et ceux qui sont donnés par ces repositories aditionnelles. Voici la liste complète des repositories que j'utilise :

Et voici comment les configurer :

  • /etc/yum.repos.d/atrpms.repo

[atrpms]
name=RHEL $releasever - $basearch - ATrpms
baseurl=http://dl.atrpms.net/el$releasever-$basearch/atrpms/stable
gpgcheck=1
enabled=1

  • /etc/yum.repos.d/CentOS-Base.repo

[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-centos4

#released updates
[update]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-centos4

#packages used/produced in the build but not released
[addons]
name=CentOS-$releasever - Addons
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=addons
#baseurl=http://mirror.centos.org/centos/$releasever/addons/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-centos4

#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras
#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-centos4

#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-centos4

#contrib - packages by Centos Users
[contrib]
name=CentOS-$releasever - Contrib
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=contrib
#baseurl=http://mirror.centos.org/centos/$releasever/contrib/$basearch/
gpgcheck=1
enabled=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-centos4

  • /etc/yum.repos.d/rpmforge.repo

# Name: RPMforge RPM Repository for Red Hat Enterprise 4 - dag
# URL: http://rpmforge.net/
[rpmforge]
name = Red Hat Enterprise $releasever - RPMforge.net - dag
#baseurl = http://apt.sw.be/redhat/el4/en/$basearch/dag
mirrorlist = http://apt.sw.be/redhat/el4/en/mirrors-rpmforge
#mirrorlist = file:///etc/yum.repos.d/mirrors-rpmforge
enabled = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag
gpgcheck = 1

3.3 Préparation des scripts nécessaires

3.3.1. Le bridge pour le réseau

La machine virtuelle devra pouvoir disposer d'au moins une carte réseau. Mais matériellement, la carte en place est utilisée par la machine hôte. Il y a plusieurs façons de procéder pour rendre disponible la carte à la machine virtuelle tout en laissant la machine hôte s'en servir normalement. La manière que j'ai retenue est de faire un "bridge". Cela permet d'utiliser le réseau quasi normalement tant sur la machine hôte que sur la machine virtuelle, comme s'il s'agissait de machines physiques séparées.

Le principe du bridge est relativement simple. Il s'agit d'intercaler entre la carte physique et les OS utilisés une couche logicielle qui va leur faire croire qu'ils possèdent chacun leur propre carte. Ainsi, notre interface eth0 (ou une autre) se verra dotée d'une sorte de switch logiciel et partagée en deux nouvelles interfaces :

schéma du bridge

Le bridge joue exactement le rôle d'un switch, c'est à dire qu'il va aiguiller convenablement les paquets entrants et sortants et les acheminer jusqu'à l'interface voulue.

La mise en place du bridge se fait par le script suivant :

#!/bin/sh
#####################################
# Mise en place d'un bridge pour qemu
#
# Auteur : Joseph BERAUD
# aka jibe, jibe74
#####################################
# Adresse IP de la machine hote
host_ip=192.168.1.11

# Adresse de la passerelle internet
gw_ip=192.168.1.1

# Adresse de boadcast du reseau local
brcst_ip=192.168.1.255

# Utilisateur qui lancera qemu
qemu_user='joseph'

echo 'Mise en place du bridge...'

# Creation du device tun0
# qui servira de carte reseau virtuelle
# a l'OS virtualise par qemu
/usr/bin/tunctl -u $qemu_user -t tun0

# On arrete la carte ethernet
/sbin/ifconfig eth0 down

# On cree un bridge
/usr/sbin/brctl addbr br0

# On met en route les deux "cartes" ethernet
# Sans IP puisque configurées plus tard et différemment...
/sbin/ifconfig eth0 0.0.0.0 promisc up
/sbin/ifconfig tun0 0.0.0.0 promisc up

# On donne l'IP de l'hote au bridge qu'on active
/sbin/ifconfig br0 $host_ip netmask 255.255.255.0 broadcast $brcst_ip up

# On parametre le bridge
/usr/sbin/brctl stp br0 off
/usr/sbin/brctl setfd br0 1
/usr/sbin/brctl sethello br0 1

# On connecte nos deux "cartes" ethernet sur le bridge
/usr/sbin/brctl addif br0 eth0
/usr/sbin/brctl addif br0 tun0

# On definit la passerelle internet
/sbin/route add default gw gw_ip

# On s'asure que /dev/net/tun est accessible
# par tous les utilisateurs
# On le fait ici, parce qu'il arrive que les
# droits changent pendant la mise en place du
# bridge... A étudier pourquoi et éventuellement
# supprimer ce workaround...
chmod 666 /dev/net/tun

# Et on est pret : qemu parametrera lui-meme sa
# "carte" tun0 lors du lancement.
# en attendant, l'OS hote devrait acceder normalement
# au reseau et a internet.

echo 'Fin de mise en place du bridge'

Créez (par copier-coller ;-)) ce script à l'aide de votre éditeur favori et enregistrez-le dans votre répertoire home sous un nom dont vous vous rappellerez facilement, par exemple "mkbridge". N'oubliez pas d'adapter les adresses IP à vos besoins ! Donnez-lui ensuite les droits d'exécution par un

[toto@OShote ~] $ chmod 755 mkbridge

Je n'ai pas créé de script pour supprimer le bridge lorsque je n'en ai plus besoin : étant donné qu'il est totalement transparent pour l'OS hôte, je le laisse en place. Il serait même possible de le mettre en place au boot, de sorte qu'il soit disponible immédiatement si besoin. C'est probablement ce que je ferai dès que je trouverai quelques minutes !

Ce script devra être lancé avant toute utilisation du réseau par une machine virtuelle. Il devra être lancé avec les droits root, le plus simple étant de le faire via "sudo", ce qui nécessite auparavant une petite configuration détaillée ci-après. Une fois "sudo" configuré, il suffit pour mettre en place le bridge de taper dans un terminal ou une console

[toto@OShote ~] $ sudo ./mkbridge

3.3.2. Autoriser l'utilisation de «sudo»

La manipulation suivante a pour but d'autoriser un utilisateur (que nous nommerons "toto" pour l'exemple) à utiliser inconditionnellement la commande "sudo" sans aucun mot de passe. Il est fort possible que cela pose des problèmes de sécurité. Si cela peut être le cas, il faudrait restreindre l'utilisation de "sudo" et/ou imposer un mot de passe. Cela est décrit en détails dans les pages de man, aussi j'invite ceux qui voudraient plus de sécurité à les consulter :

[toto@OShote ~] $ man sudo
[toto@OShote ~] $ man sudoers

Afin de permettre la mise en place du bridge par l'utilisateur "toto", nous devons l'autoriser à utiliser la commande "sudo". Si nous supposons être dans un micro-réseau personnel, nous l'autoriserons à le faire sans saisir de mot de passe. Par la même occasion, nous allons autoriser l'utilisateur spécial "qemu" (créé par le logiciel qemu pour son propre usage) à utiliser sudo également pour la mise en place de l'environnement nécessaire. Pour ce faire, il suffit d'insérer les lignes suivantes dans /etc/sudoers :

%qemu ALL=NOPASSWD:/usr/local/bin/env-qemu
%toto ALL=(ALL) NOPASSWD: ALL

"toto" est bien entendu à remplacer par l'utilisateur qui lancera le script de mise en place du bridge et lancera qemu.

Le fichier /etc/sudoers est en lecture seule, et attribué à root. Il vous faudra donc être root pour effectuer la modification, et soit en changer préalablement les droits, soit forcer l'écriture par la commande w! si vous utilisez vi. N'oubliez pas, si vous changez les droits, de remettre ceux d'origine une fois la modification effectuée !

[root@OShote ~] # chmod 640 /etc/sudoers
[root@OShote ~] # vi /etc/sudoers
[root@OShote ~] # chmod 440 /etc/sudoers

3.3.3. qemu-ifup

A son lancement, qemu appelle le script /etc/qemu-ifup qui va mettre en place l'environnement nécessaire et surtout activer le bridge en fonction des options stipulées sur la ligne de commande. Il nous faut donc créer ce script qui devra contenir le code suivant :

#!/bin/sh

echo "Execution de /etc/qemu-ifup"
echo "Activation de $1 en mode bridge..."
sudo /sbin/ifconfig $1 0.0.0.0 promisc up
echo "Ajout de $1 à br0..."
sudo /usr/sbin/brctl addif br0 $1
sleep 2

Ce script devra être créé sous root, et il faudra ensuite lui attribuer les droits voulus :

[root@OShote ~] # chmod 755 /etc/qemu-ifup

3.3.4. Lancement de qemu

Un autre script qui nous sera fort utile (bien que non indispensable) est celui qui nous servira à lancer qemu avec toute la ligne de commande nécessaire pour mettre en route une machine virtuelle. Cette ligne de commande étant directement fonction de la machine virtuelle à lancer et des possibilités et fonctions qu'on veut lui donner, je ne donnerai qu'un exemple de lancement d'une VM faisant tourner un Windows 98 ayant plein accès au réseau et à la carte son. A chacun de composer son propre script en fonction de ses besoins en se référant à l'annexe d'invocation de qemu

#!/bin/sh
#####################################
# Lancement de Windows 98 en VM qemu
#
# Auteur : Joseph BERAUD
# aka jibe, jibe74
#####################################

# J'utilise numlockx pour activer le pavé numérique
# lors de l'ouverture de session. Mais cela pose
# un problème à l'OS virtuel -> désactivation au
# lancement, puis réactivation en fin.
numlockx off
qemu -hda w98.img -soundhw sb16 -localtime -m 256 -net nic,vlan=0 -net tap,vlan=0,script=/etc/qemu-ifup -usb
numlockx on

N'oubliez pas de rendre votre script exécutable par un

[toto@OShote ~] $ chmod 755 w98

3.4. Préparation d'un disque virtuel

La première chose à faire, pour mettre en place un OS virtuel, est de lui créer un disque virtuel. Ceci se fait généralement dans le répertoire /home de l'OS hôte. Ce disque virtuel est en fait un fichier auquel vous pouvez donner le nom que vous voulez et la taille que vous voulez (sous réserve, bien sûr, qu'elle soit suffisante pour contenir l'OS invité ;-)). Nous allons donc créer un disque de 3 Go pour notre windows 98 virtuel :

[toto@OShote ~] $ qemu-img create -f qcow w98.img 3G

Comme vous le devinez, w98.img est le nom du fichier qui contient le disque virtuel et 3G est la capacité demandée. Pour connaitre toutes les options de qemu-img, consultez la documentation de qemu. Mais vous pouvez généralement vous contenter de la commande indiquée ici en adaptant le nom du fichier et la capacité. Si vous avez besoin de créer des images compatibles avec VMware, utilisez

[toto@OShote ~] $ qemu-img create -f vmdk w98.img 3G

3.5. Mise en place du bridge

Bien qu'il ne soit généralement pas nécessaire à ce stade, nous allons expliquer dès à présent comment mettre en place le bridge : il peut être préférable dans certains cas qu'il soit en place lors de l'installation de l'OS virtuel.

Puisque nous avons créé un script, il suffit de le lancer (souvenez-vous : par "sudo" pour mettre en place le bridge :

[toto@OShote ~] $ sudo ./mkbridge

Puisque c'est la première fois, nous allons nous assurer que tout s'est bien passé. Pour cela, nous devons agir en tant que root. Si vous le faites dans un terminal sous X, souvenez-vous de passer root par la commande

[toto@OShote ~] $ su -
password:
[root@OShote ~] #

En effet, c'est seulement ainsi que vous aurez l'environnement correctement paramétré. Si vous omettez le tiret (signe -) aditionnel, vous conserverez l'environnement d'un utilisateur normal, ce que vous pouvez voir au prompt root qui s'affiche :

[toto@OShote ~] $ su -
password:
[root@OShote toto] #

Une fois root, vérifions la bonne mise en place de notre bridge :

[root@OShote ~] # ifconfig | less

Nous devrions constater la présence, en plus de la boucle locale, de nos trois interfaces br0, eth0 et tun0. Il est normal que tun0 n'ait pas encore d'adresse IP, elle sera configurée ultérieurement. Par contre, br0 et eth0 devraient avoir la même IP, celle du poste hôte soit 192.168.1.11 dans mon cas personnel.

3.6. Installation d'un OS à partir du CD

Vous devez disposer du CD, à moins que vous n'en ayez l'image ISO. Il vous faut alors lancer qemu en lui demandant de booter soit sur le CD :

[toto@OShote ~] $ qemu -cdrom /dev/cdrom -hda w98.img -m 256 -boot d

soit sur l'image ISO :

[toto@OShote ~] $ qemu -cdrom my_os_install.iso -hda w98.img -m 256 -boot d

Bien sûr, vous aurez pris soin de remplacer w98.img par le nom du fichier de disque virtuel que vous avez choisi. Alors, vous constatez la magie : une fenêtre s'ouvre, et vous voyez se dérouler le boot, puis l'installation de l'OS virtuel ! Hormis le fait que c'est un peu plus long, à cause de l'émulation bien sûr, tout se passe comme si vous installiez sur un PC flambant neuf, sauf que c'est dans une fenêtre et que vous pouvez tranquillement continuer à utiliser votre OS hôte pendant l'installation ! Et ce, sans perte de performance sensible !

Procédez donc comme s'il s'agissait d'une installation normale, configurez votre nouvel OS comme vous en avez l'habitude. Vous constatez quelques petites choses surprenantes lorsqu'il s'agit du matériel. Par exemple, la carte réseau détectée est une NE2000 ! Eh oui, qemu s'interpose et émule ce type de carte, et votre OS virtuel est persuadé que ce que lui présente qemu est une carte bien réelle... et un peu ancienne !

4. Utilisation

4.1. Lancement d'un OS virtuel

Une fois fini d'installer, il nous faut lancer l'OS virtuel en passant à qemu plusieurs options lui permettant d'émuler correctement le matériel. Il peut aussi être nécessaire de lancer des commandes avant ou après qemu. Pour simplifier tout cela, nous pouvons faire un script comme décrit au paragraphe 3.3.4. Mais auparavant, il faut installer le bridge. Puisque nous ne le désinstallons pas, il ne faudra l'installer une fois et une seule entre le boot de l'OS hôte et le premier lancement d'un OS virtuel.

Comme nous l'avons déjà vu, la mise en place manuelle du bridge se fait par la commande

[toto@OShote ~] $ sudo ./mkbridge

Il est aussi possible de faire en sorte que le bridge soit mis en place dès le démarrage de l'OS hôte. Nous lançons alors l'OS virtuel en invoquant simplement le script prévu à cet effet. Pour lancer mon Windows 98, il me suffit de faire :

[toto@OShote ~] $ ./w98

4.2. Utilisation de l'OS virtuel

Il n'y a pas grand'chose à dire sur l'utilisation d'un OS virtuel, puisqu'il se comporte presque exactement comme un OS réel. Il peut accéder au réseau, et donc communiquer avec son hôte via le réseau aussi bien que travailler avec les partages samba.

4.2.1 Souris

Normalement, la souris est gérée indépendamment par les deux OS, hôte et virtuel. Ceci lui donne un comportement un peu surprenant au premier abord, mais auquel on s'habitue très vite. En effet, lorsqu'on clique une première fois dans la fenêtre de l'OS virtuel, rien ne se passe et on a même souvent l'impression d'avoir perdu le curseur. En fait, c'est parce que la souris est "capturée" par l'OS virtuel, qui a mémorisé son ancienne position (ou celle, centrale, du départ).

D'ailleurs, on voit bien lorsque la souris est gérée par l'OS hôte, qu'il existe un curseur restant immobile dans la fenêtre de l'OS virtuel. Après un premier clic dans sa fenêtre, l'OS virtuel prend le contrôle de la souris qu'il place à l'endroit de son curseur (celui qui était immobile), quel que soit l'endroit où on a cliqué.

La souris est alors prisonnière de la fenêtre de l'OS virtuel. Pour redonner le contrôle à l'OS hôte, il suffit d'appuyer simultanément sur les touches CTRL et ALT. Le curseur de l'OS virtuel s'immobilise, et celui de l'OS hôte réapparait.

La documentation de qemu donne une façon d'obtenir un passage fluide et automatique entre les deux OS. Je n'ai pas (encore ;-)) réussi à faire fonctionner cela. Mais une fois qu'on a pris l'habitude, je trouve que cela va très bien sans...

4.2.2 Imprimante

L'utilisation d'une imprimante ne pose pas de problème, sauf qu'évidemment on ne peut avoir d'imprimante locale : même l'imprimante de l'hôte est considérée comme appartenant à un autre poste du réseau. Il faut donc mettre en oeuvre les techniques habituelles de partage d'imprimante et d'utilisation d'imprimante partagée.

4.2.3 CD et DVD

Pour l'utilisation du lecteur (je n'ai pas tenté la gravure...) de CD ou DVD, il semble qu'on soit obligé d'invoquer l'OS virtuel spécialement et que la présence du CD dans le lecteur soit obligatoire lors du boot de l'OS virtuel. Il faut ajouter dans les options de commante :

5. Autres OS virtuels

5.1. Cohabitation et réseau

5.1.1 Bridge

Le bridge que nous avons mis en place va pouvoir servir à partager la connexion entre l'OS hôte et plusieurs OS virtuels. Ceci sera fait le plus simplement, sans aucune intervention, par l'ajout d'une interface tap1, tap2... tapn en plus de celle(s) existante(s).

Lors de l'installation ou de la mise en place ultérieure de la couche réseau de l'OS, on aura tout intérêt à avoir déjà lancé les autres OS virtuels nécessitant une interface réseau classée avant. En effet, il arrive que, l'interface virtuelle ayant été détectée, il soit demandé le n° ethernet de cette interface afin que la bonne soit prise en compte. Si la question est posée, et dans la mesure où le bridge a bien été mis en place et les autres OS lancés, il suffit d'ouvrir un nouveau terminal et d'y taper :

[toto@OShote ~] $ su -
password:
[root@OShote ~] #
ifconfig

puis de lire l'adresse ethernet de l'interface voulue.

5.2. Windows NT4

5.2.1 Installation

L'installation de NT4 pose un petit problème, puisqu'après avoir formatté le disque et y avoir copié les fichiers qui lui sont nécessaires, l'installateur de NT4 demande de rebooter sur le disque dur, puis continue l'installation en demandant où trouver les fichiers à installer (Ceux-ci se trouvent sur le CD, bien entendu).

Or, le CD ayant souvent été monté automatiquement par l'OS hôte, il est impossible de le retirer du lecteur. Ce qui fait qu'on boote à nouveau depuis le CD et qu'on reboucle indéfiniment sur la première partie de l'installation.

Je n'ai pas réussi, même en «unmountant» le CD depuis l'OS hôte, à l'enlever proprement. La seule solution que j'ai trouvée est d'arrêter sauvagement l'installation en cliquant sur le X de fermeture de la fenêtre.

Pour pouvoir terminer l'installation de NT4, il nous faut un accès au CD tout en bootant sur le disque dur virtuel. On aura aussi intérêt à mettre en place le réseau (penser, si ce n'est pas déjà fait, à lancer le script de mise en place du bridge et à lancer les autres OS virtuels qui doivent prendre les premières interfaces - cf § 5.1) afin de le rendre opérationnel dès l'installation (non obligatoire). Pour cela, nous invoquons qemu de la façon suivante :

[toto@OShote ~] $ qemu -hda nt4.img -cdrom /dev/cdrom -m 350 -net nic,vlan=0 -net tap,vlan=0,script=/etc/qemu-ifup

Bien entendu, les options sont à adapter à votre cas, en particulier le nom du disque virtuel (ici nt4.img) et la quantité de mémoire désirée (ici 350 Mo)

5.2.2 script de lancement

Comme cela avait été fait pour Windows 98, on peut écrire un petit script de lancement comportant les options souhaitées. A chacun de composer le sien propre en fonction de ses besoins en se référant à l'annexe d'invocation de qemu. Voici celui que j'ai créé pour mes besoins personnels :

#!/bin/sh
#####################################
# Lancement de Windows NT4 en VM qemu
#
# Auteur : Joseph BERAUD
# aka jibe, jibe74
#####################################

# J'utilise numlockx pour activer le pavé numérique
# lors de l'ouverture de session. Mais cela pose
# un problème à l'OS virtuel -> désactivation au
# lancement, puis réactivation en fin.
numlockx off
qemu -hda nt4.img -soundhw sb16 -localtime -m 256 -net nic,vlan=0 -net tap,vlan=0,script=/etc/qemu-ifup -usb
numlockx on

A. Annexes

A.1. Invocation de qemu

Ce chapitre est la traduction d'une partie de la documentation officielle qemu

[toto@OShote ~] $ qemu [options] [disk_image]

disk_image est une image disque brut pour le premier disque dur.

Options générales :

`-M machine'
Précise la machine émulée (-M ? pour obtenir la liste)

`-fda fichier'
`-fdb fichier'

Utilise fichier comme image de premier ou second lecteur de disquettes (voir la section 3.6 sur les images disque). Vous pouvez utiliser le lecteur de disquettes de la machine hôte en mettant `/dev/fd0' comme nom de fichier.

`-hda fichier'
`-hdb fichier'
`-hdc fichier'
`-hdd fichier'

Utilise fichier comme image disque 0, 1, 2 ou 3 (voir la section 3.6 sur les images disque).

`-cdrom fichier'
Utilise fichier comme image du CD-ROM (vous ne pouvez pas utiliser `-hdc' et `-cdrom' en même temps). Vous pouvez utiliser le CD-ROM de la machine hôte en mettant `/dev/cdrom' comme nom de fichier.

`-boot [a|c|d]'
Boote sur le lecteur de disquettes (a), le disque dur (c) ou le CD-ROM (d). Par défaut, boote sur le disque dur.

`-snapshot'
Ecrit dans un fichier temporaire plutôt que sur les images disque. Dans ce cas, l'image brute du disque que vous utilisez n'est pas ré-écrite. Vous pouvez cependant forcer la ré-écriture en appuyant sur les touches C-a s (voir la section 3.6 sur les images disque).

`-no-fd-bootchk'
Désactive le test de la signature du boot pour les lecteurs de disquette dans le bios Bosh. Il pourrait être nécessaire pour booter depuis d'anciennes disquettes.

`-m megs'
Fixe la taille de mémoire RAM à megs Mo. Par défaut, elle est de 128 MB.

to be continued...

A.2. Autres documents sur le sujet

Site officiel de QEMU
quemu networking
qemu 'networking howto' supplied

A.3. Changelog

19 Mars 2008 : Intégration au site BJ-Informatique.

27 Octobre 2006 (non publié) : Présentation "FreeEOS"

24 Octobre 2006 (non publié) : divers petits compléments et corrections suggérés par Caymus - comportement de la souris - Autres OS (NT4) - Autres présentations

18 Octobre 2006 : Version originale "presque complète"


Nagasunod sa CSS Conformité XHTML 1.1 Nagasunod sa istandard Babaw sang pahina Puluy-anInformaticsTraduksiyonDokumentasyonSari-sari
Dokumentasyonqemu on CentOS