Skip to content
This repository has been archived by the owner on Nov 24, 2022. It is now read-only.

vagrant halt removes lxc bridge that leads to impossibility to vagrant up afterwards #353

Closed
podarok opened this issue Mar 16, 2015 · 8 comments
Labels
Milestone

Comments

@podarok
Copy link
Contributor

podarok commented Mar 16, 2015

Here is a working config

    config.vm.network "private_network", ip: "x.x.x.x", lxc__bridge_name: "lxcbr0"

lxcbr0 being enabled during system startup
when running vagrant halt there is a message

==> default: Clearing any previously set forwarded ports...
==> default: Attempting graceful shutdown of VM...
==> default: Removing bridge 'lxcbr0'...

So vagrant up won't work before system restart and recreate lxc bridge
I see no ability to restart lxc bridge, because it is started via runlevel during system boot
Are there any config for skippping bridge removal for vagrant halt?
If no, we totally need it, because it leads to unusable behaviour

@fgrehm
Copy link
Owner

fgrehm commented Mar 16, 2015

lxcbr0 is a system managed bridge and should not be used for private networking. Please use a different bridge name (I'll leave this issue open as a reminder to add some documentation around this to the readme)

@podarok
Copy link
Contributor Author

podarok commented Mar 16, 2015

@fgrehm do you have an example for how to configure Vagrantfile for creating new bridge for every vagrant up ?

@fgrehm
Copy link
Owner

fgrehm commented Mar 16, 2015

Things should work just fine if you use other bridge name. Here's more information on how it works: https://github.com/fgrehm/vagrant-lxc#private-networks-experimental

If that is not clear enough please LMK so we can discuss how to improve docs!

@ccope
Copy link
Contributor

ccope commented Mar 17, 2015

Ugh I meant to add a check around this myself. I was hackily avoiding the issue by leaving other containers attached to the bridge. I think it would be reasonable to avoid deleting lxcbr0, docker0, and virbr0 (all common default bridge names).

@perj
Copy link

perj commented Mar 17, 2015

I think the reason this is not obvious because I have to set the bridge name manually, and that makes me expect to be able to use a preconfigured bridge. The virtualbox driver just uses the first matching vboxnet right? (hostonly_find_matching_network) And creates one if there's no matching. The proper fix might be to do something similar.

Btw, looking at the virtualbox driver, it looks like it optionally uses :name to name the interface. And if :name is set but the interface is not preconfigured, it errors. Not saying lxc has to do the same but it's good to know how others have dealt with it.

@fgrehm
Copy link
Owner

fgrehm commented Mar 17, 2015

Just out of curiosity, why are you guys using private networking with lxcbr0? Are you guys just wanting to set a static IP for the container? If that is the case, this can be easily handled by network.ipv4 (more info here)

I think it would be reasonable to avoid deleting lxcbr0, docker0, and virbr0 (all common default bridge names).

The reason I did not do that is because I have some plans to spike on getting vagrant-lxc to create a bridge that looks like Ubuntu's lxcbr0 on systems that have no networking setup (there have been reports related to "networking weirdness"es that could benefit from that) and in those cases we'd remove the bridge if the plugin was responsible for its creation.

I think the reason this is not obvious because I have to set the bridge name manually, and that makes me expect to be able to use a preconfigured bridge.

Sorry but I think it is clear from the readme how it works: "Once the last vagrant-lxc container attached to the bridge gets vagrant halted, the plugin will delete the bridge." (not to say that the functionality is experimental 😄 )

Btw, looking at the virtualbox driver, it looks like it optionally uses :name to name the interface. And if :name is set but the interface is not preconfigured, it errors. Not saying lxc has to do the same but it's good to know how others have dealt with it.

Automagic bridge naming is going to be supported eventually. Private networking is a feature I do not use that much and I wanted to first validate that the basic "infrastructure" (aka pipework) is working as intended before going that direction. More on #341 (comment)

@perj
Copy link

perj commented Mar 17, 2015

Perhaps adding support for :name that behaves the same as virtualbox could be a good first compromise (if I read that code correctly, will have to double check), I'll see if I can get cracking on that (not promising).

stucki pushed a commit to stucki/vagrant-lxc that referenced this issue Jul 6, 2015
stucki pushed a commit to stucki/vagrant-lxc that referenced this issue Jul 6, 2015
stucki pushed a commit to stucki/vagrant-lxc that referenced this issue Aug 25, 2015
stucki pushed a commit to stucki/vagrant-lxc that referenced this issue Aug 25, 2015
stucki pushed a commit to stucki/vagrant-lxc that referenced this issue Aug 25, 2015
fpletz pushed a commit that referenced this issue Aug 28, 2015
@globin globin added bug and removed documentation labels Sep 8, 2015
@globin globin added this to the v1.2.0 milestone Sep 8, 2015
@globin
Copy link
Contributor

globin commented Sep 8, 2015

Fixed in master

@globin globin closed this as completed Sep 8, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants