Vagrant: Network Regression in 2.2.1

[davidalger]

Vagrant version

Version 2.2.1

Host operating system

MacOS 10.14

Guest operating system

CentOS 7.5

Expected behavior

Should not introduce regressions caused by changing default vagrant behavior in a patch release.

Actual behavior

Issue #10383 did more than add support for specifying a default NIC type. It _changed_ the default NIC type from nil (i.e. use what's specified in the base image) to "virtio". The virtio NIC type causes major trouble with NFS mounts, at least on all the Mac based setups where I work.

All of sudden, with Vagrant 2.2.1 the machines that had been working flawlessly would have the NFS mounted devices freeze up rendering the virtual machine useless and it would have to be forcibly (the MySQL data in these VMs is on an NFS mount, which prevents normal shutdown when NFS freezes up).

The only difference is the NIC type. Previously our machines were starting with NIC type of "82540EM" as that is what was built into the base images. Now with vagrant 2.2.1 they're starting with virtio.

Adding the NIC type explicitly to our VagrantFile resolved the issues. _We are doing this to workaround the issue, but I still felt I should report it, as the change is a major BC break from my perspective and will likely affect other setups as well_

  node.vm.network :private_network, ip: ip, nic_type: "82540EM"
  node.vm.provider "virtualbox" do |vb|
    vb.customize ["modifyvm", :id, "--nictype1", "82540EM"]
  end

Steps to reproduce

We have a very reliable test case, which causes the virtio network to go belly up under NFS:

1. Start the VM (where /var/www/sites is mounted into the guest via NFS)

2. SSH into the VM and verify things are working great. A quick “ls -1R /var/www/sites >/dev/null” would verify this for me, and running "watch -d -n1 nfsstat -c” would show me the many successful hits to the NFS mount.

3. Run either a “composer create-project” to setup a new Magento 2 site or delete the vendor directory in a site and then a “composer install” from within the VM.

4. Watch the nfsstat output via that same command: "watch -d -n1 nfsstat -c”

It wouldn’t get more than a few files on disk and it would go bust!

References

• GH-10383

Additional Info

From the Virtual Box manual section on networking:

The "Paravirtualized network adapter (virtio-net)" is special. If you select this, then VirtualBox does not virtualize common networking hardware (that is supported by common guest operating systems out of the box). Instead, VirtualBox then expects a special software interface for virtualized environments to be provided by the guest, thus avoiding the complexity of emulating networking hardware and improving network performance. Starting with version 3.1, VirtualBox provides support for the industry-standard "virtio" networking drivers, which are part of the open-source KVM project.

This indicates that this network driver will not work with all base images, and I would extrapolate from this that vagrant SHOULD NOT be specifying this as the default NIC type, but should continue to leave the default NIC type to the base box and/or the provider default as specified by the user.

Please consider rolling back the change to the default NIC type and let the base image specify this. It's not vagrant's concern!

[jborean93]

Just to add to this, all Windows boxes that don't currently specify the network adapter will fail with this reason. 2.2.0 works just fine but with 2.2.1 having the default of virtio means they no longer have a valid network adapter and Vagrant can't communicate with them. Looks like https://github.com/hashicorp/vagrant/commit/d8bbc5ce092c42570ece3da1ab720df318c9294e#diff-da3f6615ece95a9aaa47a5723de258b1R170 is when this change was made.

[nitzmahone]

@davidalger beat me to the same commit-spelunking forensics by 5h

[chrisroberts]

Hi all. Thanks for reporting this issue. I have a PR open updating the implementation of the default_nic_type option and will be pushing out a patch release specifically for this tomorrow.

[b-long]

Hi all, sorry for the noise if I'm wrong, but I'm wondering if the following issues are related:

• https://github.com/hashicorp/vagrant/issues/10444
• https://github.com/hashicorp/vagrant/issues/10437

Thanks for all the hard work 👍

[dtrac]

Hi all, sorry for the noise if I'm wrong, but I'm wondering if the following issues are related:

• #10444
• #10437

Thanks for all the hard work 👍

Hello - my issue (#10444) is on 2.2.0

Dan

[davidalger]

@chrisroberts Wow, thank you for jumping on this so quickly. You are a rock-star!

[chrisroberts]

Thanks for the patience and my apologies for the headache. I was very concerned about the usage of the E1000 NIC types and wanted to have Vagrant default to a non-vulnerable device type. However, that seems to not be realistically possible so the warning will have to suffice. The predictable interface naming bit me with the type change and the default available drivers on Windows as well.

Thanks again for the report.

Cheers!

[jborean93]

Can confirm 2.2.2 works with the defaults again, will be changing my box vagrant templates to use an explicit NIC but this gets me going. Thanks for the speedy turnaround.

[chrisroberts]

Just a note that the next vbox release will fix the issue, but I don't know if there will be another 5.2. release or if the next will just be 6.0.

[der-eismann]

I can also confirm that it's working fine, however I am a bit confused by the warning. The exploit page explicitly lists the 82540EM as the only vulnerable NIC type. But after your patch you are warning about every NIC that starts with 8254 and therefore includes the other Intel NICs. Are they also affected?

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.