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
Emmanuel Florac wrote in message <4bb3b62a$0$17132$:
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
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é
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é
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
Herve Autret wrote in message <4bb5123e$0$12793$:
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 <file:Documentation/networking/tuntap.txt> for more 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.
Herve Autret wrote in message <4bb5123e$0$12793$426a74cc@news.free.fr>:
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 <file:Documentation/networking/tuntap.txt> for more
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.
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 <file:Documentation/networking/tuntap.txt> for more 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 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
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
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
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é
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).
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).
