qemu et réseau

jip wrote:

bonjour,

Sous Kubuntu, qemu fonctionne très bien (avec connexion au web
du pc émulé), MAIS je n'arrive jamais à 'ajouter' à mon réseau local
le pc émulé.
J'ai cherché sur le web et essayé pas mal de trucs, toujours sans
succés.
Comment (le + simplement possible) lancer qemu sur un disque virtuel
préalablement créé et hébergeant un OS (par exemple win98se ou
aussi une distribution linux légère) en le 'raccordant' à mon LAN ?

merci,
jip

si l'OS émulé sous qemu "voit" le web, c'est que tu as correctement
configuré l'IP de l'OS émulé et l'interface tun/tap sur l'hôte.
pour "voir" le lan, il faut passer par un répertoire public de samba sur la
machine hôte et déclarer ce répertoire sur l'OS émulé.

exemple : soit un répertoire "public" /public_smb sur la machine hôte,
le script de lancement de l'OS émulé par qemu doit ressembler à cela :

1) préparation avant lancement de qemu par un script qemu_prep :
#!/bin/bash
sudo vde_switch -tap tap0 -daemon
sudo /sbin/chmod 777 /tmp/vde.ctl

et lancement de qemu (un Win98SE) :

#!/bin/sh
export QEMU_AUDIO_DRV=alsa
cd /win_d
qemu -k fr -m 256 -localtime -soundhw sb16 -net nic -net tap
-smb /public_smb -hda w98.img -boot c

/win_d est le répertoire des images pour qemu
-k permet d'utiliser le module kqemu (accélération très visible)
m 256 donne 256 MO de ram à l'OS émulé
-soundhw sb16 permet d'utiliser la carte son (avec alsa)
-net nic et -net tap --> interfaces OS émulé / OS hôte, doivent être dans le
même segment de réseau que le serveur samba de l'hôte.
-smb donne accès au répertoire public de l'OS hôte
pour lire et écrire dans le système hôte, il suffit de créer des liens
symboliques dans le smb public vers les répertoires du système hôte, en
veillant aux droits d'accès.
petit effet de bord inexpliqué (du moins sur mon système) :
quand Win98SE est lancé sous qemu, il voit bien le répertoire public de
l'hôte et les répertoires visés par les liens symboliques, il accède au
net, mais le réseau samba du lan est coupé (serveur samba de l'hôte
recouvert par le serveur samba du Win émulé qui ne voit que lui et le
public), et connection au net coupée pour les autres machines du lan.
j'ignore si c'est dû à qemu ou aux règles iptables de l'hôte (assez
serrées),
si quelqu'un avait des lumières là-dessus, ça m'intéresse, merci.
et toujours dans les détails intéressés, il y a aussi un OS2/Warp4 sous
qemu, mais .... en fenêtre 640x480, because les pilotes officiels (OS2) de
la carte graphique plantent systématiquement OS2 ! si quelqu'un connait un
pilote OS2 qui ne plante pas sous qemu, il aura droit à un bon de
consulation gratuite + une tringle à rideau ...

A+

Ça c'est de la réponse !
LE paquet ;-)
Je n'ai pas tout compris à la première lecture, mais je m'y colle.

Merci beaucoup.

jip

Je m'y suis collé....
================================================================ Pour information, quand je lance qemu de cette façon:
qemu win98se_ok -localtime -soundhw sb16 -m 512 -net nic -net
user -cdrom /dev/cdrom
(une seule ligne)
win se lance bien et j'accède au web.
================================================================ Par contre, à partir de ta réponse:

si l'OS émulé sous qemu "voit" le web, c'est que tu as correctement
configuré l'IP de l'OS émulé et l'interface tun/tap sur l'hôte.
euh, j'ai rien fait, m'sieu...

