vagrant-packet 0.1.2 → 0.1.3

data/vendor/bundle/ruby/2.4.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/vagrantfile/vagrant_version.html.md

@@ -1,33 +0,0 @@
----
-layout: "docs"
-page_title: "Minimum Vagrant Version - Vagrantfile"
-sidebar_current: "vagrantfile-minversion"
-description: |-
-  A set of Vagrant version requirements can be specified in the Vagrantfile
-  to enforce that people use a specific version of Vagrant with a Vagrantfile.
-  This can help with compatibility issues that may otherwise arise from using
-  a too old or too new Vagrant version with a Vagrantfile.
----
-
-# Minimum Vagrant Version
-
-A set of Vagrant version requirements can be specified in the Vagrantfile
-to enforce that people use a specific version of Vagrant with a Vagrantfile.
-This can help with compatibility issues that may otherwise arise from using
-a too old or too new Vagrant version with a Vagrantfile.
-
-Vagrant version requirements should be specified at the top of a Vagrantfile
-with the `Vagrant.require_version` helper:
-
-```ruby
-Vagrant.require_version ">= 1.3.5"
-```
-
-In the case above, the Vagrantfile will only load if the version loading it
-is Vagrant 1.3.5 or greater.
-
-Multiple requirements can be specified as well:
-
-```ruby
-Vagrant.require_version ">= 1.3.5", "< 1.4.0"
-```

data/vendor/bundle/ruby/2.4.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/vagrantfile/version.html.md

@@ -1,64 +0,0 @@
----
-layout: "docs"
-page_title: "Configuration Version - Vagrantfile"
-sidebar_current: "vagrantfile-version"
-description: |-
-  Configuration versions are the mechanism by which Vagrant 1.1+ is able to
-  remain backwards compatible with Vagrant 1.0.x Vagrantfiles, while introducing
-  dramatically new features and configuration options.
----
-
-# Configuration Version
-
-Configuration versions are the mechanism by which Vagrant 1.1+ is able
-to remain [backwards compatible](/docs/installation/backwards-compatibility.html)
-with Vagrant 1.0.x Vagrantfiles, while introducing dramatically new features
-and configuration options.
-
-If you run `vagrant init` today, the Vagrantfile will be in roughly the
-following format:
-
-```ruby
-Vagrant.configure("2") do |config|
-  # ...
-end
-```
-
-The `"2"` in the first line above represents the version of the configuration
-object `config` that will be used for configuration for that block (the
-section between the `do` and the `end`). This object can be very
-different from version to version.
-
-Currently, there are only two supported versions: "1" and "2". Version 1
-represents the configuration from Vagrant 1.0.x. "2" represents the configuration
-for 1.1+ leading up to 2.0.x.
-
-When loading Vagrantfiles, Vagrant uses the proper configuration object
-for each version, and properly merges them, just like any other configuration.
-
-The important thing to understand as a general user of Vagrant is that
-_within a single configuration section_, only a single version can be used.
-You cannot use the new `config.vm.provider` configurations in a version 1
-configuration section. Likewise, `config.vm.forward_port` will not work
-in a version 2 configuration section (it was renamed).
-
-If you want, you can mix and match multiple configuration versions in the
-same Vagrantfile. This is useful if you found some useful configuration
-snippet or something that you want to use. Example:
-
-```ruby
-Vagrant.configure("1") do |config|
-  # v1 configs...
-end
-
-Vagrant.configure("2") do |config|
-  # v2 configs...
-end
-```
-
-<div class="alert alert-info">
-  <strong>What is <code>Vagrant::Config.run</code>?</strong>
-  You may see this in Vagrantfiles. This was actually how Vagrant 1.0.x
-  did configuration. In Vagrant 1.1+, this is synonymous with
-  <code>Vagrant.configure("1")</code>.
-</div>

data/vendor/bundle/ruby/2.4.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/vagrantfile/winrm_settings.html.md

