This commit includes all detailed disk information from VirtualBox
inside its storage structure in Vagrant. This gives Vagrant more
detailed access for a disk beyond its uuid and port/device such as its
capacity and the type of disk it's classified as.
This commit updates how the virtualbox provider obtains `all_disks`.
Instead of using the `list_hdds` driver method, which lists al known
harddisks for an entire VirtualBox installation, it instead uses that
array of disks to filter out the proper disks associated with the guest,
given its existance inside the guests controller attachments.
SCSI controllers are a lot like SATA controllers. This commit also
changes some controller detection logic to take boot priority into
account when selecting an appropriate controller.
Move all storage bus logic into the storage controller class. Since most
of the storage controller interaction only cares about the storage
controller name, we can simplify #get_controller and isolate the storage
controller detection-type logic in the StorageControllerArray.
This commit adds a new error message to be raised if a VM has no
supported storage controllers. This lets us differentiate between two
different "controller not found" scenarios:
1. If we are looking for a controller that we're expecting to find (i.e.
one that was recorded in the disk metadata file)
2. If we are poking around for the *best* controller to use in a
configuration task
.configure_disks is responsible for determining the disk controller(s)
to use, given the machine configuration and the current disk config.
When a machine has a single controller, use it for all attachments.
When a machine has multiple controllers, attach disks to the SATA
controller and DVDs to the IDE controller.
This commit also returns additional attachment information
(controller/port/device) with the disk metadata.
This makes it easier to check if the required controller can be found,
and automatically raise an error if it is not.
Add a #storage_bus method to the StorageController class as a shorthand
way to check the general storage controller type.
This commit adds a new error type that can be raised whenever a storage
controller of the required type is not found. This indicates that a user
needs to either add the storage controller manually or change their disk
configuration.
It also removes the last hardcoded instance of "SATA Controller" as a
default argument.
This commit adds a new VirtualBox provider helper method to return a
list of storage controllers so Vagrant can find a storage controller
with the desired characteristics (type IDE or SATA).
This still needs to get wired up to the disk cleanup method.
This builds on the existing disk functionality, and adds some special
IDE controller-related flavor.
Considerations for IDE controllers:
- Primary/secondary attachments, so that each port can have two devices
attached
- Adding the ability to address a specific controller name for disk
attachment
This also prevents a user from attaching multiple instances of the same
ISO file, because VirtualBox will assign each of these the same UUID
which makes disconnection difficult. However, if multiple copies of the
ISO are attached to different devices, removing the DVD config will
cause the duplicate devices to be removed.
We may want to consider additional work to make the storage controllers
truly generic.
Prior to this commit, if a created but exited container bound a port,
and a new container grabed that same port (say for an ssh port forward),
when the initial container came back up it would fail because the port
also got bound to the second container. This commit fixes that behavior
by first looking at what containers are already bound prior to creating
a container.
If the VirtualBox guest property /VirtualBox/GuestInfo/Net/1/V4/IP
returns an IP address ending in .1, raise an error.
This addresses an issue that was revealed as an NFS error, where Vagrant
was creating an exports file with the wrong IP address. This was thought
to be caused by the presence of a docker0 interface, but it manifested
itself even without Docker installed.
This issue is difficult to reproduce, but hopefully this PR will get us
closer to the root cause.
When user is using podman's docker CLI emulation the containers would
fail to enter running state because the docker driver could not catch
the container name. This commit fixes that by adding a check if podman
docker emulation is used and pick the container hash correctly from the
output.