j'ai juste ajouté l'IP de la passerelle (mon modem-routeur) dans les
options de Voisinage Réseau (en laissant 'obtenir automatiquement une
adresse Ip')
d'ailleurs winipcfg me dit:
IP: 10.0.2.15
Masque sous-réseau: 255.255.255.0
Passerelle par défaut: 10.0.2.2
Et je jure (sauf par hasard ;-) ne rien n'avoir fait en tun/tap...

1- Je ne comprends pas à quoi sert /tmp/vde.ctl
après ton premier script (qemu_prep), j'ai bien:
srwxrwxrwx 1 root root 0 2006-10-19 15:20 vde.ctl

2- mais au lancement du second script, j'ai:
SIOCSIFNETMASK: Ne peut attribuer l'adresse demandée
SIOCSIFADDR: Permission non accordée
SIOCSIFFLAGS: Permission non accordée
/etc/qemu-ifup: could not launch network script
Could not initialize device 'tap'

et arrêt du programme.

3-par contre si je le lance en su, ça "passe" (win98se se
lance) mais avec le message:
SIOCSIFNETMASK: Ne peut attribuer l'adresse demandée

et je n'accède plus au web sous win98 ! (ni à un quelconque réseau)

désolé,
help !

merci
jip

jip wrote:

Je m'y suis collé....
================================================================ > Pour information, quand je lance qemu de cette façon:
qemu win98se_ok -localtime -soundhw sb16 -m 512 -net nic -net
user -cdrom /dev/cdrom
(une seule ligne)
win se lance bien et j'accède au web.
================================================================ > Par contre, à partir de ta réponse:

si l'OS émulé sous qemu "voit" le web, c'est que tu as correctement
configuré l'IP de l'OS émulé et l'interface tun/tap sur l'hôte.
euh, j'ai rien fait, m'sieu...

j'ai juste ajouté l'IP de la passerelle (mon modem-routeur) dans les
options de Voisinage Réseau (en laissant 'obtenir automatiquement une
adresse Ip')
d'ailleurs winipcfg me dit:
IP: 10.0.2.15
Masque sous-réseau: 255.255.255.0
Passerelle par défaut: 10.0.2.2
Et je jure (sauf par hasard ;-) ne rien n'avoir fait en tun/tap...

1- Je ne comprends pas à quoi sert /tmp/vde.ctl
après ton premier script (qemu_prep), j'ai bien:
srwxrwxrwx 1 root root 0 2006-10-19 15:20 vde.ctl

2- mais au lancement du second script, j'ai:
SIOCSIFNETMASK: Ne peut attribuer l'adresse demandée
SIOCSIFADDR: Permission non accordée
SIOCSIFFLAGS: Permission non accordée
/etc/qemu-ifup: could not launch network script
Could not initialize device 'tap'

et arrêt du programme.

3-par contre si je le lance en su, ça "passe" (win98se se
lance) mais avec le message:
SIOCSIFNETMASK: Ne peut attribuer l'adresse demandée

et je n'accède plus au web sous win98 ! (ni à un quelconque réseau)

désolé,
help !

merci
jip

normal !

l'adresse de l'interface de l'OS émulé est attribuée en dhcp par le routeur
"internet", ce qui construit un lien ethernet "Interface OS émulé" <--->
"Routeur", lequel passe par dessus le lan.

Admettons que le lan (OS hôte) soit dans le segment 192.168.0 avec deux
interfaces ethernet, une eth0 reliée au routeur internet avec ip attribée
en dhcp par le routeur soit 10.0.2.15, une eth1 reliée au lan avec ip
192.168.0.1.
l'OS hôte assure le routage entre le segment 10.0.2 (côté "internet") et le
segment local 192.168.0 (forward, nat, masquerade, filtrage, etc).

le schéma devient :
eth0 (10.0.2.15) <---> Hôte <---> eth1 (192.168.0.1) <---> Lan

pour "voir" le lan depuis l'OS émulé, il faut une interface côté Hôte
(192.168.0.10 par exemple) et une interface côté machine émulée
(192.168.0.20 par exemple), dans le segment du lan pour voir le répertoire
samba public depuis l'OS émulé.

l'interface (virtuelle, il n'y a pas de carte physique) côté hôte est
"construite" par le module "tun", device /dev/tun 10,200 avec un lien
symbolique /dev/net/tun --> /dev/tun.
l'activation de cette interface est faite par vde_switch :
sudo vde_switch -tap tap0 -daemon
à ce moment, ifconfig donne :
tap1 Lien encap:Ethernet HWaddr 9E:38:5D:B8:BF:01
inet adr:192.168.10.10 Bcast:192.168.10.255 Masque:255.255.255.0
adr inet6: fe80::9c38:5dff:feb8:bf01/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:38 errors:0 dropped:0 overruns:0 frame:0
TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:500
RX bytes:4079 (3.9 Kb) TX bytes:1086 (1.0 Kb)
la communication se fait par la socket /tmp/vde.ctl, qu'on doit mettre en
777 pour être utilisable par les users.

ne reste plus que l'interface côté OS émulé, une simulation de RealTek 8029,
à laquelle on donne une ip 192.168.0.(20 par exemple), et passerelle sur
192.16.0.1 pour communiquer avec l'extérieur.

le schéma est maintenant :

(wan par routeur) <---> Hôte etho 10.0.2.15 <---> Hôte lan eth1 192.168.0.1
<---> Hôte vers Qemu tap1 192.168.0.10 <---> OS émulé 192.168.0.20

pré-requis :
le module tun et le device tun pour l'interface virtuelle,
le module kqemu pour une vitesse raisonnable,
le programme vde_switch pour construire et utiliser l'interface tap,
le programme sudoers pour ifconfig en user, mettre dans /etc/sudoers :
# User alias specification
#Users ::= le login des users autorisés
User_Alias ROOT_FRIENDS = le login des users "root friendly"
# Cmnd alias specification
#Cmnd ::= /bin/chmod , /sbin/ifconfig , /bin/mount
Cmnd_Alias QEMU = /bin/chmod, /sbin/ifconfig, /bin/mount, /bin/umount

ça ira, comme ça ?
A+

bonjour,

Tes explications (longues et très détaillées) me sont précieuses.
Arrivé ici:

l'interface (virtuelle, il n'y a pas de carte physique) côté hôte est
"construite" par le module "tun", device /dev/tun 10,200 avec un lien
symbolique /dev/net/tun --> /dev/tun.
(j'ai bien un /dev/net/tun

crw-rw-rw- 1 root root 10, 200 2006-05-31 03:15 /dev/net/tun
mais pas de /dev/tun)

