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. -ml
