Bonsoir, Le 4 juin 2013 à 00:31, François Lacombe <fl.infosrese...@gmail.com> a écrit :
> Disposant actuellement d'un serveur dédié muni de l'hyperviseur VMWare > ESXi 4.1, je souhaite depuis le début de l'année monter en compétence > sur la technologie KVM/Qemu sous Debian. > Donc migrer de ESXi vers KVM en tentant de reproduire à l'identique > fonctionnellement mon infra me semblait être un bon défi pour cela. Peut être que FRsAG serait plus approprié pour cette question ! > > Deux problèmes distincts se présentent à nous : > - l'utilisation de la fonctionnalité macvtap de l'hyperviseur pour > permettre à nos VM d'accéder directement à Internet (via IP failover, > classique). Ça se configure graphiquement sous vSphere quand on > utilise ESXi. Sous Debian/libvirt c'est un peu plus confus. 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. Par ailleurs le plus sûr sur les interfaces macvtap est de rester en mode bridge ou private comme indiqué dans la doc. > - La communication inter-vswitches sur l'host (les interfaces vibrX). > La documentation disponible à cette adresse > (http://wiki.libvirt.org/page/VirtualNetworking) évoque toujours des > cas mono-vswitches alors que j'en ai au moins 2 à faire communiquer en > local. 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 ? 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 > > Ces deux points ne semblent fonctionner que sur le papier de mon point > de vue et je suis à court d'astuce pour triturer la doc d'une manière > ou d'une autre. > Dans le cas de macvtap, rien ne sort des VM et tout ICMP se solde par > un "Destination host unreachable" envoyé par les interfaces mêmes des > VM, invariablement. 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. > Concernant macvtap, ne pas utiliser de bridge traditionnel est un > élément du cahier des charges. Depuis quand un cahier des charges s'immisce dans les détails technique plutôt que de rester dans le pur fonctionnel ? ;) Cordialement Emmanuel Thierry --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
