> On 27.10.2017, at 19:10, Mike Larkin <mlar...@azathoth.net> wrote: > > On Fri, Oct 27, 2017 at 09:58:09AM +0200, Martin Pieuchot wrote: >> On 26/10/17(Thu) 23:47, Mike Larkin wrote: >>> On Fri, Oct 27, 2017 at 08:23:05AM +0200, Martin Pieuchot wrote: >>>> On 26/10/17(Thu) 16:23, Carlos Cardenas wrote: >>>>> * Require interface name to be defined for switches in vm.conf >>>>> ** Requires user to create bridge(4) beforehand >>>>> * Remove code to create bridges on the fly >>>>> * Add code to ensure bridge really exists >>>>> * Update manpage switch and example sections >>>> >>>> What's the motivation to ask people to create a bridge(4) beforehand? >>>> >>> >>> This discussion came out of a previous effort to fix a bug where vmd(8) >>> doesn't >>> deconfigure bridges (and/or undo changes to bridges) it made during >>> initialization. After discussing this a bit with claudio, we decided that >>> rather than having vmd try to do magic stuff with creating bridges and >>> tearing them down behind the scenes (including corner cases where vmd is >>> killed or crashes/etc), it made sense instead to say "you create the bridge >>> and tell me which one you want to use". This can easily be accomplished >>> with a 1 (or 2) line /etc/hostname.bridgeX file. >>> >>> We may decide later to have vmd try to create bridges again at some point >>> but for now, I think this is a way to make some forward progress in this >>> area. >> >> I don't want to stop progress but I don't understand how creating a >> bridge(4) beforehand help to "deconfigure" it. Hence my question. > > We want vmd(8) to be out of the bridge manipulation business, except for > adding > and removing tapX interfaces for the guest VMs it manages. > > Right now, vmd(8) is in the bridge creation and deletion business, and it is > that second part that is giving us headache. Thus, we decided to remove both > parts since we don't have a good solution as a whole. >
OK, that answers a question that I just asked in another mail. I still don't understand why this is improving anything, but since I'm not around I cannot object. I used automatic bridge creation all the time and I never saw the theoretical problem of not "deconfiguring bridges". Why does it have to? It is a best-effort, it uses bridges if they already exist. And vmd already supported configuration with pre-configured bridges. Or was there a (supposedly simple) bug with pre-configured bridges? Reyk
