Bonsoir la liste,

C'est mon premier message ici bien que je vous lise depuis un bon moment.

Je rencontre rarement d'aussi gros soucis pour faire appel à
l'expertise de ses membres.
J'espère également que ma problématique saura en intéresser certains.

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.

On s'est lancé dans l'aventure avec quelques autres, mais c'est déjà
pas ça au niveau de la configuration réseau.
Mon host tourne sous Debian 7, les VM également.

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.
- 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.

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.


Si certains ont des configs tirant parti de ces deux fonctionnalités,
je serai ravi d'échanger avec eux et d'exposer l'architecture cible
plus en détails.
Concernant macvtap, ne pas utiliser de bridge traditionnel est un
élément du cahier des charges.


En vous remerciant par avance pour vos retours, cordialement,


François Lacombe
@InfosReseaux


---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à