Bonjour, Merci pour cette réponse.
Le 4 juin 2013 01:29, Emmanuel Thierry <m...@sekil.fr> a écrit : > Peut être que FRsAG serait plus approprié pour cette question ! Certainement mais je ne connais pas assez bien cette liste. Peut-être y ferais-je tomber un mail dans la journée. > Et… la question ? :D > Bon, plus sérieusement le macvtap est du genre capricieux. Je me suis > plusieurs fois cassé les dents dessus si bien que je suis systématiquement > revenu à un bridge regroupant l'interface physique et les interfaces des VMs. > On perd en performances mais on a exactement les mêmes fonctionnalités, c'est > quasiment invisible du point de vue de la VM. Justement, c'est une question de performance et de propreté, en plus d'être un objet dont je ne comprends pas le fonctionnement et que je souhaite creuser. Le moins qu'on puisse dire c'est que c'est capricieux en effet. De quoi cela vient-il ? Des interfaces des VM (pilotes, ...), du matériel du DC, de l'host ? un $>ip link show macvtap0 me donne bien les infos attendues 3: macvtap0@eth0... > Par ailleurs le plus sûr sur les interfaces macvtap est de rester en mode > bridge ou private comme indiqué dans la doc. Je suis en mode bridge avec l'eth0 de mon host, je n'ai rien testé d'autre, je pourrai donner ma configuration xml libvirt dans la soirée. > Tu parles de routage entre les deux switchs (auquel cas jouer avec le > forwarding) ou bien de relier les deux switchs sur un même L2 ? De routage. J'ai plusieurs réseaux /24 et je souhaiterais régir les échanges entre ces réseaux en utilisant iptables sur l'host. Sur ESXi, je n'avais qu'à mettre une VM disposant d'une patte sur tous les réseaux pour établir le lien entre eux (un routeur quoi). Ici c'est différent, tout peut se passer sur l'host normalement. > Dans le second cas tu ne peux pas relier directement les bridges entre eux. > Concrètement tu ne peux pas attacher un switch sur un autre. Par contre ce > qui doit marcher c'est de créer une paire de veth et d'ajouter chaque > extrémité à un bridge: > # ip l add type veth > # brctl addif virbr1 veth0 > # brctl addif virbr2 veth1 > # ip l set veth0 up > # ip l set veth1 up Ça c'est intéressant oui. Je regarderai ce que ca donne chez moi. A noter que sur cette page : http://libvirt.org/firewall.html il y a un petit soucis Partie type=routed, les 2 premières règles iptables laissent entendre qu'on autorise * vers vibr0 et vibr0 vers * pour peu qu'on ai les bonnes adresses source/dest. Dans la pratique ces règles sont systématiquement écrites de vibrX vers vibrY ou vibrY vers vibrX. Si je met "*" comme forward device (une feinte pour que libvirt écrive les règles iptables comme dans l'exemple de la doc), cela ne fonctionne pas. Si par contre je met vibrY en forward device de vibrX alors les deux peuvent communiquer. C'est pas satisfaisant pour autant : j'ai 3 /24 :) > Il faut voir ce que libvirt t'a généré comme config réseau. Peut être faire > des tests sans faire intervenir libvirt (simplement jouer à créer des > interfaces macvtap) peut aider au déboggage. En effet, d'autant que j'ai une surcouche à libvirt pour la gestion : archipel. Il laisse libre accès à la config xml, on peut vérifier ce qu'il fait mais j'avoue me perdre des fois dans certaines options. > Depuis quand un cahier des charges s'immisce dans les détails technique > plutôt que de rester dans le pur fonctionnel ? ;) Le CdC recommande un truc propre, pour y répondre on utilise macvtap et non un bridge. En raccourcissant ça donne ce que j'ai dit hier soir :) Cordialement, François Lacombe @InfosReseaux --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
