qemu en reseau

Le
Herve Autret
Bonjour,

Je cherche à virtualiser des serveurs pour des tests en réseau. Je
voudrais un réseau séparé du LAN, où toutes les machines soient visibles
les unes des autres. Je n'ai qu'une machine physique à ma disposition.
En principe qemu a(vait) les possibilités de le faire :

Dans http://wiki.qemu.org/download/qemu-doc.html#pcsys_005fnetwork,
je lis : <cite>
3.7.2.1 Linux host
As an example, you can download the 'linux-test-xxx.tar.gz' archive and
copy the script 'qemu-ifup' in '/etc' and configure properly sudo so
that the command ifconfig contained in 'qemu-ifup' can be executed as
root. You must verify that your host kernel supports the TAP network
interfaces: the device '/dev/net/tun' must be present.</cite>

Problème : il n'y a plus de répertoire /dev/net/ depuis quelque temps.
Quelqu'un sait comment faire fonctionner différents avatars qemu en
réseau, avec des systèmes actuels ?
--
Herve
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Emmanuel Florac
Le #21470261
Le Tue, 30 Mar 2010 22:25:53 +0000, Herve Autret a écrit:


Problème : il n'y a plus de répertoire /dev/net/ depuis quelque temps.



Bien sûr que si, mais il est créé quand tu charges le module "tun".


--
"Dope will get you through times of no money better
than money will get you through times of no dope."
Freewheelin' Franklin.
Herve Autret
Le #21474621
Bonjour,

Emmanuel Florac :

Problème : il n'y a plus de répertoire /dev/net/ depuis quelque temps.


Bien sûr que si, mais il est créé quand tu charges le module "tun".



Exact ! J'avais pourtant choisi l'option IP Tunelling ici :
$ cd /usr/src/linux
$ make menuconfig
-> Networking support
-> Networking options
-> [*] IP tunelling

Ce n'est donc pas la même chose, je suppose.
--
Hervé
Emmanuel Florac
Le #21475141
Le Wed, 31 Mar 2010 19:24:15 +0000, Herve Autret a écrit:


Ce n'est donc pas la même chose, je suppose.



Tu as compilé le module, mais encore faut-il le charger au démarrage.

--
The bearing of a child takes 9 months, no matter how many women are
assigned.
Fred Brooks
Nicolas George
Le #21475131
Emmanuel Florac wrote in message
Tu as compilé le module, mais encore faut-il le charger au démarrage.



Tu as mal lu, il y a « * », pas « M ». Mais ce n'est pas l'option qui
concerne tun/tap, donc bon.
Herve Autret
Le #21480581
Bonsoir

Nicolas George wrote:

Tu as mal lu, il y a « * », pas « M ». Mais ce n'est pas l'option qui
concerne tun/tap, donc bon.



Je vois bien CONFIG_TUN=m dans /usr/src/linux/.config mais je ne vois
pas où le configurer en "dur" dans le menu. Sauriez-vous me dire comment
ce "tun" s'appelle, en langue vernaculaire ?
--
Hervé
Nicolas George
Le #21480721
Herve Autret wrote in message
Je vois bien CONFIG_TUN=m dans /usr/src/linux/.config mais je ne vois
pas où le configurer en "dur" dans le menu. Sauriez-vous me dire comment
ce "tun" s'appelle, en langue vernaculaire ?



config TUN
tristate "Universal TUN/TAP device driver support"
select CRC32
---help---
TUN/TAP provides packet reception and transmission for user space
programs. It can be viewed as a simple Point-to-Point or Ethernet
device, which instead of receiving packets from a physical media,
receives them from user space program and instead of sending packets
via physical media writes them to the user space program.

When a program opens /dev/net/tun, driver creates and registers
corresponding net device tunX or tapX. After a program closed above
devices, driver will automatically delete tunXX or tapXX device and
all routes corresponding to it.

Please read information.

To compile this driver as a module, choose M here: the module
will be called tun.

If you don't know what to use this for, you don't need it.

