It was failing to create files below the machines\default\hyperv folder, rather it was creating folders named 'hypervSnapshots', 'hypervVirtual Hard Disks', and 'hypervVirtual Machines'. This was causing the files to not be removed when destroying the vm, and an error when subsequently bringing it up again.
Implemented the differencing disk for vmcx.
This means the disk is now copied by Hyper-V (Powershell) instead of Ruby for new machines.
This does mean EFI Firmware now does work for machines since it is quite a feep copy. Compare-VM will report incompatibilities should they be found.
Use the version of Hyper-V instead of Powershell to determine which
exception is thrown by Get-VM. Also fixing an invalid catch statement,
since Powershell can not use variables to match thrown exceptions in
catch.
This adds a new core command, `docker-exec`, which allows the user to
exec into an already-running container.
- Fixes#6566
- Fixes#5193
- Fixes#4904
- Fixes#4057
- Fixes#4179
- Fixes#4903
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 changes the way ports are aggregated in the Docker provider.
Previously ports were aggregated by their "number", but that is not a
truly unique representation. Instead, the protocol is now taken into
account when generating the port map.
Fixes GH-5527
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