Re: [FRnOG] [TECH] Hyperviseur linux KVM et configuration réseau
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/
Re: [FRnOG] [TECH] Hyperviseur linux KVM et configuration réseau
Le 4 juin 2013 à 11:05, François Lacombe a écrit : Bonjour, Merci pour cette réponse. Le 4 juin 2013 01:29, Emmanuel Thierry m...@sekil.fr a écrit : 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 ? Du noyau... A vrai dire les VMs n'ont pas grand chose à voir là dedans. Le gros du boulot est fait dans le noyau de l'hôte. Pour preuve, tu peux tout à fait créer une interface macvtap sans la mettre dans une VM. 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. Je confirme, tu fais ça sur l'hôte. Si tu es joueur tu peux aussi faire ça sur l'hôte dans un netnamespace distinct (si tu es joueur). A vrai dire cela marche très bien si tu le fais hors de libvirt. Ensuite trouver les paramètres du xml qui te généreront la conf que tu veux c'est une autre affaire... 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 :) Mettre son eth0 sur un bridge n'est pas propre ? Tiens, j'apprends des choses ! ;) Cordialement Emmanuel Thierry --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Hyperviseur linux KVM et configuration réseau
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. Mon but n'est pas de te décourager, mais d'après mon expérience avec des ESXi (4.x/5) et KVM (Debian5/6) bien chargés en IO disque et réseau tu vas sérieusement perdre en performance et en fiabilité en passant sur KVM. Maintenant je ne connais pas tes motivations, ton infra et le type de trafic/ressources, peut être que cela a du sens dans ton cas. Cela dit ça m'intéresserai d'avoir un retour d'expérience sur Debian 7, le kernel 3.2 arrange peut être bien les choses ? Cordialement --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Hyperviseur linux KVM et configuration réseau
Le 04/06/2013 11:57, Cédric Tabary 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. Mon but n'est pas de te décourager, mais d'après mon expérience avec des ESXi (4.x/5) et KVM (Debian5/6) bien chargés en IO disque et réseau tu vas sérieusement perdre en performance et en fiabilité en passant sur KVM. Maintenant je ne connais pas tes motivations, ton infra et le type de trafic/ressources, peut être que cela a du sens dans ton cas. Cela dit ça m'intéresserai d'avoir un retour d'expérience sur Debian 7, le kernel 3.2 arrange peut être bien les choses ? De nos tests entre une machine hôte (live usb) et une machine virtuelle par dessus de la virtu, ESX 4/5 on perd 10% de performance disque, KVM 12%, Xen 3% testé sur Debian 7 kernel branche 3.4 pour les tests Kvm et Xen. Ce sont des moyennes des pertes en débit, IO ou temps de traitement qu'on déroule dans les tests. Ces tests on les fait depuis 2009 pour voir les évolutions du kernel sur Xen et KVM, Esx on le test quand y a une nouvelle version vu qu'on sait qu'on utilisera pas cette techno. Je précise qu'on a une infra de virtualisation qui utilise les disques locaux en réplication comme la techno Vmware VSA, ESX est optimisé pour du SAN pas pour du local, KVM on a jamais trouvé pourquoi ça coinçait. Par contre les tests on les fait sans réplication pour considérer la perte de la couche de virtualisation sur une machine. signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Hyperviseur linux KVM et configuration réseau
De nos tests entre une machine hôte (live usb) et une machine virtuelle par dessus de la virtu, ESX 4/5 on perd 10% de performance disque, KVM 12%, Xen 3% testé sur Debian 7 kernel branche 3.4 pour les tests Kvm et Xen. Ce sont des moyennes des pertes en débit, IO ou temps de traitement qu'on déroule dans les tests. Je suis étonné des 3% de perte avec Xen, je suppose que tes tests sont faits en paravirtualisation (kernel guest xen) ? Cédric --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Hyperviseur linux KVM et configuration réseau
Certainement. Aucun intérêt de virtualiser des linux avec Xen si c'est pour utiliser qemu... [troll] Xen c'est tellement mieux ;) [/troll] Le 04/06/2013 14:13, Cédric Tabary a écrit : De nos tests entre une machine hôte (live usb) et une machine virtuelle par dessus de la virtu, ESX 4/5 on perd 10% de performance disque, KVM 12%, Xen 3% testé sur Debian 7 kernel branche 3.4 pour les tests Kvm et Xen. Ce sont des moyennes des pertes en débit, IO ou temps de traitement qu'on déroule dans les tests. Je suis étonné des 3% de perte avec Xen, je suppose que tes tests sont faits en paravirtualisation (kernel guest xen) ? Cédric --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Hyperviseur linux KVM et configuration réseau
Le 4 juin 2013 14:18, Pierre `Sn4kY` DOLIDON sn...@sn4ky.net a écrit : Certainement. Aucun intérêt de virtualiser des linux avec Xen si c'est pour utiliser qemu... Tout dépend du pourquoi de la virtualisation. Pour migrer une vieille slackware avec un kernel 2.4, une pelletée de debian 5, et d'éventuels windows (le service comptable a toujours un ou 2 windows sous le coude), esxi est presque parfait, et kvm une catastrophe (au moins 80% de perte chez moi), Xen est probablement entre les deux. [troll] Xen c'est tellement mieux ;) [/troll] On est que mardi :) mais dans le cas idéal où tu as des vm récentes avec le kernel qui va bien pour la paravirtualisation on est d'accord. Cédric --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Hyperviseur linux KVM et configuration réseau
Le 04/06/2013 14:13, Cédric Tabary a écrit : Je suis étonné des 3% de perte avec Xen, je suppose que tes tests sont faits en paravirtualisation (kernel guest xen) ? Non c'est bien en HVM, la para virt c'est pas assez souple pour du hosting VPS où tu n'as pas forcément la main sur toutes les machines. Je précise aussi que c'est du Xen et pas du XenServer où là les perfs disques sont entre KVM et ESX, ils doivent ajouter des sur couches pénalisantes. Pour donner un panel de nos tests, sur les perfs disques et réseaux, Xen est très bon, ESX sur les SAN y a pas photo, par contre niveau CPU il y a pas mal de pertes liées à la consommation de l'hyperviseur quand beaucoup de vm sont présentes. signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Hyperviseur linux KVM et configuration réseau
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/