Et tu peux utiliser la fonction de recherche de make menuconfig.
Emmanuel Florac
Le #21481401
Le Thu, 01 Apr 2010 22:26:03 +0000, Nicolas George a écrit:


Et tu peux utiliser la fonction de recherche de make menuconfig.




Quelle fonction de recherche? Jamais vu, mais ça m'intéresse :)


--
It always takes longer than you expect, even when you take into account
Hofstadter's Law.
Hofstadter's Law
Emmanuel Florac
Le #21485522
Le Fri, 02 Apr 2010 10:59:21 +0200, Pascal Hambourg a écrit:


Touche / comme dans less ou man.



Comme dans vi surtout :) (marche aussi dans firefox). Merci!


--
L'esprit qu'on veut avoir gâte celui qu'on a.
Jean-Baptiste Louis Grisset.
Emmanuel Florac
Le #21486802
Le Fri, 02 Apr 2010 23:54:57 +0200, Pascal Hambourg a écrit:


De rien. C'est quand même écrit dans les instructions affichées en haut
par make menuconfig.



<mauvaise foi>Nan pas chez moi</mauvaise foi>

--
Never ascribe to malice that which is adequately explained by
incompetence.
Hanlon's Razor.
Herve Autret
Le #21487612
Pascal Hambourg wrote:

Touche / comme dans less ou man.



Merci pour le tuyau. C'est vrai que c'était écrit et que je ne l'avais
jamais lu...

Bon par contre c'est pas toujours
facile ensuite de trouver dans quel sous-menu est l'option.



Je trouve ça pas mal au contraire :

Symbol: TUN
Prompt: Universal TUN/TAP device driversupport
x Defined at drivers/net/Kconfig:112
x Depends on: NETDEVICES [=y]
x Location:
x -> Device Drivers
x -> Network device support (NETDEVICES [=y])
x Selects: CRC32 [=y]


Quoi qu'il en soit, je fais maintenant fonctionner des instances de qemu
en réseau, accessibles par l'adresse l'extérieure de la machine. Je me
suis basé sur un script qemu-ifup ici :
http://en.wikibooks.org/wiki/QEMU/Networking

Comme je voudrais mettre plusieurs instances qemu en réseau et visibles
entre elles, j'ai adapté le script en le coupant en deux :
- Une première partie (qemu-brup, sans argument), qui est lancée une
seule fois, crée le bridge, configure son IP et y raccorde eth0.
-La seconde partie (qemu-ifup, agument=nom_du_device) est lancée avant
chaque occurrence de qemu, pour raccorder son device tap au bridge.

Pour finir, je lance :
# TAP=tapN && ./qemu-ifup $TAP &&
qemu image -net nic -net tap,ifname=${TAP},script=no

Les systèmes virtuels (deux pour l'instant) ont une adresse appartenant
au réseau local. Ils communiquent avec l'extérieur (yum update
fonctionne); ils sont accessibles en ssh depuis l'hôte mais refusent de
communiquer entre eux (cas n°1). Or c'est ce qui m'intéresserait.

Comme l'hôte a 2 cartes réseaux : une "principale" (la route par défaut)
et une "secondaire" qui sert un sous-réseau en NAT, j'ai tenté ce qui
suit :
- créer un 2nd bridge et le connecter à la seconde carte comme
précédemment.
- raccorder chaque tap à un bridge différent, en comptant qur la table
de routage de l'hôte pour faire passer les paquets de l'un à l'autre.

Ce qui se passe alors : le système du sous-réseau peut se connecter en
ssh sur le système raccordé à la carte principale. Les paquets passent
donc dans les 2 sens. En revanche, impossible de connecter la machine
située sur le sous-réseau depuis l'autre. (cas n°2)

Ce dernier cas me paraît plutôt normal ; pour pouvoir initier les
connexions dans les 2 sens, je devrais supprimer le NAT, j'imagine.

Mais la raison du cas n°1 : ça peut être également dû au NAT ? (j'avais
un peu le nez dans le guidon, je n'ai pas pensé à tester).

à +
--
Hervé
Publicité
Poster une réponse
Anonyme