@@ -1,78 +0,0 @@
----
-layout: "docs"
-page_title: "config.winrm - Vagrantfile"
-sidebar_current: "vagrantfile-winrm"
-description: |-
-  The settings within "config.winrm" relate to configuring how Vagrant
-  will access your Windows guest over WinRM. As with most Vagrant settings, the
-  defaults are typically fine, but you can fine tune whatever you would like.
----
-
-# WinRM Settings
-
-**Config namespace: `config.winrm`**
-
-The settings within `config.winrm` relate to configuring how Vagrant
-will access your Windows guest over WinRM. As with most Vagrant settings, the
-defaults are typically fine, but you can fine tune whatever you would like.
-
-These settings are only used if you've set your communicator type to `:winrm`.
-
-## Available Settings
-
-`config.winrm.username` - This sets the username that Vagrant will use
-to login to the WinRM web service by default. Providers are free to override
-this if they detect a more appropriate user. By default this is "vagrant,"
-since that is what most public boxes are made as.
-
-<hr>
-
-`config.winrm.password` - This sets a password that Vagrant will use to
-authenticate the WinRM user. By default this is "vagrant," since that is
-what most public boxes are made as.
-
-<hr>
-
-`config.winrm.host` - The hostname or IP to connect to the WinRM service.
-By default this is empty, because the provider usually figures this out for
-you.
-
-<hr>
-
-`config.winrm.port` - The WinRM port to connect to, by default 5985.
-
-<hr>
-
-`config.winrm.guest_port` - The port on the guest that WinRM is running on.
-This is used by some providers to detect forwarded ports for WinRM. For
-example, if this is set to 5985 (the default), and Vagrant detects a forwarded
-port to port 5985 on the guest from port 4567 on the host, Vagrant will attempt
-to use port 4567 to talk to the guest if there is no other option.
-
-<hr>
-
-`config.winrm.transport` - The transport used for WinRM communication. Valid settings include: `:negotiate`, `:ssl`, and `:plaintext`. The default is `:negotiate`.
-
-<hr>
-
-`config.winrm.basic_auth_only` - Whether to use Basic Authentication. Defaults to `false`. If set to `true` you should also use the `:plaintext` transport setting and the Windows machine must be configured appropriately. <strong>Note:</strong> It is strongly recommended that you only use basic authentication for debugging purposes. Credentials will be transferred in plain text.
-
-<hr>
-
-`config.winrm.ssl_peer_verification` - When set to `false` ssl certificate validation is not performed.
-
-<hr>
-
-`config.winrm.timeout` - The maximum amount of time to wait for a response from the endpoint. This defaults to 60 seconds. Note that this will not "timeout" commands that exceed this amount of time to process, it just requires the endpoint to report the status of the command before the given amount of time passes.
-
-<hr>
-
-`config.winrm.retry_limit` - The maximum number of times to retry opening a shell after failure. This defaults to 3.
-
-<hr>
-
-`config.winrm.retry_delay` - The amount of time to wait between retries and defaults to 10 seconds.
-
-<hr>
-
-`config.winrm.codepage` - The WINRS_CODEPAGE which is the client's console output code page. The default is 65001 (UTF-8). <strong>Note:</strong> Versions of Windows older than Windows 7/Server 2008 R2 may exhibit undesirable behavior using the default UTF-8 codepage. When using these older versions of Windows, its best to use the native code page of the server's locale. For example, en-US servers will have a codepage of 437. The Windows `chcp` command can be used to determine the value of the native codepage.

data/vendor/bundle/ruby/2.4.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/vagrantfile/winssh_settings.html.md

