New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow setting an IP address on :bridged #743

Closed
deanpcmad opened this Issue Feb 15, 2012 · 38 comments

Comments

Projects
None yet
@deanpcmad

I would like to be able to manually set an IP address on a Vagrant machine using the Vagrantfile.
When I set config.vm.network :bridged, "192.168.1.200", when creating the machine, it breaks and destroys the machine.

It does it on both my Ubuntu machine and Mac.

Running vagrant 0.9.7.

This is what I get on my Ubuntu machine which is where I will be running my Vagrant machines:

dean@dean-ubuntu:~/VMs/lucid32$ vagrant up
[default] Importing base box 'lucid32'...

Guest Additions Version: 4.1.0
VirtualBox Version: 4.1.8
[default] Matching MAC address for NAT networking...
[default] Clearing any previously set forwarded ports...
[default] Fixed port collision for 22 => 2222. Now on port 2200.
[default] Forwarding ports...
[default] -- 22 => 2200 (adapter 1)
[default] Creating shared folders metadata...
[default] Clearing any previously set network interfaces...
[default] Destroying VM and associated drives...
/usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/network.rb:318:in `merge': can't convert String into Hash (TypeError)
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/network.rb:318:in `bridged_config'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/network.rb:33:in `block in call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/network.rb:31:in `each'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/network.rb:31:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/clear_network_interfaces.rb:26:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/host_name.rb:10:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/share_folders.rb:20:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/clear_shared_folders.rb:13:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/nfs.rb:40:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/prune_nfs_exports.rb:15:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/provision.rb:29:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/forward_ports.rb:24:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/check_port_collisions.rb:38:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/env/set.rb:16:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/clear_forwarded_ports.rb:13:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/clean_machine_folder.rb:17:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/check_accessible.rb:18:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/general/validate.rb:14:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/match_mac_address.rb:16:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/default_name.rb:17:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/check_guest_additions.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/import.rb:31:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/check_box.rb:28:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/vm/check_accessible.rb:18:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/general/validate.rb:14:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/warden.rb:33:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/builder.rb:92:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/runner.rb:49:in `block in run'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/util/busy.rb:19:in `busy'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/action/runner.rb:49:in `run'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/vm.rb:192:in `run_action'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/vm.rb:143:in `up'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/command/up.rb:46:in `block in execute'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/command/base.rb:100:in `block in with_target_vms'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/command/base.rb:95:in `each'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/command/base.rb:95:in `with_target_vms'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/command/up.rb:39:in `execute'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/cli.rb:38:in `execute'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/lib/vagrant/environment.rb:156:in `cli'
    from /usr/local/lib/ruby/gems/1.9.1/gems/vagrant-0.9.7/bin/vagrant:43:in `<top (required)>'
    from /usr/local/bin/vagrant:19:in `load'
    from /usr/local/bin/vagrant:19:in `<main>'
@mitchellh

This comment has been minimized.

Show comment
Hide comment
@mitchellh

mitchellh Feb 15, 2012

Member

Nice, the stack trace is a bug, but unfortunately you can't statically assign an IP on bridged networks. Since the behavior of a bridged network is to join your existing network, your best bet is to assign a static MAC address to your bridged network, then configure your router so that that MAC address always gets the same IP address.

Member

mitchellh commented Feb 15, 2012

Nice, the stack trace is a bug, but unfortunately you can't statically assign an IP on bridged networks. Since the behavior of a bridged network is to join your existing network, your best bet is to assign a static MAC address to your bridged network, then configure your router so that that MAC address always gets the same IP address.

@deanpcmad

This comment has been minimized.

Show comment
Hide comment
@deanpcmad

deanpcmad Feb 15, 2012

Wow, that was fast. Ah ok, but won't multiple machines get that same IP then causing IP conflicts?

Wow, that was fast. Ah ok, but won't multiple machines get that same IP then causing IP conflicts?

@deanpcmad

This comment has been minimized.

Show comment
Hide comment
@deanpcmad

deanpcmad Feb 15, 2012

I suppose either that or would setting an IP for :hostonly and then setting the hosts file to the machine which has that work or is it strictly :hostonly and that IP will only be accessible on that host?

I suppose either that or would setting an IP for :hostonly and then setting the hosts file to the machine which has that work or is it strictly :hostonly and that IP will only be accessible on that host?

@mitchellh

This comment has been minimized.

Show comment
Hide comment
@mitchellh

mitchellh Feb 15, 2012

Member

Multiple machines shouldn't get the same IP, unless multiple VMs have the same MAC address (which they shouldn't) or your DHCP server is broken (not Vagrant's problem).

Host-only networks are not globally accessible.

Member

mitchellh commented Feb 15, 2012

Multiple machines shouldn't get the same IP, unless multiple VMs have the same MAC address (which they shouldn't) or your DHCP server is broken (not Vagrant's problem).

Host-only networks are not globally accessible.

@deanpcmad

This comment has been minimized.

Show comment
Hide comment
@deanpcmad

deanpcmad Feb 15, 2012

Would it be possible to add a static option on the config for globally accessible IPs?

Would it be possible to add a static option on the config for globally accessible IPs?

@mitchellh

This comment has been minimized.

Show comment
Hide comment
@mitchellh

mitchellh Feb 15, 2012

Member

What do you mean "globally accessible IPs?"

Member

mitchellh commented Feb 15, 2012

What do you mean "globally accessible IPs?"

@deanpcmad

This comment has been minimized.

Show comment
Hide comment
@deanpcmad

deanpcmad Feb 15, 2012

Well basically bridged and then an IP can be set, then when setting up the machine, Vagrant then sets that specified IP in, for example, /etc/network/interfaces. Or would this not be possible? I may have a look at the code and see if I can give it a go. :)

Well basically bridged and then an IP can be set, then when setting up the machine, Vagrant then sets that specified IP in, for example, /etc/network/interfaces. Or would this not be possible? I may have a look at the code and see if I can give it a go. :)

@mitchellh

This comment has been minimized.

Show comment
Hide comment
@mitchellh

mitchellh Feb 16, 2012

Member

Fixed the bug issue that you found.

Member

mitchellh commented Feb 16, 2012

Fixed the bug issue that you found.

@mitchellh mitchellh closed this Feb 16, 2012

@philwo

This comment has been minimized.

Show comment
Hide comment
@philwo

philwo Apr 5, 2012

Hi,

"you can't statically assign an IP on bridged networks" - actually, that is exactly what is needed in my case, because I am setting up a development network and the virtual machine is the DHCP server for other virtual machines and some physical hosts on the bridged network (which is an isolated network to test an OpenStack private cloud).

Do you see any chance of implementing that? :)

Best regards,
Philipp

philwo commented Apr 5, 2012

Hi,

"you can't statically assign an IP on bridged networks" - actually, that is exactly what is needed in my case, because I am setting up a development network and the virtual machine is the DHCP server for other virtual machines and some physical hosts on the bridged network (which is an isolated network to test an OpenStack private cloud).

Do you see any chance of implementing that? :)

Best regards,
Philipp

@roymax

This comment has been minimized.

Show comment
Hide comment
@roymax

roymax May 22, 2012

Allow setting an IP address on :bridged + 1

roymax commented May 22, 2012

Allow setting an IP address on :bridged + 1

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jul 10, 2012

This would be a useful feature, and Im not sure why it is judged as not possible.

I might misunderstand the question, but I know I can boot a VM with vagrant and a bridged network for eth1, then manually assign the VM a static ip. On CentOS I edit /etc/sysconfig/network-scripts/ifcfg-eth1 with the following, and restart networking:

BOOTPROTO=static
IPADDR=192.168.5.100
DEVICE=eth1
NETMASK=255.255.248.0

As long as Im not assigning anything that can conflict with the DHCP server then there is no problem, and the VM can be accessed by all other machines on the network at this static IP...

... until I reboot. Because vagrant doesn't know about this config then of course it resets it to DHCP on reboot.

If I can set that up manually each time the machine reboots, surely Vagrant could manage it via its config?

[edit: fixed netmask setting in example]

ghost commented Jul 10, 2012

This would be a useful feature, and Im not sure why it is judged as not possible.

I might misunderstand the question, but I know I can boot a VM with vagrant and a bridged network for eth1, then manually assign the VM a static ip. On CentOS I edit /etc/sysconfig/network-scripts/ifcfg-eth1 with the following, and restart networking:

BOOTPROTO=static
IPADDR=192.168.5.100
DEVICE=eth1
NETMASK=255.255.248.0

As long as Im not assigning anything that can conflict with the DHCP server then there is no problem, and the VM can be accessed by all other machines on the network at this static IP...

... until I reboot. Because vagrant doesn't know about this config then of course it resets it to DHCP on reboot.

If I can set that up manually each time the machine reboots, surely Vagrant could manage it via its config?

[edit: fixed netmask setting in example]

@ccollicutt

This comment has been minimized.

Show comment
Hide comment
@ccollicutt

ccollicutt Aug 18, 2012

I would like to be able to do bridged networking with a static IP as well.

I would like to be able to do bridged networking with a static IP as well.

@demelziraptor

This comment has been minimized.

Show comment
Hide comment
@demelziraptor

demelziraptor Sep 10, 2012

This would be very useful. Right now I'm having to set the static IP with a script that runs after the interface comes up on dhcp. (Can't put in /etc/network/interfaces in Ubuntu or the VM won't come back up on vagrant up.)

This would be very useful. Right now I'm having to set the static IP with a script that runs after the interface comes up on dhcp. (Can't put in /etc/network/interfaces in Ubuntu or the VM won't come back up on vagrant up.)

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 4, 2012

yeah really who's idea was it to not have any ip at all or to hope for dhcp on bridged interfaces..... derp

ghost commented Oct 4, 2012

yeah really who's idea was it to not have any ip at all or to hope for dhcp on bridged interfaces..... derp

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 4, 2012

really simple solution

auto eth2:1
iface eth2:1 inet static
address 192.168.1.235
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameserver 192.168.1.250
post-up route add default gw 192.168.1.1 dev eth2:1

#VAGRANT-BEGIN
auto eth2
iface eth2 inet dhcp
post-up route del default dev $IFACE
#VAGRANT-END

ghost commented Oct 4, 2012

really simple solution

auto eth2:1
iface eth2:1 inet static
address 192.168.1.235
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameserver 192.168.1.250
post-up route add default gw 192.168.1.1 dev eth2:1

#VAGRANT-BEGIN
auto eth2
iface eth2 inet dhcp
post-up route del default dev $IFACE
#VAGRANT-END

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 4, 2012

vagrant@VPN:~$ tail /etc/init.d/networking
echo "Usage: /etc/init.d/networking {start|stop}"
exit 1
;;
esac

route del default gw 10.0.2.2 dev eth0
route add default gw 192.168.1.1 dev eth2:1

exit 0

vagrant@VPN:~$

ghost commented Oct 4, 2012

vagrant@VPN:~$ tail /etc/init.d/networking
echo "Usage: /etc/init.d/networking {start|stop}"
exit 1
;;
esac

route del default gw 10.0.2.2 dev eth0
route add default gw 192.168.1.1 dev eth2:1

exit 0

vagrant@VPN:~$

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 4, 2012

rm /sbin/dhclient

ghost commented Oct 4, 2012

rm /sbin/dhclient

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 4, 2012

also add static for eth0 10.0.2.2 so that vagrant sp33kz to it. _ there done vagrant package VPN --output VPN.box and never mess with it again.

ghost commented Oct 4, 2012

also add static for eth0 10.0.2.2 so that vagrant sp33kz to it. _ there done vagrant package VPN --output VPN.box and never mess with it again.

@rasschaert

This comment has been minimized.

Show comment
Hide comment
@rasschaert

rasschaert Apr 16, 2013

Contributor

@mitchellh please reconsider your position on this. Not being able to assign a static IP on bridged interfaces makes Vagrant close to useless for doing any meaningful operations/infrastructure work.

I'm a sysadmin/devops by trade so my use case for Vagrant may be atypical. I often set up some VirtualBox machines to try out some infrastructure setups and service configurations. Being able to bring up a couple of boxes with predictable network addresses and have them talk over various network protocols to each other is essential for setting up an operations lab. I've been using VirtualBox for this type of testing with bridged interfaces and static IP addresses for years, without a hitch.

You mention DHCP with MAC addresses in the config as an alternative, but we should be able to set this up from within a Vagrantfile. Heck, the only router I have in my apartment is the one I got from my ISP who pretty much locked down advanced configuration. I couldn't fiddle with the DHCP settings if I wanted to.

I understand where you're coming from. There is the risk of having conflicting addresses. Put a big bold warning in the docs saying users should make sure the IP addresses they assign don't overlap with their DHCP pool. Have Vagrant quickly ping the IP before assigning it to make sure it's not already in use. Bury the option deep in the docs if you must, but please, provide this option.

I'll get off my soapbox now, thanks for reading.

Contributor

rasschaert commented Apr 16, 2013

@mitchellh please reconsider your position on this. Not being able to assign a static IP on bridged interfaces makes Vagrant close to useless for doing any meaningful operations/infrastructure work.

I'm a sysadmin/devops by trade so my use case for Vagrant may be atypical. I often set up some VirtualBox machines to try out some infrastructure setups and service configurations. Being able to bring up a couple of boxes with predictable network addresses and have them talk over various network protocols to each other is essential for setting up an operations lab. I've been using VirtualBox for this type of testing with bridged interfaces and static IP addresses for years, without a hitch.

You mention DHCP with MAC addresses in the config as an alternative, but we should be able to set this up from within a Vagrantfile. Heck, the only router I have in my apartment is the one I got from my ISP who pretty much locked down advanced configuration. I couldn't fiddle with the DHCP settings if I wanted to.

I understand where you're coming from. There is the risk of having conflicting addresses. Put a big bold warning in the docs saying users should make sure the IP addresses they assign don't overlap with their DHCP pool. Have Vagrant quickly ping the IP before assigning it to make sure it's not already in use. Bury the option deep in the docs if you must, but please, provide this option.

I'll get off my soapbox now, thanks for reading.

@HarlekinX

This comment has been minimized.

Show comment
Hide comment
@HarlekinX

HarlekinX Apr 16, 2013

I solved the problem with a workaround.

First i have to say that i don't understand the developer of this damn great product, because it really is a problem to not be able to set a static IP Address on a bridged network.
"Let the router do it" doesn't work in lots of setups, as others already mentioned.
My setup is: Multiple virtual servers on my Mac mini Server at home, all with different purposes. I.e a puppet master, available in my home network and over VPN with separated IP ranges, which requires 2 network adapters. My internet router manages the internal IP range, the Mac mini Server the VPN range.
Just using DHCP would put both adapters into the same IP range.
And as @rasschaert said, i first thought that this makes the usage of Vagrant useless for me.
An other problem is, that my router is indeed able to assign the same IP to a given MAC-Address every time, but i cannot choose which one. But for me, i like a clean IP structure i.e. X.X.X.10 - 29 these type of machines, 30 - 40 other types of machines. I just use DHCP beginning from .200 for mobile and guest devices.

Ok, enough talk, here's my solution:

  1. Add :auto_config => false to your network config, i.e.:

config.vm.network :public_network, :bridge => 'en0: Ethernet', :auto_config => false

This will setup the network adapter but neither configures nor activates it.

  1. Use puppet, chef or shell provider to run the ifconfig command at startup, i.e.:

Shell:
ifconfig eth1 192.168.1.60 netmask 255.255.255.0 up

Puppet:
exec{ "Set static IP":
command => "/sbin/ifconfig eth1 192.168.1.60 netmask 255.255.255.0 up",
}

Chef:
I don't know, i'm a puppet user ;-)

This configures and activates the network adapter with a static IP.
And in contrast to the other tips in this thread this works directly on creation of an VM and does not require to edit something in an existing machine that would be lost on vagrant destroy

I solved the problem with a workaround.

First i have to say that i don't understand the developer of this damn great product, because it really is a problem to not be able to set a static IP Address on a bridged network.
"Let the router do it" doesn't work in lots of setups, as others already mentioned.
My setup is: Multiple virtual servers on my Mac mini Server at home, all with different purposes. I.e a puppet master, available in my home network and over VPN with separated IP ranges, which requires 2 network adapters. My internet router manages the internal IP range, the Mac mini Server the VPN range.
Just using DHCP would put both adapters into the same IP range.
And as @rasschaert said, i first thought that this makes the usage of Vagrant useless for me.
An other problem is, that my router is indeed able to assign the same IP to a given MAC-Address every time, but i cannot choose which one. But for me, i like a clean IP structure i.e. X.X.X.10 - 29 these type of machines, 30 - 40 other types of machines. I just use DHCP beginning from .200 for mobile and guest devices.

Ok, enough talk, here's my solution:

  1. Add :auto_config => false to your network config, i.e.:

config.vm.network :public_network, :bridge => 'en0: Ethernet', :auto_config => false

This will setup the network adapter but neither configures nor activates it.

  1. Use puppet, chef or shell provider to run the ifconfig command at startup, i.e.:

Shell:
ifconfig eth1 192.168.1.60 netmask 255.255.255.0 up

Puppet:
exec{ "Set static IP":
command => "/sbin/ifconfig eth1 192.168.1.60 netmask 255.255.255.0 up",
}

Chef:
I don't know, i'm a puppet user ;-)

This configures and activates the network adapter with a static IP.
And in contrast to the other tips in this thread this works directly on creation of an VM and does not require to edit something in an existing machine that would be lost on vagrant destroy

@nywilken

This comment has been minimized.

Show comment
Hide comment
@nywilken

nywilken Apr 24, 2013

Thanks for the tip on your bridged network workaround. It doesn't seem like the ability to set :auto_config for a bridged network is documented in the Vagrant documentation. Anyway below is the Chef equivalent to your Puppet exec resource.

execute "ifup" do
    command "/sbin/ifconfig eth1 192.168.1.60 netmask 255.255.255.0 up"
end

Thanks for the tip on your bridged network workaround. It doesn't seem like the ability to set :auto_config for a bridged network is documented in the Vagrant documentation. Anyway below is the Chef equivalent to your Puppet exec resource.

execute "ifup" do
    command "/sbin/ifconfig eth1 192.168.1.60 netmask 255.255.255.0 up"
end
@ErebusBat

This comment has been minimized.

Show comment
Hide comment
@ErebusBat

ErebusBat May 16, 2013

Thanks to the others the solution I came up with was to stick this into my bootstrap.sh file:

echo "Setting up bridged interface"
sudo /sbin/ifconfig eth1 192.168.0.100 netmask 255.255.255.0 up
sudo /sbin/route add default gw 192.168.0.1 eth1

If you don't have a bootstrap.sh setup then you can add the following to your Vagrantfile

config.vm.provision :shell, :path => "bootstrap.sh"

Thanks to the others the solution I came up with was to stick this into my bootstrap.sh file:

echo "Setting up bridged interface"
sudo /sbin/ifconfig eth1 192.168.0.100 netmask 255.255.255.0 up
sudo /sbin/route add default gw 192.168.0.1 eth1

If you don't have a bootstrap.sh setup then you can add the following to your Vagrantfile

config.vm.provision :shell, :path => "bootstrap.sh"
@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 22, 2013

Allow setting an IP address on :bridged + 1

ghost commented May 22, 2013

Allow setting an IP address on :bridged + 1

@knightsamar

This comment has been minimized.

Show comment
Hide comment
@knightsamar

knightsamar Jun 5, 2013

Option for setting a static IP on :public_network 👍

@mitchellh, maybe you can keep the DHCP as default for :public_network, but please provide an option for static IP

Option for setting a static IP on :public_network 👍

@mitchellh, maybe you can keep the DHCP as default for :public_network, but please provide an option for static IP

@Flimm

This comment has been minimized.

Show comment
Hide comment

Flimm commented Aug 7, 2013

+1

@bryfry

This comment has been minimized.

Show comment
Hide comment
@bryfry

bryfry Sep 2, 2013

Here is my solution with ansible as the 'provisioner' : https://github.com/bryfry/vaspi

This really seems like a basic feature that any normal provider like virtualbox should have out of the box.

+1 to get this patched to not rely on provisioning hacks to get standard functionality.

bryfry commented Sep 2, 2013

Here is my solution with ansible as the 'provisioner' : https://github.com/bryfry/vaspi

This really seems like a basic feature that any normal provider like virtualbox should have out of the box.

+1 to get this patched to not rely on provisioning hacks to get standard functionality.

@byxelkrok

This comment has been minimized.

Show comment
Hide comment

+1

@byxelkrok

This comment has been minimized.

Show comment
Hide comment
@byxelkrok

byxelkrok Sep 13, 2013

to bring up the static ip on the guest os, you could also run this command from the host os:

vagrant ssh -c"sudo /sbin/ifconfig eth1 192.168.0.100 netmask 255.255.255.0 up"

to bring up the static ip on the guest os, you could also run this command from the host os:

vagrant ssh -c"sudo /sbin/ifconfig eth1 192.168.0.100 netmask 255.255.255.0 up"

@NebuPookins

This comment has been minimized.

Show comment
Hide comment
@NebuPookins

NebuPookins Nov 9, 2013

your best bet is to assign a static MAC address to your bridged network, then configure your router so that that MAC address always gets the same IP address.

How do you set a static MAC address to your bridged network? I googled for "vagrant mac address", but

I've also read through the Version 2 documentation, particularly the pages:

And could not find any information regarding setting the MAC address.

Is it documented anywhere?

your best bet is to assign a static MAC address to your bridged network, then configure your router so that that MAC address always gets the same IP address.

How do you set a static MAC address to your bridged network? I googled for "vagrant mac address", but

I've also read through the Version 2 documentation, particularly the pages:

And could not find any information regarding setting the MAC address.

Is it documented anywhere?

@weidongshao

This comment has been minimized.

Show comment
Hide comment
@weidongshao

weidongshao Feb 5, 2014

+1 for this feature!
There are many use cases for a static IP on a bridged interface. e.g, I want the VM guest to provide DHCP services to the bridged network in my case!!

+1 for this feature!
There are many use cases for a static IP on a bridged interface. e.g, I want the VM guest to provide DHCP services to the bridged network in my case!!

@tclh123

This comment has been minimized.

Show comment
Hide comment

tclh123 commented Jun 4, 2014

+1

@bohrqiu

This comment has been minimized.

Show comment
Hide comment

bohrqiu commented Jul 1, 2014

+1

@erronjason

This comment has been minimized.

Show comment
Hide comment

+1

@iongion

This comment has been minimized.

Show comment
Hide comment
@iongion

iongion Oct 14, 2014

+1
3 years :(

iongion commented Oct 14, 2014

+1
3 years :(

@youranwj

This comment has been minimized.

Show comment
Hide comment

youranwj commented Jun 9, 2015

+1

@anderm3

This comment has been minimized.

Show comment
Hide comment
@anderm3

anderm3 Sep 28, 2015

@mitchellh I was coming by to add another 👍 to this, but I was wondering if you'd be open to a PR related to this request and I am wondering if there are some edge cases you are particularly concerned about?

anderm3 commented Sep 28, 2015

@mitchellh I was coming by to add another 👍 to this, but I was wondering if you'd be open to a PR related to this request and I am wondering if there are some edge cases you are particularly concerned about?

@rohan-plt

This comment has been minimized.

Show comment
Hide comment
@rohan-plt

rohan-plt Sep 1, 2017

+1
The fact that so many people are resorting to hacks to do this anyway should indicate that it is possible to do this safely. "Just do this in the {router|DHCP server}" misses the reality that not all of us have full control of our environment. I am using Vagrant on a network where the IT department is actively hostile to anything that isn't Windows.

You could make this much simpler for us. You could trivially have Vagrant's internal SSH working over v6 link local addresses. Alternatively let us tell Vagrant the static IPv4 or IPv6 address we will configure and let us configure /etc/network/interfaces or the equivalent and ignore the rest of the networking config from there.
Thanks,
-rohan

+1
The fact that so many people are resorting to hacks to do this anyway should indicate that it is possible to do this safely. "Just do this in the {router|DHCP server}" misses the reality that not all of us have full control of our environment. I am using Vagrant on a network where the IT department is actively hostile to anything that isn't Windows.

You could make this much simpler for us. You could trivially have Vagrant's internal SSH working over v6 link local addresses. Alternatively let us tell Vagrant the static IPv4 or IPv6 address we will configure and let us configure /etc/network/interfaces or the equivalent and ignore the rest of the networking config from there.
Thanks,
-rohan

@hedss

This comment has been minimized.

Show comment
Hide comment
@hedss

hedss Dec 21, 2017

Heya, Vagrant is generally awesome, but I'm yet another +1 for this thread.

I, like many others here, want to use the VM as the DHCP server, amongst other services, and I'm also using hacks to do this atm.

hedss commented Dec 21, 2017

Heya, Vagrant is generally awesome, but I'm yet another +1 for this thread.

I, like many others here, want to use the VM as the DHCP server, amongst other services, and I'm also using hacks to do this atm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment