Je comprends bien… c’est rapide.
Faire du apt-get dans un container, c’est juste pas mon habitude : Si j’ai besoin de faire ça, je build une image, je la pousse dans un repository et je pull dans la VM. Clair que c’est plus long au 1er coup
Je compte créer une VM File-Server avec eth0 puis installer Iproute2 pour brider la connexion puis installer Docker & co.
Ensuite, toutes mes VM « locale » seront sur eth1.
Il me semblait que « sur le papier » on sait par où ça rentre et sort… 
Il me semble qu’il n’utilise pas Docker quand il fait ses « apt-get » mais directement le package deb disponible depuis son LXC debian…
Peut être ai je compris de travers…
Oui c’est ça.
C’est ça. J’installe un debian de base dans le container LXC et là, je l’utilise comme un debian « normal », d’ou apt-get.
Ca doit être faisable. Mais, l’orthodoxie TCP/IP ne recommande pas ce genre de pratique.
Les interfaces physiques différentes soit on fait du bonding, soit on fait deux subnets.
Dans ta situation, je ferai du bonding et avec tc tu peux faire du throttling de bande passante vers certaines IP.
1 « J'aime »
je vais me documenter alors 
Merci pour le retour
dans ce cas, je fais toujours la limitation de la bande passante dans ma VM ? Ce qui change c’est juste l’agrégation c’est ça ?
Ou placerais tu l’utilisation de tc par ip ?
Sans avoir testé, je ferai tout au niveau de proxmox (le serveur lui-même, pas les VMs). A la base, c’est un debian avec des choses en plus.
Par défaut (config bête de base), toutes les VMs s’appuient sur un Linux Bridge vmbr0, qui lui même est bindé sur l’interface physique.
Donc, si je devais faire ça, je créerai un bonding bond0 avec eth0 et eth1 (à voir le nom de tes interfaces…) dans le bonding.
Une interface vmbr1 qui est bindé sur bond0.
Et j’appliquerai le shaping/throttling sur vmbr1. Donc, toutes les VMs seraient traitées en même temps.
1 « J'aime »
Il va falloir que je relise plusieurs fois ta réponse 
Ah ? pourtant c’est clair !
1 « J'aime »
Je conçois que l’explication est assez « velue » mais ce que tu souhaites faire l’est aussi.
J’ai oublié d’écrire que (bien entendu !!!), les VMs devraient s’appuyer sur VMBR1 et pas VMBR0 pour le réseau.
Mais, c’était implicite, pour voir si tu suis 
j’avais suivi…
J’en suis là :
https://pve.proxmox.com/wiki/Network_Configuration
Je lis je bouquine et pique du nez… 
Je comprends ce que tu me racontes et cela me parait logique…donc je vais partir la dessus…
Dernière question :
Quel est l’intérêt de faire de l’agréation si mon switch ne gère que du 1gbits/s ?
Est-ce utile pour l’instant ?
J’ai l’impression que la solution est de ne pas brancher eth1 et de faire du tc ip sur proxmox…
En clair, si je fais l’agrégation avec mon switch , vais je gagner en bande passante ou non ? je ne me rends pas compte…
Ca va être l’heure d’aller au lit de toute façon. Donc, c’est pas grave.
Je ne connais pas le reste de ton infra. Probablement pas dans l’immédiat. Après si tu as (un jour) un NAS avec des gros débits (et les disques/SSD/NVRAM qui vont bien) ou un accès fibre à plus d’un Gb/s, peut-être.
En usage domestique, je pense que le Gb/s suffit largement…
Oui, c’est aussi une option.
Sur mon nouveau serveur, avec mes deux ethernet, je ne vais pas faire du bonding mais, en fait, je vais migrer mon opnsense (firewall) physique en VM. Je vais dédier l’interface eth1 du host proxmox à l’interface « WAN » de mon firewall.
L’interface eth0 de proxmox sera le « LAN » du firewall et des VMs.
Après, chacun fait ce qu’il veut 
Sauf, de mettre deux interfaces physiques dans le même subnet. Ca, c’est mal. 
J’ai bien compris… 
1 « J'aime »
Sur mon proxmox, toutes mes vms sont sur une interface réseau dédié (vmbr qui n’est pas associé a une carte réseau physique).
Bon faut dire que j’ai un pfsense en tête comme VM qui s’occupe du routage.
Tout ça pour dire que mes vms communiquent entre elles sans polluer la carte puisqu’elles discutent sur une interface virtuelle non Bridger.
Et pour accéder aux autres devices physique elles utilisent le vlan dédié (gérer par pfsense avec les règles qui vont bien).
1 « J'aime »
Ça revient à ce que fait golfvert avec une troisième interface vmbr qui n’est ni eth0 ni eth1. Et dans opnsense tu lui ajoutes bien les 3 interfaces réseau.
Là messieurs vous avez éveillé ma curiosité, je sens que je vais étudier cette solution dans pas longtemps 
1 « J'aime »
Je post ma conf réseau de proxmox:
On voit bien que proxmox n’a accès qu’à VMBR1 (le lan)
Que vmbr4 (réseau dédié au VM) n’est pass bridgé sur une interface physique
C’est intéressant comme design. Je n’ai pas trop de dialogue inter-VMs donc, je ne sais pas si ça m’apporterait qq chose de faire ça.
Mais, même si tu affectes VMBR4 a une interface physique, le trafic purement local à ce bridge (donc entre les VMs), ne va pas utiliser de ressource de l’interface physique. Non?
Une autre raison (sécurité?) de faire cette architecture?
Je suis toujours à la chasse des complexités pas forcément nécessaires !
Je vois aussi que ton interface VMBR0 (le WAN de pfsense je pense) est bindé sur en0 sur laquelle proxmox n’a pas d’IP c’est ça?
Je pense que la carte réseau voit quand même le trafic, dans se cas pour moi c’est elle qui agit comme un switch (à vérifier en forçant un gros trafic entre 2 VM pour voir…).
Non ça sert à isoler le traffic entre les vlans notamment le WiFi-iot, les invités, les caméras (elles s’est pire je les ai privé d’internet tout cours :).
Oui Proxmox n’a qu’une seul IP sur le lan.
Pour info vmbr3 et vmbr5 sont aussi des WAN j’ai un double WAN free-adsl/orange-fibre et une connexion 4G en secours sur vmbr3. Pfsense se débrouille alors tout seul pour gérer le multi-wan et certaines règles forcent l’utilisation de tel ou tel wan. (mes mail par exemple sont associé à l’adresse IP fixe de free et s’ils sortent par orange il se font blacklisté car IP/DNS ne correspondent plus dans ce cas)
1 « J'aime »