The "destroy_on_error" functionality for `vagrant up` is implemented in
the `recover()` action chain, and works by firing off a destroy action
from inside that chain.
This is all well and good, but it copies its existing `env` which has
had `action_name` set for the up action. This was causing action_hooks
for up actions to attach to this destroy action stack.
Setting the action_name explicitly in the env before firing the runner
should correct the behavior. I'm not sure if raw_action_name is used
anywhere but I figured it was better to be consistent vs conservative in
what we change.
VirtualBox introduced a restriction on the valid range for hostonly
networks. When using a version of VirtualBox which includes this
restriction a check is performed on the defined IP address to validate
it is within either the default range (as defined in the VirtualBox
documentation) or the values defined in the network configuration
file.
This includes updates for resolving all warnings provided by Ruby
for deprecations and/or removed methods. It also enables support
for Ruby 2.7 in the specification constraint as all 2.7 related
warnings are resolved with this changeset.
This commit catches the Errno::EPERM raised by the operating system if
the machine folder is inaccessible and displays it as a more friendly
error message.
This can be an issue on macOS Catalina if virtual machine files are kept
in a special directory (Documents/Downloads/Desktop) that Vagrant's
embedded Ruby is not allowed to access.
In some cases the E1000 NIC type is the only acceptable value. Since
defaulting causes breakages to existing boxes, leave the default value
as `nil` but check the VirtualBox version in use and print warning to
user if VirtualBox version is vulnerable and E1000 NIC types are
configured for use within defined network adapters.
When preparing the NFS settings on VirtualBox the guest IP addresses
are pulled from VirtualBox directly and any static addresses are
pulled as well. This can lead to aquiring a host IP and machine IP
but results in a failure of NFS mount because the IPs are not on
the same network. This filters the machine IP result to validate
it is within the host adapter IP range.
Set the IPv6 adapter IP to be <prefix>::1. Otherwise, guest to host
communication over IPv6 is not routed correctly. This means that
consumers should not specify <prefix>::1 IP addresses to VirtualBox,
which should be a reasonable restriction.
Fixes#6658
Vagrant should only consider the host-only interfaces used by the
virtual machine in the IPv6 fixup code. There may be other interfaces
present on the system with IPv6 addresses that for various reasons
would fail the routing check (for example, an interface with no
machines attached).
The patch changes the behavior to not scan all of the host-only
interfaces and adds a unit test for the behavior (that the correct IP
is validated).
Lastly, there is a small fix here that may not be an issue for most
people where the IPv6 prefix was asummed to be a multiple of 16 for
the purposes of constructing the UDP probe datagram. This assumption
has been removed.
Fixes#6586
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.
test-only change
when rsync is not installed on the machine running the unit tests, the
prepare_nfs_settings tests end up calling the :nfs_installed capability
on the host, which fails on the fake host wired up in tests.
this adds some explicit stubbing to prevent the implicit assumption that
rsync is installed.
Since vbox guest properties are proving to be less reliable than we had
hoped, bring back the static config parsing mechanism for finding a
guest IP to hand to NFS. If we find a static IP (or set of IPs) we'll
use that instead of trying to probe guest properties.
This retains NFS support for DHCP interfaces while regaining the
reliability that we previously had when static IPs were required.
Previously, we required a host-only interface with a static IP for NFS
to work in VirtualBox, because we needed access to the guest's IP in
order to properly configure mount commands.
After boot, VirtualBox exposes the IP addresses of a guest's network
adapters via the "guestproperty" interface.
This adds support for reading VirtualBox guest properties to the
VirtualBox driver and utilizes that support to prepare NFS settings,
which removes the necessity for a static IP for NFS to work.
In this commit we also start building out scaffolding for unit testing
vbox actions and drivers.
Test plan:
- Prepare a Vagrantfile with the following:
* private network with type: :dhcp
* synced folder with nfs: true
- Boot a VM from this Vagrantfile using the virtualbox provider
- Machine should boot successfully with working synced folder
