On Mon, Oct 30, 2017 at 11:16:47PM +0100, Reyk Floeter wrote: > > > 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 >
This was a fix for what I outlined there as well as bizarre behaviour during vmctl reload with bridges defined.
