This change allows you to specify multiple network interfaces to bridge
to, picking the first found.
```ruby
config.vm.network "public_network",
bridge: ["en4: Thunderbolt Ethernet",
"en6: Broadcom NetXtreme Gigabit Ethernet Controller",
"en0: Wi-Fi (AirPort)"]
```
This should fix the cleaning up of the default VirtualBox dhcpserver,
which we've been fighting with for ages over in #3083. We were checking
for a structure _including_ a netmask, but the driver was not populating
netmask.
Vagrant >1.7 is unable to login to the default boot2docker host if it has
been halted and brought back up again.
This is because the insecure SSH keypair is replaced but boot2docker doesn't
persist filesystem changes between reboots. So when next brought up Vagrant
tries to use the new keypair which is no longer valid and subsequently isn't
able to login.
Prevent this from happening by disabling the `ssh.insert_key` option on
versions where it is available.
fixes#3083
Detect the presence of the default DHCP server that comes in a fresh
VirtualBox install and clean it up to prevent it from colliding with
Vagrant-managed network config.
In order to accomplish this, we:
- add a `remove_dhcp_server` call to the virtualbox driver
- fix dhcp options parsing to allow `:dhcp_{ip,lower,upper}`
configuration options to make it through (so a user can override the
removal behavior with some explicit configuration)
- add the full `:network_name` to the details returned from
`:read_dhcp_servers`, so we can have a durable value to pass to
`:remove_dhcp_server`
Note that we do have to eat one more `VBoxManage list dhcpservers` for
each network interface to support this, but this seemed like a nominal
cost
This is just a refactor, no behavior change.
Instead of stitching together dhcpserver info in the structure returned
from `read_host_only_interfaces`, sprout a new driver method called
`read_dhcp_servers` to return that information separately.
This means that driver clients (well there's really only _one_ client in
`ProviderVirtualBox::Action::Network`) have to do a bit more work to get
interface and DHCP server information.
But this gives us (a) a cleaner and more consistent driver interface and
(b) groundwork for a fix for #3083, which will require interacting with
DHCP servers outside of the context of host-only interfaces.
