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/
