shield the guest from nameserver changes when using :hostonly networking

[schisamo]

I provisioned a VM at coworking today and the guest VM inherited the nameserver info from that network:

vagrant@piab-private-chef:~$ cat /etc/resolv.conf 
nameserver 192.168.34.251
domain thebox
search thebox

I went home where I expected this configuration:

nameserver 208.67.222.222 # opendns
nameserver 10.66.44.1 # internal router

VirtualBox ships with the ability to enable a DNS proxy in NAT mode to shield the guest VM from this issue. When this mode is enabled the guest VM receives this configuration:

vagrant@piab-private-chef:~$ cat /etc/resolv.conf 
nameserver 10.0.2.3

10.0.2.3 is a DNS proxy that 'does the right thing'. We should probably enable by default when Vagrant has a network type :hostonly. This commit does just that!

[miketheman]

@schisamo - what is the impact of this setting when using a VM with both NAT and Host-only adapters?

[schisamo]

@miketheman it does what I would consider to be "the right thing" and disables the DNS proxy:

A Vagrantfile which contains:

config.vm.network :hostonly, '33.33.33.10'
config.vm.network :bridged

produces:

vagrant@piab-private-chef:~$ cat /etc/resolv.conf 
nameserver 208.67.222.222
nameserver 10.66.44.1
vagrant@piab-private-chef:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 08:00:27:70:6a:a2  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe70:6aa2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:289127 errors:0 dropped:0 overruns:0 frame:0
          TX packets:88372 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:406998787 (406.9 MB)  TX bytes:4978341 (4.9 MB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:04:1c:85  
          inet addr:33.33.33.10  Bcast:33.33.33.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe04:1c85/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2815 (2.8 KB)  TX bytes:398 (398.0 B)

eth2      Link encap:Ethernet  HWaddr 08:00:27:e2:a9:f2  
          inet addr:10.66.44.77  Bcast:10.66.44.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fee2:a9f2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:39 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6512 (6.5 KB)  TX bytes:1152 (1.1 KB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:560 (560.0 B)  TX bytes:560 (560.0 B)

[mitchellh]

@miketheman This would require a NAT adapter. As you can see in the patch it looks like @schisamo is simply using the Vagrant assumption that there is a NAT adapter on NIC 1 to enable this.

@schisamo I actually enable this on almost every VM I create, using config.vm.customize, so I feel like this should be a sane default.

The one negative thing I can think of is eventually I would like to get rid of Vagrant's reliance on NIC1 being a NAT adapter, and this code would be complicated to maintain backwards compatibility in that case, since then the driver would have to find the NAT adapter (if there is one) and enable it. Hm.

I think I'm going to take a day or two to think over and see if I can think of any other negative effects of this... then I'll merge.

[schisamo]

@mitchellh thanks for the tip about using config.vm.customize to set --natdnsproxy1 on in the Vagrantfile. After looking at it more I think this may not be the best spot for this default. Got any hints on where sane defaults like this should go? Another example sane defaults would be --usbehci off to disable USB 2.0 and thus a reliance on the Oracle VM VirtualBox Extension Pack which a lot of people may not have installed by default.

[mitchellh]

Okay! I think this makes sense to include as a default. I think you're right that where you put it isn't the best place for it. I think the best place for it may be as another middleware like VM::Defaults. The usbehci setting seems like a good idea as well.

[mitchellh]

@schisamo If you're still interested in this can you perhaps try to add this feature to the SaneDefaults middleware: https://github.com/mitchellh/vagrant/blob/master/lib/vagrant/action/vm/sane_defaults.rb

I've started putting some opinionated defaults in there. :)