This commit updates how Vagrant manages disk state with the virtualbox
provider. Instead of using the raw structure from `list_hdds` for
all_disks, it instead uses that data that now lives inside the
controllers attachment structure.
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.
This commit adds a unique error message for an empty box value. It
requires modifications to vagrantfile.rb because some Vagrantfile config
is used before validation occurs.
This fixes an issue where having a box name set to an empty string will
cause all Vagrant commands to fail with an error like:
ArgumentError: Malformed version number string (random box name)
This may be related to #10663.
- removed superfluous cap/shell_expand_guest_path
- solaris11 guest_capability for shell_expand_guest_path now directly returns the linux capability class
Use subject instead of invalid_subject because the validation assertions
test the subject double.
This also adds an additional check when validating the `size` attribute
because it is only required for disks of type `:disk`.
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
This preserves the existing behavior of the method but changes the
implementation to use #read_storage_controllers. The caps that call a
mix of #get_port_and_device and #read_storage_controllers may be a
candidate for further refactoring, but this makes sure that we're
fetching storage attachments consistently.
.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.
