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
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).
Mais encore ?
Le réseau local est privé (172.16..), sans DNS ni NIS. J'avais levé tous les pare-feu et désactivé SELinux sur les VM, mais j'intuite que là n'est pas la question que tu poses. J'ai aussi essayé d'ajouter des routes à destination des invités qui arrivent directement sur leur tapI respectif... sans succès. Ce que je veux faire ? tester la performance et la faisabilité d'un service de type openais ou heartbeat, alors que je n'ai qu'une machine physique à ma disposition.
Rien qu'en posant la question en ces termes, une réponse se fait jour : installer un OS virtualisé par Xen et installer les serveurs virtualisés en domU et je n'ai plus ce problème-là. Certes. Mais j'aimerais aussi comprendre la cause de ce problème de communication en réseau des invités qemu entre eux.
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)
Mais encore ?
J'ai vu que le device tap1 (par ex) ne voit pas arriver les demandes de connexion. Le demandeur se voit répondre "no route to host" et nmap dit que le destinataire est "down" ; nmap -PN dit que tout est fermé... -- Hervé
Bonsoir,
Pascal Hambourg:
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).
Mais encore ?
Le réseau local est privé (172.16..), sans DNS ni NIS. J'avais levé tous
les pare-feu et désactivé SELinux sur les VM, mais j'intuite que là n'est
pas la question que tu poses. J'ai aussi essayé d'ajouter des routes à
destination des invités qui arrivent directement sur leur tapI
respectif... sans succès.
Ce que je veux faire ? tester la performance et la faisabilité d'un
service de type openais ou heartbeat, alors que je n'ai qu'une machine
physique à ma disposition.
Rien qu'en posant la question en ces termes, une réponse se fait jour :
installer un OS virtualisé par Xen et installer les serveurs virtualisés
en domU et je n'ai plus ce problème-là. Certes. Mais j'aimerais aussi
comprendre la cause de ce problème de communication en réseau des
invités qemu entre eux.
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)
Mais encore ?
J'ai vu que le device tap1 (par ex) ne voit pas arriver les demandes de
connexion. Le demandeur se voit répondre "no route to host" et nmap dit
que le destinataire est "down" ; nmap -PN dit que tout est fermé...
--
Hervé
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).
Mais encore ?
Le réseau local est privé (172.16..), sans DNS ni NIS. J'avais levé tous les pare-feu et désactivé SELinux sur les VM, mais j'intuite que là n'est pas la question que tu poses. J'ai aussi essayé d'ajouter des routes à destination des invités qui arrivent directement sur leur tapI respectif... sans succès. Ce que je veux faire ? tester la performance et la faisabilité d'un service de type openais ou heartbeat, alors que je n'ai qu'une machine physique à ma disposition.
Rien qu'en posant la question en ces termes, une réponse se fait jour : installer un OS virtualisé par Xen et installer les serveurs virtualisés en domU et je n'ai plus ce problème-là. Certes. Mais j'aimerais aussi comprendre la cause de ce problème de communication en réseau des invités qemu entre eux.
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)
Mais encore ?
J'ai vu que le device tap1 (par ex) ne voit pas arriver les demandes de connexion. Le demandeur se voit répondre "no route to host" et nmap dit que le destinataire est "down" ; nmap -PN dit que tout est fermé... -- Hervé
Doug713705
Dans fr.comp.os.linux.configuration Pascal Hambourg nous expliquait:
Quelle fonction de recherche? Jamais vu, mais ça m'intéresse :)
Touche / comme dans less ou man. Utile pour trouver l'état d'une option notamment cachée, les dépendances... Bon par contre c'est pas toujours facile ensuite de trouver dans quel sous-menu est l'option.
Trop bon !!!
-- Tu peux venir la où je suis, l'ennui c'est que je ne suis plus. (H.F.T. - La môme kaléïdoscope)
Dans fr.comp.os.linux.configuration Pascal Hambourg nous expliquait:
Quelle fonction de recherche? Jamais vu, mais ça m'intéresse :)
Touche / comme dans less ou man. Utile pour trouver l'état d'une option
notamment cachée, les dépendances... Bon par contre c'est pas toujours
facile ensuite de trouver dans quel sous-menu est l'option.
Trop bon !!!
--
Tu peux venir la où je suis, l'ennui c'est que je ne suis plus. (H.F.T.
- La môme kaléïdoscope)
Dans fr.comp.os.linux.configuration Pascal Hambourg nous expliquait:
Quelle fonction de recherche? Jamais vu, mais ça m'intéresse :)
Touche / comme dans less ou man. Utile pour trouver l'état d'une option notamment cachée, les dépendances... Bon par contre c'est pas toujours facile ensuite de trouver dans quel sous-menu est l'option.
Trop bon !!!
-- Tu peux venir la où je suis, l'ennui c'est que je ne suis plus. (H.F.T. - La môme kaléïdoscope)