Ça ne semble pas clair du tout ;-) mais je me laisse (bêtement) guider.

l'activation de cette interface est faite par vde_switch :
sudo vde_switch -tap tap0 -daemon
à ce moment, ifconfig donne :
ben non ! je n'ai pas de tap1 à ce stade

tap1 Lien encap:Ethernet HWaddr 9E:38:5D:B8:BF:01
inet adr:192.168.10.10 Bcast:192.168.10.255
Masque:255.255.255.0 adr inet6: fe80::9c38:5dff:feb8:bf01/64
Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:38 errors:0 dropped:0 overruns:0 frame:0
TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:500
RX bytes:4079 (3.9 Kb) TX bytes:1086 (1.0 Kb)
la communication se fait par la socket /tmp/vde.ctl, qu'on doit mettre en
777 pour être utilisable par les users.
ok, ok; j'avais bien compris ça au travers du script qemu_prep

la suite me semble couler de source... si je peux y arriver !

ne reste plus que l'interface côté OS émulé, une simulation de RealTek
8029, à laquelle on donne une ip 192.168.0.(20 par exemple), et passerelle
sur 192.16.0.1 pour communiquer avec l'extérieur.

le schéma est maintenant :

(wan par routeur) <---> Hôte etho 10.0.2.15 <---> Hôte lan eth1
192.168.0.1 <---> Hôte vers Qemu tap1 192.168.0.10 <---> OS émulé
192.168.0.20

