This occurs with a Linux host when a link-local address is configured
for vboxnet0 (which is the default for VirtualBox 5.2.6).
`connect': Invalid argument - connect(2) for "fe80::ffff:ffff:ffff:ffff" port 80 (Errno::EINVAL)
Prior to this commit, the incorrect path was used when determining where
to export an ovf file during the `vagrant package` step. This commit
updates that by checking if vagrant is within WSL, and if so, convert
the path to a proper windows path to be used during the export.
Fixes#9059
Prior to this commit, the hyper-v and virtualbox system crash check
existed within the initialize function of the virtualbox provider. That
caused an issue when running with other providers, because the
virtualbox provider still gets initialized even if not used. This commit
changes that by placing the check inside of one of the virtualbox
provider actions that checks if virtualbox is installed and ready to
use. This action is action is used by the main vbox provider actions,
and should not be called when other providers are being used with
Vagrant.
This commit adds a function on windows for the VirtualBox provider to
check if Hyper-V is enabled. If so, exit and display a warning to the
user that going forward will result in a system crash.
Display warning to user about the VirtualBox SharedFoldersEnableSymlinksCreate
option with link to VirtualBox documentation and instructions on how the
setting can be disabled.
Prior to this commit, the virtualbox synced folder option
`SharedFoldersEnableSymlinksCreate` was always enabled. This commit
introduces a config option and an environment variable which allows
users to configure the option globally or per synced_folder in their
Vagrantfile.
It should be valid to allow paths with spaces for the synced folder
guest path but since the guest path is used to generate the ID (if one
isn't provided), this will err out in VirtualBox because it doesn't
allow spaces for the --name argument. We should simply convert ' ' to
'_' as we do with other special characters.
Reverting the changes done in 7d2f7dab97
because they don't work and or update vagrant to invoke running the
vbox cli tool for every single forwarded port instead of forwarding them
all in one command.
Issue: https://github.com/mitchellh/vagrant/issues/8468
A lot of vboxmanage commands are flakey and frequently cause
bringing multiple machines up at once to fail, especially when
the host system is under heavy load. Most commands are also safe
to retry and just result in a no-op, so we can simply add
'retryable' to a lot of existing calls. For the others we need to
do a little bit of cleanup or reevaluate the parameters before
trying again.
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.
This commit adds some better handling around the snapshot restore and
delete commands for the virtualbox provider. If a user attempts to restore from
a vm that does not exist, instead of exiting 0 it will raise an
exception saying the virtual machine has not been created yet.
Addtionally, if a user attempts to restore from a snapshot id that does
not exist, instead of printing a complicated exception from the
virtualbox cli tool, it prints a more useful error message telling the
user that the snapshot does not exist.
Enables proper setup of VMs started from within WSL rootfs paths. Updates
setup for Windows access when working within the WSL to auto-detect settings
instead of relying on user defined environment variables.
We know that the vm does not exist if we get VBOX_E_OBJECT_NOT_FOUND.
For any other error, this may well be VirtualBox getting confused and it is probably
worth retrying...
This commit basically grepped the code base for all uses of Dir.mktmpdir
and Tempfile.new/open and ensures the value is unique within the
code base and also prefixed with `vagrant-`.
Previously, most invocations of these commands simply used "vagrant",
thus making them indistinguishable when trying to identify leaks.
Previously, there was no one gesture that would start a VM if it was not
running and run the appropriate provisioners regardless of its original
state. `vagrant up` did nothing if the VM was running, while
`vagrant provision` did nothing if the VM was not running.
Change the semantics of `vagrant up`, via the start actions of the providers,
to go through the provisioning logic even if the VM is already running.
The semantics of `run: "once"` vs `run: "always"` are respected.
Tested with the VirtualBox provider but not the others.
Resolves#4421
Brian Cain
Chris Roberts
Cédric Félizard
Stefan Scherer
Josh Soref
eyJhb
Zachary Flower
Erik Lattimore
Jehiah Czebotar
Samuel Clark
nico.vanelslande
Chris Roberts
Richard Gareau
Mikhail Zholobov
Chris Roberts
Björn Brala
Indrek Ardel
Seth Vargo
David O'Rourke
Ray Ruvinskiy