August 2019 - FRsAG

Re: [FRsAG] Sauvegarde fiable pour Proxmox KVM
by Sebastien Caps 26 Aug '19

26 Aug '19

-------- Message original -------- Objet: Re: [FRsAG] Sauvegarde fiable pour Proxmox KVM Date: 26-08-2019 09:40 De: Sebastien Caps <s.caps(a)dsx-networks.com> À: Nicolas Girardi <n.girardi(a)gmail.com> Bonjour, La restauration au niveau fichier avec Veeam est bien disponible pour Linux. Il faut ajouter les codes d'accès/clé à la machine et il fait le job. Sébastien Le 25-08-2019 11:23, Nicolas Girardi a écrit : > Bonjour, > > La restauration au niveau fichier n’est pas disponible sur Linux > sauf erreur de ma part. > > Nicolas Girardi. > > Le 25 août 2019 à 00:44, Olivier Vailleau > <olivier.vailleau(a)gmail.com> a écrit : > >> En fait, Veeam sait backuper directement auprès du stockage, pour >> peu que ce soit un système qu'il connaisse (par exemple, les >> grandes marques de baies de disque comme 3par, Netapp, etc.) >> Il déclenche un snap sur l'hyperviseur. Celui-ci déclenche un vss >> sur la vm (windows). Dès que le snap hyperviseur est réalisé, il >> déclenche un snap sur le stockage puis relâche immédiatement le >> snap hyperviseur (moins de delta à rattraper pour l'hyperviseur). >> Il aura ensuite tout le temps d'aspirer les données depuis le >> stockage, sans surcharger l'hyperviseur. C'est quand m^me assez >> efficace, mais il faut être dans la bonne combo >> Edition_veeam_entreprise_plus et matériel connu. >> >> Veeam sait effectivement parcourir un backup et te récupérer un >> fichier, ou même un objet SQL, AD, Exchange. Ca, c'est fort. En >> revanche, il ne sait pas restaurer tous les *.txt de ta vm...(ou >> j'ai pas trouvé) >> >> Je te l'accorde, il peut être lent, mais je crois que c'est surtout >> lié au transfert scp (fastSCP) avec vmware. Sinon, il sait te faire >> un instant-recovery : il monte ton backup directement en NFS et te >> relance la vm très vite (sur un lien un peu mou, mais globalement, >> ca marche). >> Il permet ensuite d'autre trucs assez sympa comme le Sure-backup : >> il peut remonter dans un env. isolé un jeu de vm, les démarrer et >> attendre qu'un http réponde, ou qu'un AD ou sql soit up. Il fait ca >> automatiquement et te prévient si un truc a merdé. C'est bien pour >> être sûr que tes backups tournent. Je ne connais pas de concurrent >> à cette fonction. >> >> Veeam sait aussi envoyer les backups sur bande et gère de façon >> rudimentaire les pools de bande et la rétention GFS. c'est assez >> minimaliste (par exemple, pas de catalogue des guest files quand >> c'est sur bande) mais ca permet au moins de sortir sur LTO tes >> données et de faire plaisir à ton DSI qui ne jure que par la >> bande. >> >> Il lui manque la possibilité d'aller causer avec un kvm/qemu/PVE >> pour chercher les snaps et les backuper.. Je pense que si Veeam fait >> cela un jour, le paysage de la virtu changera dans pas mal >> d'entreprises ! >> Bonne journée aussi ! >> >> Le sam. 24 août 2019 à 18:10, Florent CARRÉ <colundrum(a)gmail.com> >> a écrit : >> >> Hello la liste, >> >> Bon, j'ai beau ne pas utiliser Proxmox (pour l'absence de Xen), il a >> l'avantage d'avoir un Ceph de disponible ... >> Pourquoi ne pas faire du Ceph on Ceph via diff ? >> https://archive.fosdem.org/2018/schedule/event/backup_ceph_at_scale/ >> [2] >> >> Sinon, j'ai vu l'existence de backy2 qui a l'air intéressant et >> supporte également Ceph : https://github.com/wamdam/backy2 [3] >> >> /! Risque de troll >> >> Le jour qu'on aura un Veeam supportant Ceph, je pense qu'il >> méritera pleinement son prix ... >> >> Pourquoi au niveau de Ceph (ou autre stockage) et non de >> l'hyperviseur ? >> >> Je trouve stupide qu'on s'enferme sur une surcouche comme Proxmox, >> XCP ... Il faut que le backup puisse se faire directement sur le >> système de stockage >> >> (rappel : je n'utilise pas Proxmox) >> Si demain, je veux par exemple bouger de Proxmox pour un setup pur >> et dur en Debian ou oVirt ou Red Hat Virtualization, je peux garder >> toutes les vms stockées sur le Ceph, le plus long sera de remettre >> la conf des vms avec les disques ... mais on ne les touche pas >> >> Ensuite l'autre point, c'est le fonctionnement des backups de Veeam >> ? >> Je ne me suis jamais penché entièrement sur le sujet mais je pense >> que le snapshot au niveau du stockage sera toujours bien plus >> efficient. Après, oui on aura toujours des FD open/busy voir même >> qui ont disparus dans les vm/LXC mais ça fait parti du block qui >> est backupé >> >> La seule chose qui manquera c'est la puissance de Veeam pour >> explorer les fichiers dans les différents backups et encore parfois >> il peut être très lent (surtout quand on a un poste de travail qui >> est un laptop a bout de souffle et sous Windows) >> >> Je ne vois l'intérêt de Veeam seulement sur sa facilité >> d'extraction de fichiers bien précis des backups, ríen de plus... >> Je ne trouve pas que ce soit une solution miracle >> >> Pourquoi devrait-on être dépendant de la surcouche de >> virtualisation ? >> >> Bonne journée >> >> On Sat, Aug 24, 2019, 10:09 Olivier Raulin >> <olivier(a)olivier-raulin.fr> wrote: >> >> Bonjour, >> >> Proxmox dispose d'un mode de backup des VM/CT intégré, qui >> produit une image brute de la VM et compressée de la machine. Il >> utilise les outils Qemu pour sauvegarder les VM >> >> Cela marche bien, ça peut se pousser automatiquement dans un >> dossier, un repo NFS, etc. et ça gère un historique paramétrable >> (combien de backups on conserve dans ce dossier) >> En plus ça se configure très simplement dans l'interface, avec >> une planification que l'on choisit pour chaque machine. >> >> Je dirais que c'est plutôt simple à prendre en main, et efficace >> en cas de gros incident (un HV HS, par exemple), mais cela n'a pas >> la souplesse ni la légèreté d'une backup fine au niveau >> applicatif (j'estime que dans pas mal de scénarios il faut mixer >> ces 2 méthodes) >> >> Par ailleurs, si on veut aller plus loin il est tout à fait >> possible, en fonction du stockage que l'on choisit (LVM, ZFS, etc.) >> d'effectuer des snapshots réguliers et de gérer soi-même ces >> snapshots. >> Cela ne se passera par contre pas via l'interface web, mais >> derrière Proxmox c'est une Debian, il n'y a pas de limitation >> particulière pour définir ses propres process. >> >> Je ne suis pas familier de solutions comme VEEAM, je ne saurais >> donc pas comparer les deux. >> >> Proxmox propose des offres de support pour entreprise, mais je ne >> connais pas le périmètre concerné. >> >> On 22/08/2019 16:31, SIMANCAS Hugo wrote: >> >> Bonjour, >> >> Avez-vous du Prodmox/KVM en prod ? Qu’utilisez-vous en sauvegarde >> fiable (avec support entreprise comme VEEAM) >> >> Merci d’avance >> >> Cordialement, Regards, >> >> HUGO SIMANCAS >> >> Directeur Technique Associé >> >> https://www.data-expertise.com/ [4] >> >> Support technique : 09 78 23 20 29 >> Standard : 05 34 26 02 46 | LIGNE DIRECTE : 05 34 26 50 57 | MOBILE >> : 06 95 44 29 64 >> >> _______________________________________________ >> Liste de diffusion du FRsAG >> http://www.frsag.org/ [1] >> _______________________________________________ >> Liste de diffusion du FRsAG >> http://www.frsag.org/ [1] > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ [1] > >> _______________________________________________ >> Liste de diffusion du FRsAG >> http://www.frsag.org/ [1] > > > Links: > ------ > [1] http://www.frsag.org/ > [2] > https://archive.fosdem.org/2018/schedule/event/backup_ceph_at_scale/ > [3] https://github.com/wamdam/backy2 > [4] https://www.data-expertise.com/ > > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/

1 0

RAID 1 - md1: 70Mo/s - md2: 220Mo/s - ???
by Frederic Dumas 22 Aug '19

22 Aug '19

Bonjour à tous, Peut-être d'autres ont rencontré ce phénomène sur des grappes en RAID1 logiciel (mdadm) sous Linux et pourront me conseiller. Deux grappes constituées d'un SSD (/dev/sdb) sur un contrôleur et de deux HDD (/dev/sda et /dev/sdd) sur un autre contrôleur: > /dev/md1: > Version : 1.2 > Creation Time : Sat Aug 17 20:43:32 2019 > Raid Level : raid1 > Array Size : 585922560 (558.78 GiB 599.98 GB) > Used Dev Size : 585922560 (558.78 GiB 599.98 GB) > Raid Devices : 2 > Total Devices : 2 > Persistence : Superblock is persistent > > Intent Bitmap : Internal > > Update Time : Mon Aug 19 11:17:20 2019 > State : clean Active Devices : 2 > Working Devices : 2 > Failed Devices : 0 > Spare Devices : 0 > > Consistency Policy : bitmap > > Name : <sanitized>:1 (local to host <sanitized>) > UUID : <sanitized> > Events : 20538 > > Number Major Minor RaidDevice State > 0 8 2 0 active sync /dev/sda2 > 1 8 17 1 active sync /dev/sdb1 > /dev/md2: > Version : 1.2 > Creation Time : Sat Aug 17 20:43:50 2019 > Raid Level : raid1 > Array Size : 585922560 (558.78 GiB 599.98 GB) > Used Dev Size : 585922560 (558.78 GiB 599.98 GB) > Raid Devices : 2 > Total Devices : 2 > Persistence : Superblock is persistent > > Intent Bitmap : Internal > > Update Time : Mon Aug 19 11:17:20 2019 > State : clean Active Devices : 2 > Working Devices : 2 > Failed Devices : 0 > Spare Devices : 0 > > Consistency Policy : bitmap > > Name : <sanitized>:2 (local to host <sanitized>) > UUID : <sanitized> > Events : 12267 > > Number Major Minor RaidDevice State > 0 8 18 0 active sync /dev/sdb2 > 1 8 50 1 active sync /dev/sdd2 L'option --write-mostly n'est pas utilisée. Elle permet de prioriser les accès en lecture sur le SSD. Mais les grappes ont été construites sans cette option. hdparm est le seul outil que je connaisse pour faire un test de débit en lecture sur une grappe en particulier, quelque soit le système de fichiers au-dessus. Voilà l'étrange résultat que hdparm renvoie: > # hdparm -t /dev/md1 /dev/md2 > > /dev/md1: (HDD + SSD) > Timing buffered disk reads: 216 MB in 3.03 seconds = 71.38 MB/sec > > /dev/md2: (SSD + HDD) > Timing buffered disk reads: 672 MB in 3.00 seconds = 223.80 MB/sec /dev/md2 offre le taux de transfert plus ou moins attendu d'un SSD sur un lien SATA bridé à 300Mo/s. Par contre, le résultat de /dev/md1 semble démontrer que la lecture se fait exclusivement sur le HDD, ignorant totalement le SSD. C'est une situation à la fois curieuse et problématique. Comment expliquer ce phénomène ? Le seul début de piste auquel je peux penser, c'est que l'ordre d'assemblage des grappes n'a pas été le même pour md1 et md2: /dev/md1 est composée de HDD1 + SDD /dev/md2 est composée de SDD + HDD2 Quelqu'un a-t-il jamais entendu dire que l'ordre d'assemblage des disques dans la grappe pourrait-il avoir une conséquence sur la priorité de lecture depuis l'un ou l'autre périphérique ? D'autres outils de benchmark plus sophistiqués (bonnie++, iozone3...) écrivant dans le système de fichiers pour faire leurs tests de performance. Comme des volumes logiques LVM sont intercalés entre le système de fichiers et les grappes RAID, je n'ai pas de moyen de restreindre ces tests à l'une ou l'autre grappe sous-jacente. Évidemment, sans confirmation par un autre outil de bench, on ne peut pas exclure complètement que hdparm renvoie des résultats faussés, pour un raison obscure. Mais les valeurs affichées sont quand même signe d'un truc bizarre. J'espère trouver sur la liste quelques indices permettant de comprendre et corriger ce "dysfonctionnement". Merci. -- Frédéric Dumas f.dumas(a)ellis.siteparc.fr

4 5

[MISC] Don de switchs HP
by frsag＠sparfel.net 22 Aug '19

22 Aug '19

Bonjour, Je donne les switchs/châssis HP Procurve suivants : - 1 * 5406zl - 1 * 5304xl A venir chercher dans le 93 ou sur Paris éventuellement. Me contacter en MP si intéressé. Quelques informations techniques : HP-5406zl# sh ru Running configuration: ; J8697A Configuration Editor; Created on release #K.15.12.0012 ; Ver #05:08.41.ff.3f.ef:63 hostname "HP-5406zl" module 1 type j8705a module 2 type j8705a snmp-server community "public" unrestricted vlan 1 name "DEFAULT_VLAN" untagged A1-A24,B1-B24 ip address 192.168.1.100 255.255.255.0 exit HP-5406zl# sh modules Status and Counters - Module Information Chassis: 5406zl J8697A! Serial Number: SG039SU0VG Allow V1 Modules: Yes Management Module: J8726A Serial Number: ID037AS0D6 Core Dump: YES Core Mod Slot Module Description Serial Number Status Dump Ver ---- -------------------------------------- -------------- -------- ----- --- A HP J8705A Gig-T/SFP zl Module SG038AU045 Up NO 1 B HP J8705A Gig-T/SFP zl Module SG038AU050 Up NO 1 J8705A = 20 ports cuivre 1 Gbit/s POE + 4 ports GBIC dont 3 équipés de GBIC FO 1Gbit/s 6 GBIC J4858C ProCurve Switch 5304XL# sh ru Running configuration: ; J4850A Configuration Editor; Created on release #E.11.38 hostname "ProCurve Switch 5304XL" module 1 type J4907A module 3 type J4907A module 2 type J4878A snmp-server community "public" Unrestricted vlan 1 name "DEFAULT_VLAN" untagged A1-A16,B1-B4,C1-C16 ip address 192.168.1.100 255.255.255.0 exit ProCurve Switch 5304XL# sh modules Status and Counters - Module Information Slot Module Description Serial Number ----- ---------------------------------------- -------------- A ProCurve J4907A XL Gig-T/GBIC module SG434PM0P7 B ProCurve J4878A XL mini-GBIC module SG430AA00K C ProCurve J4907A XL Gig-T/GBIC module SG709XX054 J4907A = 16 ports cuivre 1 Gbit/s + 2 ports Dual Perso Cuivre/GBIC 1 Gbit/s avec 2 GBIC FO 1Gibt/s J4878A = 4 ports GBIC avec 4 GBIC FO 1Gibt/s 5 GBIC J4858A 2 GBIC J4848B 1 GBIC J4858C Cordialement, Frédéric.

1 1

Re: [FRsAG] [MISC] - Envoyer F2 via applet Java Web Start ?
by Joel DEREFINKO 21 Aug '19

21 Aug '19

Merci à tous pour vos retours, ca me rassure de voir qu’on galère tous sur les mêmes petits sujets à la con qui font perdre un max de temps ☺ Joël De : Florent CARRÉ <colundrum(a)gmail.com> Envoyé : mercredi 21 août 2019 12:24 À : Joel DEREFINKO <joel.derefinko(a)118218.fr> Objet : Re: [FRsAG] [MISC] - Envoyer F2 via applet Java Web Start ? Bonjour Joël, Peux tu essayer en utilisant IPMIView, pour moi c'est le seul outil qui parfois réussi l'impossible ... Sinon via l'ipmitool en cli https://www.supermicro.com/en/solutions/management-software/ipmi-utilities C'est bourrin mais il n'y a pas 50 façons possibles de contourner ce problème (j'avais utilisé IPMIView avec des iLO et ça fonctionnait bien Maintenant et par chance, je vois un peu plus le choix de la console en HTML5 et tant mieux (dernièrement sur une iLO) Bon courage et excellente journée Florent On Wed, Aug 21, 2019, 05:14 Joel DEREFINKO <joel.derefinko(a)118218.fr<mailto:joel.derefinko@118218.fr>> wrote: Oui j’ai testé tous les CTRL/ALT/etc. possibles Clairement ca me rend fou, je sais pas qui est le plus c.. : oracle/java pour mapper F2 sur « exit » ou VMWare pour utiliser F2 pour se logger… Ou alors c’est moi, pas impossible non plus :D De : David Ponzone <david.ponzone(a)gmail.com<mailto:david.ponzone@gmail.com>> Envoyé : mercredi 21 août 2019 11:57 À : Joel DEREFINKO <joel.derefinko(a)118218.fr<mailto:joel.derefinko@118218.fr>> Cc : frsag(a)frsag.org<mailto:frsag@frsag.org> Objet : Re: [FRsAG] [MISC] - Envoyer F2 via applet Java Web Start ? M’en parle pas, c’est la merde ces applets Java. T’as essayé ctrl-F2, alt-f2, etc..? David Ponzone Le 21 août 2019 à 11:53, Joel DEREFINKO <joel.derefinko(a)118218.fr<mailto:joel.derefinko@118218.fr>> a écrit : Bonjour à tous, Petite question un peu stupide : j’accède en IPMI sur une machine Nutanix (SuperMicro rebrandé). J’ai besoin de faire des modifs sur le VMWARE via la remote console Java. Problème : pour se logger en console sur l’ESX il faut presser « F2 », et F2 est le raccourci pour fermer la fenêtre JNLP. J’obtiens donc un joli prompt « Are you sure ?? EXIT ? YES/NO » au lieu de pouvoir me logger son mon ESX… J’ai testé tout un tas de raccourcis (ALT, CTRL, CTRL+ALT, etc…) sans succès. J’en suis à chercher si je peux modifier les raccourcis de l’applet… Avez-vous déjà été confronté à ce problème ? Auriez-vous un trick magique ? Merci d’avance ! Joël _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

1 0

[MISC] - Envoyer F2 via applet Java Web Start ?
by Joel DEREFINKO 21 Aug '19

21 Aug '19

Bonjour à tous, Petite question un peu stupide : j'accède en IPMI sur une machine Nutanix (SuperMicro rebrandé). J'ai besoin de faire des modifs sur le VMWARE via la remote console Java. Problème : pour se logger en console sur l'ESX il faut presser « F2 », et F2 est le raccourci pour fermer la fenêtre JNLP. J'obtiens donc un joli prompt « Are you sure ?? EXIT ? YES/NO » au lieu de pouvoir me logger son mon ESX... J'ai testé tout un tas de raccourcis (ALT, CTRL, CTRL+ALT, etc...) sans succès. J'en suis à chercher si je peux modifier les raccourcis de l'applet... Avez-vous déjà été confronté à ce problème ? Auriez-vous un trick magique ? Merci d'avance ! Joël

4 6

recherche d' alternance
by Anthony Chauvin 19 Aug '19

19 Aug '19

Bonjour je me permets de refaire un appel, pouvez vous m'aider svp? Je m’appelle Anthony chauvin, en deuxième année d’ingénierie informatique à g4 Marseille) Je suis à la recherche d’une alternance pour l’année prochaine ! Je suis motivé, sérieux et j’apprends très vite ! Langue : Anglais (lu et parlé) COMPETENCES SPECIFIQUES: - Langage C/C++ pour la conception de logiciels - Langage SQL pour la gestion de bases de données - Création et conception de site web (PHP, HTML, CSS, Javascript) - Langage JAVA pour la conception d’applications - Maitrise de Photoshop pour le traitement d’images - Modélisation UML : diagramme de classe, de cas d’utilisations, de séquences… COMPETENCES SUPPLEMENTAIRES: - Management de la qualité - Gestion et organisation de projet (cahier des charges, spécifications techniques , conception - Présentation de projets (revue de cahier des charges, d’avancement, CR final) Si dans votre entreprise, dans vos contacts vous avez des pistes.... je suis à disposition pour plus de renseignements !! Merci d avance !! -- Chauvin anthony

1 0

Re: [FRsAG] Problème d'isolation réseau et système sous Linux - OVS - Qemu
by Florent Nolot 14 Aug '19

14 Aug '19

Bonjour justement, je n'ai pas de routage en place, pas de proxy arp et les trames de broadcast atteigne VM3 depuis VM1 Sur mon host : toto@ubuntu:~$ ip route show default via 10.22.9.254 dev ens160 onlink 10.22.9.0/24 dev ens160 proto kernel scope link src 10.22.9.75 net.ipv4.ip_forward = 0 net.ipv4.conf.all.proxy_arp = 0 Sur les VM, je n'ai pas de route par défaut. Chaque VM est lancé ainsi qemu-system-x86_64 -machine accel=kvm:tcg -cpu host -m 256 -hda alpine-lab1.img -net nic,macaddr=52:54:00:12:12:02 -net tap,script=no,ifname=lab1vm1 -vnc :2 -name lab1vm1 -localtime --daemonize Ce que je n'explique pas, si je down eth0 eth1 de la VM2, les ping continue à marcher ! VM2 ne fait donc pas le routage. Visiblement, c'est le kernel du host qui relai les paquets. Mais pourquoi les tag vlan ne jouent pas leur rôle ? Cordialement Le 14/08/2019 à 04:44, VALOIS, Pascal a écrit : > > bonjour, > > Dans ton cas, je pense que tes vm1 2 et 3 ont chacune une route par > défaut positionnée, et que l'équipement qui assure leur routage fait > le lien entre les deux vlans. > > en gros, au niveau 2 tu est bien isolé, mais comme tu es dans un > contexte de ping et de routage ip, et non plus d'une transation pure > ethernet (niveau 2), ben tu as un chemin qui existe entre des vms. > > A ce niveau la, il faut ajouter des ACLS sur ton équipement de > routage, pour filtrer le niveau 3 (comme le ferai un firewall) > > Cordialement. > > Le 13/08/2019 à 23:23, Florent Nolot a écrit : >> >> Bonjour >> >> J'ai un problème d'isolation entre des VM connectés à un OpenVSwitch >> et utilisant des VLAN. Les vlan ne jouent pas leur rôle de >> cloisement. Je copie ci-dessous le post stackoverflow que j'ai >> effectué, resté sans réponse à ce jour. >> >> I have 3 VM (qemu with tap interface), 2 on vlan 10 and 1 on vlan 66 >> on the same lab1 OpenVSwitch. The first VM is connected via a tap >> interface on port lab1vm1. The second has 2 network interfaces >> connected on port lab1dhcp and lab1dhcpmaster and the third VM on >> port dhcpmaster. >> >> |------------- ----------------------- -------------- | VM 1 | | VM2 >> | | VM3 | |10.10.10.3 | |10.8.6.1 10.10.10.13| | 10.10.10.2 | >> ------------- ----------------------- -------------- | | | | | | | | >> ------------------------------------------------------------------ >> |lab1vm1 lab1dhcp lab1dhcpadm dhcpmaster OVS lab1| |tag 10 tag 10 tag >> 66 tag 66 | >> ------------------------------------------------------------------ | >> >> The OpenVSwitch is configured as follow : >> >> |Bridge"lab1"Port"lab1vm1"tag:10Interface"lab1vm1"Port"lab1"tag:10Interface"lab1"type:internal >> Port"lab1dhcp"tag:10Interface"lab1dhcp"Port"lab1dhcpadm"tag:66Interface"lab1dhcpadm"Portdhcpmaster >> tag:66Interfacedhcpmaster ovs_version:"2.9.2"| >> >> The problem: VM1 can ping VM3! >> >> * If I power off VM2 or shutdown lab1dhcp or lab1dhcpadm interface, >> the ping doesn't work. >> * If I shutdown the two network interfaces of VM2, ping works ! >> >> Why VM2 relay ICMP packet from VM1 to VM3 ? The broadcast send by VM1 >> reach also VM3 ! for example, if I ask an address from dhcp client on >> VM1, VM3 receive the dhcp discover. >> >> Merci pour votre aide. >> >> Florent >> >> >> _______________________________________________ >> Liste de diffusion du FRsAG >> http://www.frsag.org/ > >

3 6

Re : Problème d'isolation réseau et système sous Linux - OVS - Qemu
by LEFIEUX Morgan 14 Aug '19

14 Aug '19

2 1

Problème d'isolation réseau et système sous Linux - OVS - Qemu
by Florent Nolot 13 Aug '19

13 Aug '19

Bonjour J'ai un problème d'isolation entre des VM connectés à un OpenVSwitch et utilisant des VLAN. Les vlan ne jouent pas leur rôle de cloisement. Je copie ci-dessous le post stackoverflow que j'ai effectué, resté sans réponse à ce jour. I have 3 VM (qemu with tap interface), 2 on vlan 10 and 1 on vlan 66 on the same lab1 OpenVSwitch. The first VM is connected via a tap interface on port lab1vm1. The second has 2 network interfaces connected on port lab1dhcp and lab1dhcpmaster and the third VM on port dhcpmaster. |------------- ----------------------- -------------- | VM 1 | | VM2 | | VM3 | |10.10.10.3 | |10.8.6.1 10.10.10.13| | 10.10.10.2 | ------------- ----------------------- -------------- | | | | | | | | ------------------------------------------------------------------ |lab1vm1 lab1dhcp lab1dhcpadm dhcpmaster OVS lab1| |tag 10 tag 10 tag 66 tag 66 | ------------------------------------------------------------------ | The OpenVSwitch is configured as follow : |Bridge"lab1"Port"lab1vm1"tag:10Interface"lab1vm1"Port"lab1"tag:10Interface"lab1"type:internal Port"lab1dhcp"tag:10Interface"lab1dhcp"Port"lab1dhcpadm"tag:66Interface"lab1dhcpadm"Portdhcpmaster tag:66Interfacedhcpmaster ovs_version:"2.9.2"| The problem: VM1 can ping VM3! * If I power off VM2 or shutdown lab1dhcp or lab1dhcpadm interface, the ping doesn't work. * If I shutdown the two network interfaces of VM2, ping works ! Why VM2 relay ICMP packet from VM1 to VM3 ? The broadcast send by VM1 reach also VM3 ! for example, if I ask an address from dhcp client on VM1, VM3 receive the dhcp discover. Merci pour votre aide. Florent

1 0

Problème d'isolation réseau et système sous Linux - OVS - Qemu
by Florent Nolot 13 Aug '19

13 Aug '19

Bonjour J'ai un problème d'isolation entre des VM connectés à un OpenVSwitch et utilisant des VLAN. Les vlan ne jouent pas leur rôle de cloisement. Je copie ci-dessous le post stackoverflow que j'ai effectué, resté sans réponse à ce jour. I have 3 VM (qemu with tap interface), 2 on vlan 10 and 1 on vlan 66 on the same lab1 OpenVSwitch. The first VM is connected via a tap interface on port lab1vm1. The second has 2 network interfaces connected on port lab1dhcp and lab1dhcpmaster and the third VM on port dhcpmaster. |------------- ----------------------- -------------- | VM 1 | | VM2 | | VM3 | |10.10.10.3 | |10.8.6.1 10.10.10.13| | 10.10.10.2 | ------------- ----------------------- -------------- | | | | | | | | ------------------------------------------------------------------ |lab1vm1 lab1dhcp lab1dhcpadm dhcpmaster OVS lab1| |tag 10 tag 10 tag 66 tag 66 | ------------------------------------------------------------------ | The OpenVSwitch is configured as follow : |Bridge"lab1"Port"lab1vm1"tag:10Interface"lab1vm1"Port"lab1"tag:10Interface"lab1"type:internal Port"lab1dhcp"tag:10Interface"lab1dhcp"Port"lab1dhcpadm"tag:66Interface"lab1dhcpadm"Portdhcpmaster tag:66Interfacedhcpmaster ovs_version:"2.9.2"| The problem: VM1 can ping VM3! * If I power off VM2 or shutdown lab1dhcp or lab1dhcpadm interface, the ping doesn't work. * If I shutdown the two network interfaces of VM2, ping works ! Why VM2 relay ICMP packet from VM1 to VM3 ? The broadcast send by VM1 reach also VM3 ! for example, if I ask an address from dhcp client on VM1, VM3 receive the dhcp discover. Merci pour votre aide.

1 0