pré-requis :
le module tun et le device tun pour l'interface virtuelle,
le module kqemu pour une vitesse raisonnable,
le programme vde_switch pour construire et utiliser l'interface tap,
le programme sudoers pour ifconfig en user, mettre dans /etc/sudoers :
# User alias specification
#Users ::= le login des users autorisés
User_Alias ROOT_FRIENDS = le login des users "root friendly"
# Cmnd alias specification
#Cmnd ::= /bin/chmod , /sbin/ifconfig , /bin/mount
Cmnd_Alias QEMU = /bin/chmod, /sbin/ifconfig, /bin/mount, /bin/umount

ça ira, comme ça ?
Je fais pourtant des efforts... pour suivre. Désolé.

A+
merci du temps passé à essayer de me sortir de l'ornière.

bon we
jip

jip wrote:

bonjour,

Tes explications (longues et très détaillées) me sont précieuses.
Arrivé ici:

merci, ya pas de quoi, c'est un plaisir

l'interface (virtuelle, il n'y a pas de carte physique) côté hôte est
"construite" par le module "tun", device /dev/tun 10,200 avec un lien
symbolique /dev/net/tun --> /dev/tun.
(j'ai bien un /dev/net/tun

crw-rw-rw- 1 root root 10, 200 2006-05-31 03:15 /dev/net/tun
mais pas de /dev/tun)

pas grave ! dans ce cas, faire un lien symbolique /dev/tun pointant
sur /dev/net/tun
non, ce n'est pas inutile, il faut les deux, sinon ça merdoie

Ça ne semble pas clair du tout ;-) mais je me laisse (bêtement) guider.

l'activation de cette interface est faite par vde_switch :
sudo vde_switch -tap tap0 -daemon
à ce moment, ifconfig donne :
ben non ! je n'ai pas de tap1 à ce stade

as-tu installé le paquet vde ?
c'est un tar.gz facile à trouver avec google
sur mon système actif (MDV LE2005), c'est le vde-1.5.11

la communication se fait par la socket /tmp/vde.ctl, qu'on doit mettre en
777 pour être utilisable par les users.
ok, ok; j'avais bien compris ça au travers du script qemu_prep

la suite me semble couler de source... si je peux y arriver !
Je fais pourtant des efforts... pour suivre. Désolé.

merci du temps passé à essayer de me sortir de l'ornière.

rassure-toi, j'en ai bavé un peu pour trouver tout ça !

bon we
jip

A+

l'interface (virtuelle, il n'y a pas de carte physique) côté hôte est
"construite" par le module "tun", device /dev/tun 10,200 avec un lien
symbolique /dev/net/tun --> /dev/tun.
ok

Ça ne semble pas clair du tout ;-) mais je me laisse (bêtement) guider.

l'activation de cette interface est faite par vde_switch :
sudo vde_switch -tap tap0 -daemon
à ce moment, ifconfig donne :
ben non ! je n'ai pas de tap1 à ce stade

ok

la communication se fait par la socket /tmp/vde.ctl, qu'on doit mettre
en 777 pour être utilisable par les users.
ok, ok; j'avais bien compris ça au travers du script qemu_prep

bonjour,

Ça rentre doucement ;-)
Après avoir pris connaissance de tes réponses,
ce qui me gêne c'est qu'après le script qemu_prep, un
ifconfig me donne:

eth0 Lien encap:Ethernet HWaddr 00:0C:76:5E:63:13
inet adr:10.0.0.2 Bcast:10.0.0.255 Masque:255.255.255.0
(...)
lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
(...)
tap1 Lien encap:Ethernet HWaddr 8A:EB:40:CB:97:0D
inet adr:10.0.0.138 Bcast:10.255.255.255 Masque:255.0.0.0
(...)



J'ai donc bien (chez moi):

WAN par modem/routeur [10.0.0.138] <--> Hôte eth0 [10.0.0.2]
et
Hôte vers Qemu tap1 mais d'office avec 10.0.0.138 (?)

Je ne comprends pas à quel moment (et comment) je dois configurer
le segment:
<--> Hôte LAN eth1 192.168.0.1
ni comment modifier:
tap1 [10.0.0.138] en tap1 [192.168.0.10]

Au lancement de qemu, j'ai toujours le message
SIOCSIFNETMASK: Ne peut attribuer l'adresse demandée

encore merci,
bon we

jip