@@ -1,168 +0,0 @@
----
-layout: "docs"
-page_title: "config.winssh - Vagrantfile"
-sidebar_current: "vagrantfile-winssh"
-description: |-
-  The settings within "config.winssh" relate to configuring how Vagrant
-  will access your machine over Windows OpenSSH. As with most Vagrant settings, the
-  defaults are typically fine, but you can fine tune whatever you would like.
----
-
-# WinSSH
-
-The WinSSH communicator is built specifically for the Windows native
-port of OpenSSH. It does not rely on a POSIX-like environment which
-removes the requirement of extra software installation (like cygwin)
-for proper functionality.
-
-_NOTE: The Windows native port of OpenSSH is still considered
-"pre-release" and is non-production ready._
-
-For more information, see the [Win32-OpenSSH project page](https://github.com/PowerShell/Win32-OpenSSH/).
-
-# WinSSH Settings
-
-The WinSSH communicator uses the same connection configuration options
-as the SSH communicator. These settings provide the information for the
-communicator to establish a connection to the VM.
-
-**Config namespace: `config.ssh`**
-
-The settings within `config.ssh` relate to configuring how Vagrant
-will access your machine over SSH. As with most Vagrant settings, the
-defaults are typically fine, but you can fine tune whatever you would like.
-
-## Available Settings
-
-`config.ssh.username` - This sets the username that Vagrant will SSH
-as by default. Providers are free to override this if they detect a more
-appropriate user. By default this is "vagrant," since that is what most
-public boxes are made as.
-
-<hr>
-
-`config.ssh.password` - This sets a password that Vagrant will use to
-authenticate the SSH user. Note that Vagrant recommends you use key-based
-authentication rather than a password (see `private_key_path`) below. If
-you use a password, Vagrant will automatically insert a keypair if
-`insert_key` is true.
-
-<hr>
-
-`config.ssh.host` - The hostname or IP to SSH into. By default this is
-empty, because the provider usually figures this out for you.
-
-<hr>
-
-`config.ssh.port` - The port to SSH into. By default this is port 22.
-
-<hr>
-
-`config.ssh.guest_port` - The port on the guest that SSH is running on. This
-is used by some providers to detect forwarded ports for SSH. For example, if
-this is set to 22 (the default), and Vagrant detects a forwarded port to
-port 22 on the guest from port 4567 on the host, Vagrant will attempt
-to use port 4567 to talk to the guest if there is no other option.
-
-<hr>
-
-`config.ssh.private_key_path` - The path to the private key to use to
-SSH into the guest machine. By default this is the insecure private key
-that ships with Vagrant, since that is what public boxes use. If you make
-your own custom box with a custom SSH key, this should point to that
-private key.
-
-You can also specify multiple private keys by setting this to be an array.
-This is useful, for example, if you use the default private key to bootstrap
-the machine, but replace it with perhaps a more secure key later.
-
-<hr>
-
-`config.ssh.insert_key` - If `true`, Vagrant will automatically insert
-a keypair to use for SSH, replacing Vagrant's default insecure key
-inside the machine if detected. By default, this is true.
-
-This only has an effect if you do not already use private keys for
-authentication or if you are relying on the default insecure key.
-If you do not have to care about security in your project and want to
-keep using the default insecure key, set this to `false`.
-
-<hr>
-
-`config.ssh.keys_only` - Only use Vagrant-provided SSH private keys (do not use
-any keys stored in ssh-agent). The default value is `true`.`
-
-<hr>
-
-`config.ssh.paranoid` - Perform strict host-key verification. The default value
-is `false`.
-
-# WinSSH Settings
-
-The configuration options below are specific to the WinSSH communicator.
-
-**Config namespace: `config.winssh`**
-
-## Available Settings
-
-`config.winssh.forward_agent` - If `true`, agent forwarding over SSH
-connections is enabled. Defaults to false.
-
-<hr>
-
-`config.winssh.forward_env` - An array of host environment variables to forward to
-the guest. If you are familiar with OpenSSH, this corresponds to the `SendEnv`
-parameter.
-
-```ruby
-config.winssh.forward_env = ["CUSTOM_VAR"]
-```
-
-<hr>
-
-`config.winssh.proxy_command` - A command-line command to execute that receives
-the data to send to SSH on stdin. This can be used to proxy the SSH connection.
-`%h` in the command is replaced with the host and `%p` is replaced with
-the port.
-
-<hr>
-
-`config.winssh.keep_alive` If `true`, this setting SSH will send keep-alive packets
-every 5 seconds by default to keep connections alive.
-
-<hr>
-
-`config.winssh.shell` - The shell to use when executing SSH commands from
-Vagrant. By default this is `cmd`. Valid values are `"cmd"` or `"powershell"`.
-Note that this has no effect on the shell you get when you run `vagrant ssh`.
-This configuration option only affects the shell to use when executing commands
-internally in Vagrant.
-
-<hr>
-
-`config.winssh.export_command_template` - The template used to generate
-exported environment variables in the active session. This can be useful
-when using a Bourne incompatible shell like C shell. The template supports
-two variables which are replaced with the desired environment variable key and
-environment variable value: `%ENV_KEY%` and `%ENV_VALUE%`. The default template
-for a `cmd` configured shell is:
-
-```ruby
-config.winssh.export_command_template = 'set %ENV_KEY%="%ENV_VALUE%"'
-```
-
-The default template for a `powershell` configured shell is:
-
-```ruby
-config.winssh.export_command_template = '$env:%ENV_KEY%="%ENV_VALUE%"'
-```
-
-`config.winssh.sudo_command` - The command to use when executing a command
-with `sudo`. This defaults to `%c` (assumes vagrant user is an administrator
-and needs no escalation). The `%c` will be replaced by the command that is
-being executed.
-
-<hr>
-
-`config.winssh.upload_directory` - The upload directory used on the guest
-to store scripts for execute. This is set to `C:\Windows\Temp` by default.

data/vendor/bundle/ruby/2.4.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/virtualbox/boxes.html.md

@@ -1,165 +0,0 @@
----
-layout: "docs"
-page_title: "Creating a Base Box - VirtualBox Provider"
-sidebar_current: "providers-virtualbox-boxes"
-description: |-
-  As with every Vagrant provider, the Vagrant VirtualBox provider has a custom
-  box format that affects how base boxes are made.
----
-
-# Creating a Base Box
-
-As with [every Vagrant provider](/docs/providers/basic_usage.html), the
-Vagrant VirtualBox provider has a custom box format that affects how base
-boxes are made.
-
-Prior to reading this, you should read the
-[general guide to creating base boxes](/docs/boxes/base.html). Actually,
-it would probably be most useful to keep this open in a separate tab
-as you may be referencing it frequently while creating a base box. That
-page contains important information about common software to install
-on the box.
-
-Additionally, it is helpful to understand the
-[basics of the box file format](/docs/boxes/format.html).
-
-<div class="alert alert-warning">
-  <strong>Advanced topic!</strong> This is a reasonably advanced topic that
-  a beginning user of Vagrant does not need to understand. If you are
-  just getting started with Vagrant, skip this and use an available
-  box. If you are an experienced user of Vagrant and want to create
-  your own custom boxes, this is for you.
-</div>
-
-## Virtual Machine
-
-The virtual machine created in VirtualBox can use any configuration you would
-like, but Vagrant has some hard requirements:
-
-  * The first network interface (adapter 1) _must_ be a NAT adapter.
-    Vagrant uses this to connect the first time.
-
-  * The MAC address of the first network interface (the NAT adapter)
-    should be noted, since you will need to put it in a Vagrantfile
-    later as the value for `config.vm.base_mac`. To get this value, use
-    the VirtualBox GUI.
-
-Other than the above, you are free to customize the base virtual machine
-as you see fit.
-
-## Additional Software
-
-In addition to the software that should be installed based on the
-[general guide to creating base boxes](/docs/boxes/base.html),
-VirtualBox base boxes require some additional software.
-
-### VirtualBox Guest Additions
-
-[VirtualBox Guest Additions](https://www.virtualbox.org/manual/ch04.html)
-must be installed so that things such as shared folders can function.
-Installing guest additions also usually improves performance since the guest
-OS can make some optimizations by knowing it is running within VirtualBox.
-
-Before installing the guest additions, you will need the linux kernel headers
-and the basic developer tools. On Ubuntu, you can easily install these like
-so:
-
-```
-$ sudo apt-get install linux-headers-$(uname -r) build-essential dkms
-```
-
-#### To install via the GUI:
-
-Next, make sure that the guest additions image is available by using the
-GUI and clicking on "Devices" followed by "Install Guest Additions".
-Then mount the CD-ROM to some location. On Ubuntu, this usually looks like
-this:
-
-```
-$ sudo mount /dev/cdrom /media/cdrom
-```
-
-Finally, run the shell script that matches your system to install the
-guest additions. For example, for Linux on x86, it is the following:
-
-```
-$ sudo sh /media/cdrom/VBoxLinuxAdditions.run
-```
-
-If the command succeeds, then the guest additions are now installed!
-
-#### To install via the command line:
-
-You can find the appropriate guest additions version to match your VirtualBox
-version by selecting the appropriate version
-[here](http://download.virtualbox.org/virtualbox/). The examples below use
-4.3.8, which was the latest VirtualBox version at the time of writing.
-
-```
-wget http://download.virtualbox.org/virtualbox/4.3.8/VBoxGuestAdditions_4.3.8.iso
-sudo mkdir /media/VBoxGuestAdditions
-sudo mount -o loop,ro VBoxGuestAdditions_4.3.8.iso /media/VBoxGuestAdditions
-sudo sh /media/VBoxGuestAdditions/VBoxLinuxAdditions.run
-rm VBoxGuestAdditions_4.3.8.iso
-sudo umount /media/VBoxGuestAdditions
-sudo rmdir /media/VBoxGuestAdditions
-```
-
-If you did not install a Desktop environment when you installed the operating
-system, as recommended to reduce size, the install of the VirtualBox additions
-should warn you about the lack of OpenGL or Window System Drivers, but you can
-safely ignore this.
-
-If the commands succeed, then the guest additions are now installed!
-
-## Packaging the Box
-
-Vagrant includes a simple way to package VirtualBox base boxes. Once you've
-installed all the software you want to install, you can run this command:
-
-```
-$ vagrant package --base my-virtual-machine
-```
-
-Where "my-virtual-machine" is replaced by the name of the virtual machine
-in VirtualBox to package as a base box.
-
-It will take a few minutes, but after it is complete, a file "package.box"
-should be in your working directory which is the new base box. At this
-point, you've successfully created a base box!
-
-## Raw Contents
-
-This section documents the actual raw contents of the box file. This is not
-as useful when creating a base box but can be useful in debugging issues
-if necessary.
-
-A VirtualBox base box is an archive of the resulting files of
-[exporting](https://www.virtualbox.org/manual/ch08.html#vboxmanage-export)
-a VirtualBox virtual machine. Here is an example of what is contained
-in such a box:
-
-```
-$ tree
-.
-|-- Vagrantfile
-|-- box-disk1.vmdk
-|-- box.ovf
-|-- metadata.json
-
-0 directories, 4 files
-```
-
-In addition to the files from exporting a VirtualBox VM, there is
-the "metadata.json" file used by Vagrant itself.
-
-Also, there is a "Vagrantfile." This contains some configuration to
-properly set the MAC address of the NAT network device, since VirtualBox
-requires this to be correct in order to function properly. If you are
-not using `vagrant package --base` above, you will have to set the
-`config.vm.base_mac` setting in this Vagrantfile to the MAC address
-of the NAT device without colons.
-
-When bringing up a VirtualBox backed machine, Vagrant
-[imports](https://www.virtualbox.org/manual/ch08.html#vboxmanage-import)
-the "box.ovf" file found in the box contents.

data/vendor/bundle/ruby/2.4.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/virtualbox/common-issues.html.md

@@ -1,33 +0,0 @@
----
-layout: "docs"
-page_title: "Common Issues - VirtualBox Provider"
-sidebar_current: "providers-virtualbox-issues"
-description: |-
-  This page lists some common issues people run into with Vagrant and VirtualBox
-  as well as solutions for those issues.
----
-
-# Common Issues
-
-This page lists some common issues people run into with Vagrant and VirtualBox
-as well as solutions for those issues.
-
-## Hanging on Windows
-
-If Vagrant commands are hanging on Windows because they're communicating
-to VirtualBox, this may be caused by a permissions issue with VirtualBox.
-This is easy to fix. Starting VirtualBox as a normal user or as an
-administrator will prevent you from using it in the opposite way. Please keep
-in mind that when Vagrant interacts with VirtualBox, it will interact with
-it with the same access level as the console running Vagrant.
-
-To fix this issue, completely shut down all VirtualBox machines and GUIs.
-Wait a few seconds. Then, launch VirtualBox only with the access level you
-wish to use.
-
-## DNS Not Working
-
-If DNS is not working within your VM, then you may need to enable
-a DNS proxy (built-in to VirtualBox). Please [see the StackOverflow answers
-here](https://serverfault.com/questions/453185/vagrant-virtualbox-dns-10-0-2-3-not-working)
-for a guide on how to do that.

data/vendor/bundle/ruby/2.4.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/virtualbox/configuration.html.md

@@ -1,112 +0,0 @@
----
-layout: "docs"
-page_title: "Configuration - VirtualBox Provider"
-sidebar_current: "providers-virtualbox-configuration"
-description: |-
-  The VirtualBox provider exposes some additional configuration options
-  that allow you to more finely control your VirtualBox-powered Vagrant
-  environments.
----
-
-# Configuration
-
-The VirtualBox provider exposes some additional configuration options
-that allow you to more finely control your VirtualBox-powered Vagrant
-environments.
-
-## GUI vs. Headless
-
-By default, VirtualBox machines are started in headless mode, meaning
-there is no UI for the machines visible on the host machine. Sometimes,
-you want to have a UI. Common use cases include wanting to see a browser
-that may be running in the machine, or debugging a strange boot issue.
-You can easily tell the VirtualBox provider to boot with a GUI:
-
-```
-config.vm.provider "virtualbox" do |v|
-  v.gui = true
-end
-```
-
-## Virtual Machine Name
-
-You can customize the name that appears in the VirtualBox GUI by
-setting the `name` property. By default, Vagrant sets it to the containing
-folder of the Vagrantfile plus a timestamp of when the machine was created.
-By setting another name, your VM can be more easily identified.
-
-```ruby
-config.vm.provider "virtualbox" do |v|
-  v.name = "my_vm"
-end
-```
-
-## Linked Clones
-
-By default new machines are created by importing the base box. For large
-boxes this produces a large overhead in terms of time (the import operation)
-and space (the new machine contains a copy of the base box's image).
-Using linked clones can drastically reduce this overhead.
-
-Linked clones are based on a master VM, which is generated by importing the
-base box only once the first time it is required. For the linked clones only
-differencing disk images are created where the parent disk image belongs to
-the master VM.
-
-```ruby
-config.vm.provider "virtualbox" do |v|
-  v.linked_clone = true
-end
-```
-
-To have backward compatibility:
-
-```ruby
-config.vm.provider 'virtualbox' do |v|
-  v.linked_clone = true if Gem::Version.new(Vagrant::VERSION) >= Gem::Version.new('1.8.0')
-end
-```
-
-If you do not want backward compatibility and want to force users to
-support linked cloning, you can use `Vagrant.require_version` with 1.8.
-
-<div class="alert alert-info">
-  <strong>Note:</strong> the generated master VMs are currently not removed
-  automatically by Vagrant. This has to be done manually. However, a master
-  VM can only be removed when there are no linked clones connected to it.
-</div>
-
-## VBoxManage Customizations
-
-[VBoxManage](https://www.virtualbox.org/manual/ch08.html) is a utility that can
-be used to make modifications to VirtualBox virtual machines from the command
-line.
-
-Vagrant exposes a way to call any command against VBoxManage just prior
-to booting the machine:
-
-```ruby
-config.vm.provider "virtualbox" do |v|
-  v.customize ["modifyvm", :id, "--cpuexecutioncap", "50"]
-end
-```
-
-In the example above, the VM is modified to have a host CPU execution
-cap of 50%, meaning that no matter how much CPU is used in the VM, no
-more than 50% would be used on your own host machine. Some details:
-
-* The `:id` special parameter is replaced with the ID of the virtual
-  machine being created, so when a VBoxManage command requires an ID, you
-  can pass this special parameter.
-
-* Multiple `customize` directives can be used. They will be executed in the
-  order given.
-
-There are some convenience shortcuts for memory and CPU settings:
-
-```ruby
-config.vm.provider "virtualbox" do |v|
-  v.memory = 1024
-  v.cpus = 2
-end
-```

data/vendor/bundle/ruby/2.4.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/virtualbox/index.html.md

@@ -1,26 +0,0 @@
----
-layout: "docs"
-page_title: "VirtualBox Provider"
-sidebar_current: "providers-virtualbox"
-description: |-
-  Vagrant comes with support out of the box for VirtualBox, a free,
-  cross-platform consumer virtualization product.
----
-
-# VirtualBox
-
-Vagrant comes with support out of the box for [VirtualBox](https://www.virtualbox.org),
-a free, cross-platform consumer virtualization product.
-
-The VirtualBox provider is compatible with VirtualBox versions 4.0.x, 4.1.x,
-4.2.x, 4.3.x, 5.0.x, 5.1.x, and 5.2.x. Other versions are unsupported and the provider
-will display an error message. Please note that beta and pre-release versions
-of VirtualBox are not supported and may not be well-behaved.
-
-VirtualBox must be installed on its own prior to using the provider, or
-the provider will display an error message asking you to install it.
-VirtualBox can be installed by [downloading](https://www.virtualbox.org/wiki/Downloads)
-a package or installer for your operating system and using standard procedures
-to install that package.
-
-Use the navigation to the left to find a specific VirtualBox topic to read more about.