beckermj/vaguerent
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #13048 from hashicorp/docs/amb.migrate-link-formats

Browse Source 
docs: Migrate link formats
This commit is contained in:
Ashlee M Boyer 2023-01-20 17:28:59 -05:00 committed by GitHub
commit 24a830aff0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
122 changed files with 328 additions and 295 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
.github/workflows/check-legacy-links-format.yml vendored Normal file
View File

@ -0,0 +1,17 @@
name: Legacy Link Format Checker
on:
push:
paths:
- 'website/content/**/*.mdx'
- 'website/data/*-nav-data.json'
jobs:
check-links:
uses: hashicorp/dev-portal/.github/workflows/docs-content-check-legacy-links-format.yml@d7c2fceac2dc41e3f857f1ce7c344141fd6a13dd
with:
repo-owner: 'hashicorp'
repo-name: 'vagrant'
commit-sha: ${{ github.sha }}
mdx-directory: 'website/content'
nav-data-directory: 'website/data'

16
.github/workflows/test-link-rewrites.yml vendored Normal file
View File

@ -0,0 +1,16 @@
name: Test Link Rewrites
on: [deployment_status]
jobs:
test-link-rewrites:
if: github.event.deployment_status.state == 'success'
uses: hashicorp/dev-portal/.github/workflows/docs-content-link-rewrites-e2e.yml@2aceb60125f6c15f4c8dbe2e4d79148047bfa437
with:
repo-owner: 'hashicorp'
repo-name: 'vagrant'
commit-sha: ${{ github.sha }}
main-branch-preview-url: 'https://vagrant-git-main-hashicorp.vercel.app/'
# Workflow is only intended to run for one single migration PR
# This variable does not need to be updated
pr-branch-preview-url: 'https://vagrant-git-docs-ambmigrate-link-formats-hashicorp.vercel.app/'

16
website/content/docs/boxes/base.mdx
View File

@ -40,7 +40,7 @@ following:
- SSH user so Vagrant can connect
- Perhaps Chef, Puppet, etc. but not strictly required.
In addition to this, each [provider](/docs/providers/) may require
In addition to this, each [provider](/vagrant/docs/providers/) may require
additional software. For example, if you are making a base box for VirtualBox,
you will want to include the VirtualBox guest additions so that shared folders
work properly. But if you are making an AWS base box, this is not required.
@ -58,16 +58,16 @@ boxes.
Provider-specific guides for creating base boxes are linked below:
- [Docker Base Boxes](/docs/providers/docker/boxes)
- [Hyper-V Base Boxes](/docs/providers/hyperv/boxes)
- [VMware Base Boxes](/docs/providers/vmware/boxes)
- [VirtualBox Base Boxes](/docs/providers/virtualbox/boxes)
- [Docker Base Boxes](/vagrant/docs/providers/docker/boxes)
- [Hyper-V Base Boxes](/vagrant/docs/providers/hyperv/boxes)
- [VMware Base Boxes](/vagrant/docs/providers/vmware/boxes)
- [VirtualBox Base Boxes](/vagrant/docs/providers/virtualbox/boxes)
### Packer and Vagrant Cloud
We strongly recommend using [Packer](https://www.packer.io) to create reproducible
We strongly recommend using [Packer](https://www.packer.io/) to create reproducible
builds for your base boxes, as well as automating the builds. Read more about
[automating Vagrant box creation with Packer](https://www.packer.io/guides/packer-on-cicd/build-image-in-cicd)
[automating Vagrant box creation with Packer](/packer/guides/packer-on-cicd/build-image-in-cicd)
in the Packer documentation.
### Disk Space
@ -282,7 +282,7 @@ provider-specific guides are linked to towards the top of this page.
You can distribute the box file however you would like. However, if you want
to support versioning, putting multiple providers at a single URL, pushing
updates, analytics, and more, we recommend you add the box to
[HashiCorp's Vagrant Cloud](/vagrant-cloud).
[HashiCorp's Vagrant Cloud](/vagrant/vagrant-cloud).
You can upload both public and private boxes to this service.

12
website/content/docs/boxes/format.mdx
View File

@ -10,7 +10,7 @@ description: |-
In the past, boxes were just [tar files](<https://en.wikipedia.org/wiki/Tar_(computing)>)
of VirtualBox exports. With Vagrant supporting multiple
[providers](/docs/providers/) and [versioning](/docs/boxes/versioning)
[providers](/vagrant/docs/providers/) and [versioning](/vagrant/docs/boxes/versioning)
now, box files are slightly more complicated.
Box files made for Vagrant 1.0.x (the VirtualBox export `tar` files) continue
@ -26,7 +26,7 @@ Today, there are three different components:
box file and so on.
- Box Catalog Metadata - This is a JSON document (typically exchanged
during interactions with [HashiCorp's Vagrant Cloud](/vagrant-cloud))
during interactions with [HashiCorp's Vagrant Cloud](/vagrant/vagrant-cloud))
that specifies the name of the box, a description, available
versions, available providers, and URLs to the actual box files
(next component) for each provider and version. If this catalog
@ -35,7 +35,7 @@ Today, there are three different components:
- Box Information - This is a JSON document that can provide additional
information about the box that displays when a user runs
`vagrant box list -i`. More information is provided [here](/docs/boxes/info).
`vagrant box list -i`. More information is provided [here](/vagrant/docs/boxes/info).
The first two components are covered in more detail below.
@ -47,7 +47,7 @@ are supported for legacy reasons in Vagrant.
Box files are compressed using `tar`, `tar.gz`, or `zip`. The contents of the
archive can be anything, and is specific to each
[provider](/docs/providers/). Vagrant core itself only unpacks
[provider](/vagrant/docs/providers/). Vagrant core itself only unpacks
the boxes for use later.
Within the archive, Vagrant does expect a single file:
@ -80,11 +80,11 @@ file.
## Box Metadata
The metadata is an optional component for a box (but highly recommended)
that enables [versioning](/docs/boxes/versioning), updating, multiple
that enables [versioning](/vagrant/docs/boxes/versioning), updating, multiple
providers from a single file, and more.
-> **You do not need to manually make the metadata.** If you
have an account with [HashiCorp's Vagrant Cloud](/vagrant-cloud), you
have an account with [HashiCorp's Vagrant Cloud](/vagrant/vagrant-cloud), you
can create boxes there, and HashiCorp's Vagrant Cloud automatically creates
the metadata for you. The format is still documented here.

12
website/content/docs/boxes/index.mdx
View File

@ -9,16 +9,16 @@ description: |-
# Vagrant boxes
Boxes are the package format for Vagrant environments. You specify a box environment and operating configurations in your [Vagrantfile](/docs/vagrantfile). You can use a box on any [supported platform](https://www.vagrantup.com/downloads) to bring up identical working environments. To enable teams to use and manage the same boxes, [versions are supported](/docs/boxes/versioning).
Boxes are the package format for Vagrant environments. You specify a box environment and operating configurations in your [Vagrantfile](/vagrant/docs/vagrantfile). You can use a box on any [supported platform](/vagrant/downloads) to bring up identical working environments. To enable teams to use and manage the same boxes, [versions are supported](/vagrant/docs/boxes/versioning).
~> **Note**: Boxes require a provider, a virtualization product, to operate. Before you can use a box,
ensure that you have properly installed a supported [provider](/docs/providers).
ensure that you have properly installed a supported [provider](/vagrant/docs/providers).
The quickest way to get started is to select a pre-defined box environment from the
[publicly available catalog on Vagrant Cloud](https://vagrantcloud.com/boxes/search).
You can also add and share your own customized boxes on Vagrant Cloud.
The `vagrant box` CLI utility provides all the functionality for box management. You can read the documentation on the [vagrant box](/docs/cli/box)
The `vagrant box` CLI utility provides all the functionality for box management. You can read the documentation on the [vagrant box](/vagrant/docs/cli/box)
command for more information.
## Discover boxes
@ -30,7 +30,7 @@ systems as bases, as well as specialized boxes to get you started with common
configurations such as LAMP stacks, Ruby, and Python.
The boxes on the public catalog work with many different
[providers](/docs/providers/). The list of supported providers is located in the box descriptions.
[providers](/vagrant/docs/providers/). The list of supported providers is located in the box descriptions.
### Add a box
@ -72,7 +72,7 @@ It is often a point of confusion but Canonical, the company that makes the Ubunt
## Create a box
If you are unable to find a box that meets your specific use case, you can create one. We recommend that you first create a [base box](/docs/boxes/base) to have a clean slate to start from when you build future development environments.
If you are unable to find a box that meets your specific use case, you can create one. We recommend that you first create a [base box](/vagrant/docs/boxes/base) to have a clean slate to start from when you build future development environments.
Learn more about [box formats](/docs/boxes/format) to get started.
Learn more about [box formats](/vagrant/docs/boxes/format) to get started.

4
website/content/docs/boxes/info.mdx
View File

@ -23,7 +23,7 @@ hashicorp/bionic64 (virtualbox, 1.0.0)
## Box Info
To accomplish this, you simply need to include a file named `info.json` when
creating a [base box](/docs/boxes/base) which is a JSON document containing
creating a [base box](/vagrant/docs/boxes/base) which is a JSON document containing
any and all relevant information that will be displayed to the user when the
`-i` option is used with `vagrant box list`.
@ -37,5 +37,5 @@ any and all relevant information that will be displayed to the user when the
There are no special keys or values in `info.json`, and Vagrant will print each
key and value on its own line.
The [Box File Format](/docs/boxes/format) provides more information about what
The [Box File Format](/vagrant/docs/boxes/format) provides more information about what
else goes into a Vagrant box.

8
website/content/docs/boxes/versioning.mdx
View File

@ -23,13 +23,13 @@ to Vagrant makes it easy to use and fit nicely into the Vagrant workflow.
This page will cover how to use versioned boxes. It does _not_ cover how
to update your own custom boxes with versions. That is covered in
[creating a base box](/docs/boxes/base).
[creating a base box](/vagrant/docs/boxes/base).
## Viewing Versions and Updating
`vagrant box list` only shows _installed_ versions of boxes. If you want
to see all available versions of a box, you will have to find the box
on [HashiCorp's Vagrant Cloud](/vagrant-cloud). An easy way to find a box
on [HashiCorp's Vagrant Cloud](/vagrant/vagrant-cloud). An easy way to find a box
is to use the url `https://vagrantcloud.com/$USER/$BOX`. For example, for
the `hashicorp/bionic64` box, you can find information about it at
`https://vagrantcloud.com/hashicorp/bionic64`.
@ -47,7 +47,7 @@ command just downloads these updates locally.
## Version Constraints
You can constrain a Vagrant environment to a specific version or versions
of a box using the [Vagrantfile](/docs/vagrantfile/) by specifying
of a box using the [Vagrantfile](/vagrant/docs/vagrantfile/) by specifying
the `config.vm.box_version` option.
If this option is not specified, the latest version is always used. This is
@ -76,7 +76,7 @@ of the format `X.Y.Z` where `X`, `Y`, and `Z` are all positive integers.
## Automatic Update Checking
Using the [Vagrantfile](/docs/vagrantfile/), you can also configure
Using the [Vagrantfile](/vagrant/docs/vagrantfile/), you can also configure
Vagrant to automatically check for updates during any `vagrant up`. This is
enabled by default, but can easily be disabled with
`config.vm.box_check_update = false` in your Vagrantfile.

2
website/content/docs/cli/box.mdx
View File

@ -11,7 +11,7 @@ description: |-
**Command: `vagrant box`**
This is the command used to manage (add, remove, etc.) [boxes](/docs/boxes).
This is the command used to manage (add, remove, etc.) [boxes](/vagrant/docs/boxes).
The main functionality of this command is exposed via even more subcommands:

6
website/content/docs/cli/cloud.mdx
View File

@ -36,7 +36,7 @@ Vagrant Cloud.
**Command: `vagrant cloud auth login`**
The login command is used to authenticate with [HashiCorp's Vagrant Cloud](/vagrant-cloud)
The login command is used to authenticate with [HashiCorp's Vagrant Cloud](/vagrant/vagrant-cloud)
server. Logging in is only necessary if you are accessing protected boxes.
**Logging in is not a requirement to use Vagrant.** The vast majority
@ -171,7 +171,7 @@ The provider create command is used to create a new provider entry on Vagrant Cl
The `url` argument is expected to be a remote URL that Vagrant Cloud can use
to download the provider. If no `url` is specified, the provider entry can be updated
later with a url or the [upload](#cloud-provider-upload) command can be used to
upload a Vagrant [box file](/docs/boxes).
upload a Vagrant [box file](/vagrant/docs/boxes).
## Cloud Provider Delete
@ -191,7 +191,7 @@ Vagrant Cloud with the given options.
**Command: `vagrant cloud provider upload ORGANIZATION/BOX-NAME PROVIDER-NAME VERSION BOX-FILE`**
The provider upload command will upload a Vagrant [box file](/docs/boxes) to Vagrant Cloud for
The provider upload command will upload a Vagrant [box file](/vagrant/docs/boxes) to Vagrant Cloud for
the specified version and provider.
# Cloud Publish

4
website/content/docs/cli/connect.mdx
View File

@ -11,9 +11,9 @@ description: |-
**Command: `vagrant connect NAME`**
The connect command complements the
[share command](/docs/cli/share) by enabling access to shared
[share command](/vagrant/docs/cli/share) by enabling access to shared
environments. You can learn about all the details of Vagrant Share in the
[Vagrant Share section](/docs/share/).
[Vagrant Share section](/vagrant/docs/share/).
The reference of available command-line flags to this command
is available below.

2
website/content/docs/cli/destroy.mdx
View File

@ -35,4 +35,4 @@ the box installed in the system will still be present on the hard drive. To
return your computer to the state as it was before `vagrant up` command, you
need to use `vagrant box remove`.
For more information, read about the [`vagrant box remove`](/docs/cli/box) command.
For more information, read about the [`vagrant box remove`](/vagrant/docs/cli/box) command.

2
website/content/docs/cli/index.mdx
View File

@ -25,7 +25,7 @@ available by reading the appropriate sub-section available in the left
navigational area of this site.
You may also wish to consult the
[documentation](/docs/other/environmental-variables) regarding the
[documentation](/vagrant/docs/other/environmental-variables) regarding the
environmental variables that can be used to configure and control
Vagrant in a global way.

2
website/content/docs/cli/init.mdx
View File

@ -11,7 +11,7 @@ description: |-
**Command: `vagrant init [name [url]]`**
This initializes the current directory to be a Vagrant environment
by creating an initial [Vagrantfile](/docs/vagrantfile/) if
by creating an initial [Vagrantfile](/vagrant/docs/vagrantfile/) if
one does not already exist.
If a first argument is given, it will prepopulate the `config.vm.box`

6
website/content/docs/cli/login.mdx
View File

@ -11,13 +11,13 @@ description: |-
**Command: `vagrant login`**
The login command is used to authenticate with the
[HashiCorp's Vagrant Cloud](/vagrant-cloud) server. Logging in is only
[HashiCorp's Vagrant Cloud](/vagrant/vagrant-cloud) server. Logging in is only
necessary if you are accessing protected boxes or using
[Vagrant Share](/docs/share/).
[Vagrant Share](/vagrant/docs/share/).
**Logging in is not a requirement to use Vagrant.** The vast majority
of Vagrant does _not_ require a login. Only certain features such as protected
boxes or [Vagrant Share](/docs/share/) require a login.
boxes or [Vagrant Share](/vagrant/docs/share/) require a login.
The reference of available command-line flags to this command
is available below.

2
website/content/docs/cli/machine-readable.mdx
View File

@ -14,7 +14,7 @@ is replaced with machine-friendly output.
This mode makes it easy to programmatically execute Vagrant and read data
out of it. This output format is protected by our
[backwards compatibility](/docs/installation/backwards-compatibility)
[backwards compatibility](/vagrant/docs/installation/backwards-compatibility)
policy. Until Vagrant 2.0 is released, however, the machine readable output
may change as we determine more use cases for it. But the backwards
compatibility promise should make it safe to write client libraries to

10
website/content/docs/cli/non-primary.mdx
View File

@ -26,8 +26,8 @@ non-primary subcommands. They're executed just like any other subcommand:
The list of non-primary commands is below. Click on any command to learn
more about it.
- [docker-exec](/docs/providers/docker/commands)
- [docker-logs](/docs/providers/docker/commands)
- [docker-run](/docs/providers/docker/commands)
- [rsync](/docs/cli/rsync)
- [rsync-auto](/docs/cli/rsync-auto)
- [docker-exec](/vagrant/docs/providers/docker/commands)
- [docker-logs](/vagrant/docs/providers/docker/commands)
- [docker-run](/vagrant/docs/providers/docker/commands)
- [rsync](/vagrant/docs/cli/rsync)
- [rsync-auto](/vagrant/docs/cli/rsync-auto)

10
website/content/docs/cli/package.mdx
View File

@ -11,8 +11,8 @@ description: |-
**Command: `vagrant package [name|id]`**
This packages a currently running _VirtualBox_ or _Hyper-V_ environment into a
re-usable [box](/docs/boxes). This command can only be used with
other [providers](/docs/providers/) based on the provider implementation
re-usable [box](/vagrant/docs/boxes). This command can only be used with
other [providers](/vagrant/docs/providers/) based on the provider implementation
and if the provider supports it.
## Options
@ -30,15 +30,15 @@ and if the provider supports it.
tasks.
- `--info path/to/info.json` - The package will include a custom JSON file containing
information to be displayed by the [list](/docs/cli/box#box-list) command when invoked
information to be displayed by the [list](/vagrant/docs/cli/box#box-list) command when invoked
with the `-i` flag
- `--vagrantfile FILE` - Packages a Vagrantfile with the box, that is loaded
as part of the [Vagrantfile load order](/docs/vagrantfile/#load-order)
as part of the [Vagrantfile load order](/vagrant/docs/vagrantfile/#load-order)
when the resulting box is used.
-> **A common misconception** is that the `--vagrantfile`
option will package a Vagrantfile that is used when `vagrant init`
is used with this box. This is not the case. Instead, a Vagrantfile
is loaded and read as part of the Vagrant load process when the box is
used. For more information, read about the [Vagrantfile load order](/docs/vagrantfile/#load-order).
used. For more information, read about the [Vagrantfile load order](/vagrant/docs/vagrantfile/#load-order).

4
website/content/docs/cli/plugin.mdx
View File

@ -10,7 +10,7 @@ description: |-
**Command: `vagrant plugin`**
This is the command used to manage [plugins](/docs/plugins/).
This is the command used to manage [plugins](/vagrant/docs/plugins/).
The main functionality of this command is exposed via another level
of subcommands:
@ -104,7 +104,7 @@ This command accepts optional command-line flags:
**Command: `vagrant plugin license <name> <license-file>`**
This command installs a license for a proprietary Vagrant plugin,
such as the [VMware Fusion provider](/docs/providers/vmware).
such as the [VMware Fusion provider](/vagrant/docs/providers/vmware).
# Plugin List

2
website/content/docs/cli/port.mdx
View File

@ -37,4 +37,4 @@ $ vagrant port my-machine
- `--machine-readable` - This tells Vagrant to display machine-readable output
instead of the human-friendly output. More information is available in the
[machine-readable output](/docs/cli/machine-readable) documentation.
[machine-readable output](/vagrant/docs/cli/machine-readable) documentation.

2
website/content/docs/cli/provision.mdx
View File

@ -10,7 +10,7 @@ description: |-
**Command: `vagrant provision [vm-name]`**
Runs any configured [provisioners](/docs/provisioning/)
Runs any configured [provisioners](/vagrant/docs/provisioning/)
against the running Vagrant managed machine.
This command is a great way to quickly test any provisioners, and is especially

4
website/content/docs/cli/reload.mdx
View File

@ -10,8 +10,8 @@ description: |-
**Command: `vagrant reload [name|id]`**
The equivalent of running a [halt](/docs/cli/halt) followed by an
[up](/docs/cli/up).
The equivalent of running a [halt](/vagrant/docs/cli/halt) followed by an
[up](/vagrant/docs/cli/up).
This command is usually required for changes made in the Vagrantfile to
take effect. After making any modifications to the Vagrantfile, a `reload`

2
website/content/docs/cli/resume.mdx
View File

@ -12,7 +12,7 @@ description: |-
**Command: `vagrant resume [name|id]`**
This resumes a Vagrant managed machine that was previously suspended,
perhaps with the [suspend command](/docs/cli/suspend).
perhaps with the [suspend command](/vagrant/docs/cli/suspend).
The configured provisioners will not run again, by default. You can force
the provisioners to re-run by specifying the `--provision` flag.

4
website/content/docs/cli/rsync-auto.mdx
View File

@ -12,7 +12,7 @@ description: |-
**Command: `vagrant rsync-auto`**
This command watches all local directories of any
[rsync synced folders](/docs/synced-folders/rsync) and automatically
[rsync synced folders](/vagrant/docs/synced-folders/rsync) and automatically
initiates an rsync transfer when changes are detected. This command does
not exit until an interrupt is received.
@ -41,7 +41,7 @@ To ensure that the command works properly, you should start `rsync-auto`
only when the machine is running, and shut it down before any machine
state changes.
You can always force a resync with the [rsync](/docs/cli/rsync) command.
You can always force a resync with the [rsync](/vagrant/docs/cli/rsync) command.
## Vagrantfile Changes

2
website/content/docs/cli/rsync.mdx
View File

@ -9,7 +9,7 @@ description: The "vagrant rsync" command forces a re-sync of any rsync synced fo
**Command: `vagrant rsync`**
This command forces a re-sync of any
[rsync synced folders](/docs/synced-folders/rsync).
[rsync synced folders](/vagrant/docs/synced-folders/rsync).
Note that if you change any settings within the rsync synced folders such
as exclude paths, you will need to `vagrant reload` before this command will

2
website/content/docs/cli/share.mdx
View File

@ -15,7 +15,7 @@ share your Vagrant environment with anyone in the world, enabling collaboration
directly in your Vagrant environment in almost any network environment.
You can learn about all the details of Vagrant Share in the
[Vagrant Share section](/docs/share/).
[Vagrant Share section](/vagrant/docs/share/).
The reference of available command-line flags to this command
is available below.

4
website/content/docs/cli/suspend.mdx
View File

@ -11,10 +11,10 @@ description: |-
**Command: `vagrant suspend [name|id]`**
This suspends the guest machine Vagrant is managing, rather than fully
[shutting it down](/docs/cli/halt) or [destroying it](/docs/cli/destroy).
[shutting it down](/vagrant/docs/cli/halt) or [destroying it](/vagrant/docs/cli/destroy).
A suspend effectively saves the _exact point-in-time state_ of the machine,
so that when you [resume](/docs/cli/resume) it later, it begins running
so that when you [resume](/vagrant/docs/cli/resume) it later, it begins running
immediately from that point, rather than doing a full boot.
This generally requires extra disk space to store all the contents of the

6
website/content/docs/cli/up.mdx
View File

@ -11,14 +11,14 @@ description: |-
**Command: `vagrant up [name|id]`**
This command creates and configures guest machines according to your
[Vagrantfile](/docs/vagrantfile/).
[Vagrantfile](/vagrant/docs/vagrantfile/).
This is the single most important command in Vagrant, since it is how
any Vagrant machine is created.
## Options
- `name` - Name of machine defined in [Vagrantfile](/docs/vagrantfile/). Using
- `name` - Name of machine defined in [Vagrantfile](/vagrant/docs/vagrantfile/). Using
`name` to specify the Vagrant machine to act on must be done from within a
Vagrant project (directory where the Vagrantfile exists).
@ -38,7 +38,7 @@ any Vagrant machine is created.
is supported.
- `--provider x` - Bring the machine up with the given
[provider](/docs/providers/). By default this is "virtualbox".
[provider](/vagrant/docs/providers/). By default this is "virtualbox".
- `--[no-]provision` - Force, or prevent, the provisioners to run.

2
website/content/docs/cli/validate.mdx
View File

@ -8,7 +8,7 @@ description: The "vagrant validate" command is used to validate your Vagrantfile
**Command: `vagrant validate`**
This command validates your [Vagrantfile](/docs/vagrantfile/).
This command validates your [Vagrantfile](/vagrant/docs/vagrantfile/).
## Options

2
website/content/docs/cloud-init/configuration.mdx
View File

@ -39,7 +39,7 @@ or directly `inline` in a Vagrantfile.
option.
Examples of how to define these options can be found in the
[usage documentation](/docs/cloud-init/configuration).
[usage documentation](/vagrant/docs/cloud-init/configuration).
### cloud_init Type

4
website/content/docs/cloud-init/index.mdx
View File

@ -10,8 +10,8 @@ description: Introduction to using cloud-init with Vagrant
change in between releases. Use at your own risk. It currently is not officially
supported or functional.
For examples on how to achieve this, among other use cases, please refer to the [usage](/docs/cloud-init/usage)
For examples on how to achieve this, among other use cases, please refer to the [usage](/vagrant/docs/cloud-init/usage)
guide for more information!
For more information about what options are available for configuring cloud-init, see the
[configuration section](/docs/cloud-init/configuration).
[configuration section](/vagrant/docs/cloud-init/configuration).

2
website/content/docs/cloud-init/usage.mdx
View File

@ -17,7 +17,7 @@ VAGRANT_EXPERIMENTAL="cloud_init,disks"
```
Please note that `VAGRANT_EXPERIMENTAL` is an environment variable. For more
information about this flag visit the [Experimental docs page](/docs/experimental)
information about this flag visit the [Experimental docs page](/vagrant/docs/experimental)
for more info. Without this flag enabled, any cloud-init configs defined will
not be configured.

4
website/content/docs/disks/hyperv/index.mdx
View File

@ -19,7 +19,7 @@ VAGRANT_EXPERIMENTAL="disks"
```
Please note that `VAGRANT_EXPERIMENTAL` is an environment variable. For more
information about this flag visit the [Experimental docs page](/docs/experimental/)
information about this flag visit the [Experimental docs page](/vagrant/docs/experimental/)
for more info. Without this flag enabled, any disks defined will not be configured.
Because of how Hyper-V handles disk management, a Vagrant guest _must_ be powered
@ -28,5 +28,5 @@ with a guests disk, you will need to `vagrant reload` the guest for any changes
to be applied.
For more information on how to use Hyper-V to configure disks for a guest, refer
to the [general usage](/docs/disks/usage) and [configuration](/docs/disks/configuration)
to the [general usage](/vagrant/docs/disks/usage) and [configuration](/vagrant/docs/disks/configuration)
guide for more information.

6
website/content/docs/disks/hyperv/usage.mdx
View File

@ -19,11 +19,11 @@ VAGRANT_EXPERIMENTAL="disks"
```
Please note that `VAGRANT_EXPERIMENTAL` is an environment variable. For more
information about this flag visit the [Experimental docs page](/docs/experimental/)
information about this flag visit the [Experimental docs page](/vagrant/docs/experimental/)
for more info. Without this flag enabled, any disks defined will not be configured.
For examples of how to use the disk feature with Hyper-V, please refer to the
[general disk usage guide](/docs/disks/usage) for more examples.
[general disk usage guide](/vagrant/docs/disks/usage) for more examples.
## provider_config options
@ -32,7 +32,7 @@ Vagrant supports most options for these operations. You should be able to define
the PowerShell specific argument to a given Hyper-V command in the provider_config
hash, and Vagrant should properly pass it along to the command.
To define a provider specific option, please refer to the [Disk Options documentation page](/docs/disks/configuration) for more info.
To define a provider specific option, please refer to the [Disk Options documentation page](/vagrant/docs/disks/configuration) for more info.
### Note about options defined below

6
website/content/docs/disks/index.mdx
View File

@ -14,12 +14,12 @@ for more information on how to use and enable this feature.
Vagrant Disks is a feature that allows users to define what mediums should be attached
to their guests, as well as allowing users to resize their primary disk.
For examples on how to achieve this, among other use cases, please refer to the [usage](/docs/disks/usage)
For examples on how to achieve this, among other use cases, please refer to the [usage](/vagrant/docs/disks/usage)
guide for more information!
For more information about what options are available for configuring disks, see the
[configuration section](/docs/disks/configuration).
[configuration section](/vagrant/docs/disks/configuration).
## Supported Providers
Currently, only VirtualBox is supported. Please refer to the [VirtualBox documentation](/docs/disks/virtualbox) for more information on using disks with the VirtualBox provider!
Currently, only VirtualBox is supported. Please refer to the [VirtualBox documentation](/vagrant/docs/disks/virtualbox) for more information on using disks with the VirtualBox provider!

2
website/content/docs/disks/usage.mdx
View File

@ -17,7 +17,7 @@ VAGRANT_EXPERIMENTAL="disks"
```
Please note that `VAGRANT_EXPERIMENTAL` is an environment variable. For more
information about this flag visit the [Experimental docs page](/docs/experimental/)
information about this flag visit the [Experimental docs page](/vagrant/docs/experimental/)
for more info. Without this flag enabled, any disks defined will not be configured.
Below are some very simple examples of how to use Vagrant Disks with the VirtualBox provider.

6
website/content/docs/disks/virtualbox/index.mdx
View File

@ -19,7 +19,7 @@ VAGRANT_EXPERIMENTAL="disks"
```
Please note that `VAGRANT_EXPERIMENTAL` is an environment variable. For more
information about this flag visit the [Experimental docs page](/docs/experimental/)
information about this flag visit the [Experimental docs page](/vagrant/docs/experimental/)
for more info. Without this flag enabled, any disks defined will not be configured.
**Vagrant currently only supports VirtualBox version 5.x and newer for configuring and
@ -42,7 +42,7 @@ disks to a particular storage controller based on the type of disk configured:
Vagrant will not be able to configure disks of a given type if the associated
storage controller does not exist. In this case, you may use
[provider-specific customizations](/docs/providers/virtualbox/configuration#vboxmanage-customizations)
[provider-specific customizations](/vagrant/docs/providers/virtualbox/configuration#vboxmanage-customizations)
to add a required storage controller.
It should also be noted that storage controllers have different limits for the
@ -51,5 +51,5 @@ maximum number of disks for a storage controller type will result in a Vagrant
error.
For more information on how to use VirtualBox to configure disks for a guest, refer
to the [general usage](/docs/disks/usage) and [configuration](/docs/disks/configuration)
to the [general usage](/vagrant/docs/disks/usage) and [configuration](/vagrant/docs/disks/configuration)
guide for more information.

4
website/content/docs/disks/virtualbox/usage.mdx
View File

@ -19,11 +19,11 @@ VAGRANT_EXPERIMENTAL="disks"
```
Please note that `VAGRANT_EXPERIMENTAL` is an environment variable. For more
information about this flag visit the [Experimental docs page](/docs/experimental/)
information about this flag visit the [Experimental docs page](/vagrant/docs/experimental/)
for more info. Without this flag enabled, any disks defined will not be configured.
For examples of how to use the disk feature with VirtualBox, please refer to the
[general disk usage guide](/docs/disks/usage) for more examples.
[general disk usage guide](/vagrant/docs/disks/usage) for more examples.
## provider_config options

2
website/content/docs/disks/vmware/common-issues.mdx
View File

@ -36,6 +36,6 @@ Vagrant will not decrease the size of a disk.
If snapshots exist for a VM, disk functionality will be limited. Vagrant will return
an error for any actions that are limited due to the existence of snapshots. In order
to restore functionality the snapshots must be removed. This can be done using the
[`vagrant snapshot delete`](/docs/cli/snapshot) command. To delete all snapshots
[`vagrant snapshot delete`](/vagrant/docs/cli/snapshot) command. To delete all snapshots
for a VMware backed VM try `vagrant cap provider delete_all_snapshots --target <target vm name>`.
Note once a snapshot is deleted, it can not be restored.

4
website/content/docs/disks/vmware/index.mdx
View File

@ -21,7 +21,7 @@ VAGRANT_EXPERIMENTAL="disks"
```
Please note that `VAGRANT_EXPERIMENTAL` is an environment variable. For more
information about this flag visit the [Experimental docs page](/docs/experimental/)
information about this flag visit the [Experimental docs page](/vagrant/docs/experimental/)
for more info. Without this flag enabled, any disks defined will not be configured.
Because of how VMware handles disk management, a Vagrant guest _must_ be powered
@ -30,5 +30,5 @@ with a guests disk, you will need to `vagrant reload` the guest for any changes
to be applied.
For more information on how to use VMware to configure disks for a guest, refer
to the [general usage](/docs/disks/usage) and [configuration](/docs/disks/configuration)
to the [general usage](/vagrant/docs/disks/usage) and [configuration](/vagrant/docs/disks/configuration)
guide for more information.

6
website/content/docs/disks/vmware/usage.mdx
View File

@ -21,17 +21,17 @@ VAGRANT_EXPERIMENTAL="disks"
```
Please note that `VAGRANT_EXPERIMENTAL` is an environment variable. For more
information about this flag visit the [Experimental docs page](/docs/experimental/)
information about this flag visit the [Experimental docs page](/vagrant/docs/experimental/)
for more info. Without this flag enabled, any disks defined will not be configured.
For examples of how to use the disk feature with VMWware, please refer to the
[general disk usage guide](/docs/disks/usage) for more examples.
[general disk usage guide](/vagrant/docs/disks/usage) for more examples.
## provider_config options
Vagrant supports some additional VMWware specific options for specifying disk.
To define a provider specific option, please refer to the [Disk Options documentation page](/docs/disks/configuration) for more info.
To define a provider specific option, please refer to the [Disk Options documentation page](/vagrant/docs/disks/configuration) for more info.
### Note about options defined below

8
website/content/docs/experimental/index.mdx
View File

@ -42,22 +42,22 @@ This is a list of all the valid experimental features that Vagrant recognizes:
### `cloud_init`
Enabling this feature allows Vagrant to use the `cloud-init` feature. More
information about these options can be found on the [cloud-init documentation page](/docs/cloud-init/usage)
information about these options can be found on the [cloud-init documentation page](/vagrant/docs/cloud-init/usage)
### `dependency_provisioners`
Enabling this feature allows all provisioners to specify `before` and `after`
options. These options allow provisioners to be configured to run before or after
any given "root" provisioner. More information about these options can be found
on the [base provisioner documentation page](/docs/provisioning/basic_usage)
on the [base provisioner documentation page](/vagrant/docs/provisioning/basic_usage)
### `disks`
Enabling this feature will allow Vagrant to manage and configure virtual hard disks
for certain providers. More information about supported providers and how to
configure disks can be found on the [disk documentation page](/docs/disks)
configure disks can be found on the [disk documentation page](/vagrant/docs/disks)
### `typed_triggers`
Enabling this feature allows triggers to recognize and execute `:type` triggers.
More information about how these should be used can be found on the [trigger documentation page](/docs/triggers/configuration#trigger-types)
More information about how these should be used can be found on the [trigger documentation page](/vagrant/docs/triggers/configuration#trigger-types)

2
website/content/docs/experimental/vagrant_go.mdx
View File

@ -105,7 +105,7 @@ The form of these directories is as follows:
Vagrant-go does not have knowledge of the Vagrant-ruby data directories so does not
have access to that data and vice versa. Both Vagrant-go and Vagrant-ruby
respect the [Vagrant environment variables](/docs/other/environmental-variables/) for
respect the [Vagrant environment variables](/vagrant/docs/other/environmental-variables/) for
setting data directory paths. However, the layout and content of these directories
are different for Vagrant-go and Vagrant-ruby.

4
website/content/docs/index.mdx
View File

@ -14,10 +14,10 @@ Welcome to the documentation for Vagrant - the command line utility for managing
the lifecycle of virtual machines. This website aims to document every feature
of Vagrant from top-to-bottom, covering as much detail as possible. If you are
just getting started with Vagrant, we highly recommended starting with
the [getting started tutorial](https://learn.hashicorp.com/vagrant) on
the [getting started tutorial](/vagrant/tutorials) on
HashiCorp's Learn platform first, and then returning to this page.
The navigation will take you through each component of Vagrant. Click on a
navigation item to get started, or read more about
[why developers, designers, and operators choose Vagrant](/intro)
[why developers, designers, and operators choose Vagrant](/vagrant/intro)
for their needs.

4
website/content/docs/installation/index.mdx
View File

@ -10,7 +10,7 @@ description: |-
To get started with Vagrant, download the appropriate installer or
package for your platform from our
[Vagrant downloads page](/downloads). Install the package with the standard procedures for
[Vagrant downloads page](/vagrant/downloads). Install the package with the standard procedures for
your operating system.
The installer automatically adds `vagrant` to your system path
@ -26,7 +26,7 @@ versions of Vagrant.
## First development environment
If you are new to Vagrant, the next step to set up a development environment is to install
a [box](https://developer.hashicorp.com/vagrant/tutorials/getting-started/getting-started-boxes).
a [box](/vagrant/tutorials/getting-started/getting-started-boxes).
## How to use multiple hypervisors

6
website/content/docs/installation/uninstallation.mdx
View File

@ -17,7 +17,7 @@ do this on every platform.
Removing the Vagrant program will remove the `vagrant` binary and all
dependencies from your machine. After uninstalling the program, you can
always [reinstall](/docs/installation/) again using standard
always [reinstall](/vagrant/docs/installation/) again using standard
methods. Uninstalling Vagrant will _not_ remove user data. The section below this
one gives more detailed instructions on how to remove that directory from your
system.
@ -42,8 +42,8 @@ rm -f /usr/bin/vagrant
## Removing User Data
Removing the user data will remove all [boxes](/docs/boxes),
[plugins](/docs/plugins/), license files, and any stored state that may be used
Removing the user data will remove all [boxes](/vagrant/docs/boxes),
[plugins](/vagrant/docs/plugins/), license files, and any stored state that may be used
by Vagrant. Removing the user data effectively makes Vagrant think it
is a fresh install.

4
website/content/docs/installation/upgrading-from-1-0.mdx
View File

@ -11,12 +11,12 @@ description: |-
# Upgrading From Vagrant 1.0.x
The upgrade process from 1.0.x to 1.x is straightforward. Vagrant is quite
[backwards compatible](/docs/installation/backwards-compatibility)
[backwards compatible](/vagrant/docs/installation/backwards-compatibility)
with Vagrant 1.0.x, so you can simply reinstall Vagrant
over your previous installation by downloading the latest package and
installing it using standard procedures for your operating system.
As the [backwards compatibility](/docs/installation/backwards-compatibility)
As the [backwards compatibility](/vagrant/docs/installation/backwards-compatibility)
page says, **Vagrant 1.0.x plugins will not work with Vagrant 1.1+**. Many
of these plugins have been updated to work with newer versions of Vagrant,
so you can look to see if they've been updated. If not however, you will have

6
website/content/docs/installation/upgrading.mdx
View File

@ -12,11 +12,11 @@ description: |-
This page details how to upgrade Vagrant in the 1.x.x series.
~> If you need to upgrade from Vagrant 1.0.x, read the
[specific page dedicated to that](/docs/installation/upgrading-from-1-0).
[specific page dedicated to that](/vagrant/docs/installation/upgrading-from-1-0).
Vagrant upgrades during the 1.x.x release series are straightforward:
1. [Download](/downloads) the new package
1. [Download](/vagrant/downloads) the new package
2. Install it over the existing package
The installers will properly overwrite and remove old files. It is recommended
@ -26,7 +26,7 @@ that no other Vagrant processes are running during the upgrade process.
Note that Vagrantfile stability for the new Vagrantfile syntax is not
guaranteed until Vagrant 3.0. While Vagrantfiles made for 1.0.x will
[continue to work](/docs/installation/backwards-compatibility),
[continue to work](/vagrant/docs/installation/backwards-compatibility),
newer Vagrantfiles may have backwards incompatible changes until 3.0.
## Issue reports

10
website/content/docs/multi-machine.mdx
View File

@ -32,7 +32,7 @@ benefits of Vagrant.
## Defining Multiple Machines
Multiple machines are defined within the same project [Vagrantfile](/docs/vagrantfile/)
Multiple machines are defined within the same project [Vagrantfile](/vagrant/docs/vagrantfile/)
using the `config.vm.define` method call. This configuration directive
is a little funny, because it creates a Vagrant configuration within a
configuration. An example shows this best:
@ -60,7 +60,7 @@ being defined. Therefore, any configuration on `web` will only affect the
And importantly, you can continue to use the `config` object as well. The
configuration object is loaded and merged before the machine-specific configuration,
just like other Vagrantfiles within the
[Vagrantfile load order](/docs/vagrantfile/#load-order).
[Vagrantfile load order](/vagrant/docs/vagrantfile/#load-order).
If you are familiar with programming, this is similar to how languages have
different variable scopes.
@ -87,7 +87,7 @@ that "B" is last. That is because the ordering is outside-in, in
the order of the file.
If you want to apply a slightly different configuration to multiple machines,
see [this tip](/docs/vagrantfile/tips#loop-over-vm-definitions).
see [this tip](/vagrant/docs/vagrantfile/tips#loop-over-vm-definitions).
## Controlling Multiple Machines
@ -115,8 +115,8 @@ slashes, it assumes you are using a regular expression.
## Communication Between Machines
In order to facilitate communication within machines in a multi-machine setup,
the various [networking](/docs/networking/) options should be used.
In particular, the [private network](/docs/networking/private_network) can
the various [networking](/vagrant/docs/networking/) options should be used.
In particular, the [private network](/vagrant/docs/networking/private_network) can
be used to make a private network between multiple machines and the host.
## Specifying a Primary Machine

4
website/content/docs/networking/basic_usage.mdx
View File

@ -17,7 +17,7 @@ are important to know.
## Configuration
All networks are configured within your [Vagrantfile](/docs/vagrantfile/)
All networks are configured within your [Vagrantfile](/vagrant/docs/vagrantfile/)
using the `config.vm.network` method call. For example, the Vagrantfile
below defines some port forwarding:
@ -38,7 +38,7 @@ the guest port can be accessed by.
Multiple networks can be defined by having multiple `config.vm.network`
calls within the Vagrantfile. The exact meaning of this can differ for
each [provider](/docs/providers/), but in general the order specifies
each [provider](/vagrant/docs/providers/), but in general the order specifies
the order in which the networks are enabled.
## Enabling Networks

2
website/content/docs/networking/forwarded_ports.mdx
View File

@ -112,7 +112,7 @@ will output information about any collisions detections and auto corrections
made, so you can take notice and act accordingly.
You can define allowed port range assignable by Vagrant when port collision is
detected via [config.vm.usable_port_range](/docs/vagrantfile/machine_settings) property.
detected via [config.vm.usable_port_range](/vagrant/docs/vagrantfile/machine_settings) property.
```ruby
Vagrant.configure("2") do |config|

6
website/content/docs/networking/index.mdx
View File

@ -14,12 +14,12 @@ some high-level networking options for things such as forwarded ports,
connecting to a public network, or creating a private network.
The high-level networking options are meant to define an abstraction that
works across multiple [providers](/docs/providers/). This means that
works across multiple [providers](/vagrant/docs/providers/). This means that
you can take your Vagrantfile you used to spin up a VirtualBox machine and
you can reasonably expect that Vagrantfile to behave the same with something
like VMware.
You should first read the [basic usage](/docs/networking/basic_usage) page
You should first read the [basic usage](/vagrant/docs/networking/basic_usage) page
and then continue by reading the documentation for a specific networking
primitive by following the navigation to the left.
@ -28,7 +28,7 @@ primitive by following the navigation to the left.
In some cases,
these options are _too_ high-level, and you may want to more finely tune
and configure the network interfaces of the underlying machine. Most
providers expose [provider-specific configuration](/docs/providers/configuration)
providers expose [provider-specific configuration](/vagrant/docs/providers/configuration)
to do this, so please read the documentation for your specific provider
to see what options are available.

2
website/content/docs/networking/private_network.mdx
View File

@ -16,7 +16,7 @@ that is not publicly accessible from the global internet. In general, this
means your machine gets an address in the [private address space](https://en.wikipedia.org/wiki/Private_network#Private_IPv4_address_spaces).
Multiple machines within the same private network (also usually with the
restriction that they're backed by the same [provider](/docs/providers/))
restriction that they're backed by the same [provider](/vagrant/docs/providers/))
can communicate with each other on private networks.
-> **Guest operating system support.** Private networks generally

6
website/content/docs/networking/public_network.mdx
View File

@ -13,9 +13,9 @@ description: |-
**Network identifier: `public_network`**
Vagrant public networks are less private than private networks, and the exact
meaning actually varies from [provider to provider](/docs/providers/),
meaning actually varies from [provider to provider](/vagrant/docs/providers/),
hence the ambiguous definition. The idea is that while
[private networks](/docs/networking/private_network) should never allow the
[private networks](/vagrant/docs/networking/private_network) should never allow the
general public access to your machine, public networks can.
-> **Confused?** We kind of are, too. It is likely that public
@ -30,7 +30,7 @@ for SSH access, and potentially allow root access over SSH. With
these known credentials, your box is easily accessible by anyone on
your network. Before configuring Vagrant to use a public network,
consider _all_ potential security implications
and review the [default box configuration](/docs/boxes/base) to identify potential security risks.
and review the [default box configuration](/vagrant/docs/boxes/base) to identify potential security risks.
## DHCP

2
website/content/docs/other/environmental-variables.mdx
View File

@ -140,7 +140,7 @@ This option can be overridden on a per-folder basis within your Vagrantfile
config by setting the `SharedFoldersEnableSymlinksCreate` option to true if you
do not wish to completely disable this feature for all VirtualBox guests.
More information on the option can be read in the [VirtualBox synced folders docs page.](/docs/synced-folders/virtualbox#sharedfoldersenablesymlinkscreate)
More information on the option can be read in the [VirtualBox synced folders docs page.](/vagrant/docs/synced-folders/virtualbox#sharedfoldersenablesymlinkscreate)
## `VAGRANT_DISABLE_SMBMFSYMLINKS`

4
website/content/docs/other/index.mdx
View File

@ -11,5 +11,5 @@ description: |-
This section covers other information that does not quite fit under the
other categories.
- [Debugging](/docs/other/debugging)
- [Environment Variables](/docs/other/environmental-variables)
- [Debugging](/vagrant/docs/other/debugging)
- [Environment Variables](/vagrant/docs/other/environmental-variables)

2
website/content/docs/plugins/commands.mdx
View File

@ -11,7 +11,7 @@ description: |-
This page documents how to add new commands to Vagrant, invocable
via `vagrant YOUR-COMMAND`. Prior to reading this, you should be familiar
with the [plugin development basics](/docs/plugins/development-basics).
with the [plugin development basics](/vagrant/docs/plugins/development-basics).
~> **Warning: Advanced Topic!** Developing plugins is an
advanced topic that only experienced Vagrant users who are reasonably

4
website/content/docs/plugins/configuration.mdx
View File

@ -12,7 +12,7 @@ description: |-
This page documents how to add new configuration options to Vagrant,
settable with `config.YOURKEY` in Vagrantfiles. Prior to reading this,
you should be familiar with the
[plugin development basics](/docs/plugins/development-basics).
[plugin development basics](/vagrant/docs/plugins/development-basics).
~> **Warning: Advanced Topic!** Developing plugins is an
advanced topic that only experienced Vagrant users who are reasonably
@ -74,7 +74,7 @@ there.
## Merging
Vagrant works by loading [multiple Vagrantfiles and merging them](/docs/vagrantfile/#load-order).
Vagrant works by loading [multiple Vagrantfiles and merging them](/vagrant/docs/vagrantfile/#load-order).
This merge logic is built-in to configuration classes. When merging two
configuration objects, we will call them "old" and "new", it'll by default
take all the instance variables defined on "new" that are not `UNSET_VALUE`

2
website/content/docs/plugins/development-basics.mdx
View File

@ -25,7 +25,7 @@ comfortable with Ruby should approach.
Plugins are written using [Ruby](https://www.ruby-lang.org/en/) and are packaged
using [RubyGems](https://rubygems.org/). Familiarity with Ruby is required,
but the [packaging and distribution](/docs/plugins/packaging) section should help
but the [packaging and distribution](/vagrant/docs/plugins/packaging) section should help
guide you to packaging your plugin into a RubyGem.
## Setup and Workflow

2
website/content/docs/plugins/go-plugins/guests.mdx
View File

@ -35,7 +35,7 @@ The file structure of a guest plugin looks like:
Where `main.go` defines the plugin options. `guest/myguest.go` defines the core plugin
functionality including the detection of the guest. `cap/*` has the definitions of
all the guest plugin capabilities. These capabilities are the same as those for [Ruby
plugins](../guest-capabilities).
plugins](/vagrant/docs/plugins/guest-capabilities).
## Writing a guest plugin

6
website/content/docs/plugins/guest-capabilities.mdx
View File

@ -10,17 +10,17 @@ description: |-
# Plugin Development: Guest Capabilities
This page documents how to add new capabilities for [guests](/docs/plugins/guests)
This page documents how to add new capabilities for [guests](/vagrant/docs/plugins/guests)
to Vagrant, allowing Vagrant to perform new actions on specific guest
operating systems.
Prior to reading this, you should be familiar
with the [plugin development basics](/docs/plugins/development-basics).
with the [plugin development basics](/vagrant/docs/plugins/development-basics).
~> **Warning: Advanced Topic!** Developing plugins is an
advanced topic that only experienced Vagrant users who are reasonably
comfortable with Ruby should approach.
Guest capabilities augment [guests](/docs/plugins/guests) by attaching
Guest capabilities augment [guests](/vagrant/docs/plugins/guests) by attaching
specific "capabilities" to the guest, which are actions that can be performed
in the context of that guest operating system.

6
website/content/docs/plugins/guests.mdx
View File

@ -12,7 +12,7 @@ description: |-
This page documents how to add new guest OS detection to Vagrant, allowing
Vagrant to properly configure new operating systems.
Prior to reading this, you should be familiar
with the [plugin development basics](/docs/plugins/development-basics).
with the [plugin development basics](/vagrant/docs/plugins/development-basics).
~> **Warning: Advanced Topic!** Developing plugins is an
advanced topic that only experienced Vagrant users who are reasonably
@ -64,7 +64,7 @@ end
```
After detecting an OS, that OS is used for various
[guest capabilities](/docs/plugins/guest-capabilities) that may be
[guest capabilities](/vagrant/docs/plugins/guest-capabilities) that may be
required.
## Guest Inheritance
@ -76,7 +76,7 @@ Inheritance allows guests to share a lot of common behavior while allowing
distro-specific overrides.
Inheritance is not done via standard Ruby class inheritance because Vagrant
uses a custom [capability-based](/docs/plugins/guest-capabilities) system.
uses a custom [capability-based](/vagrant/docs/plugins/guest-capabilities) system.
Vagrant handles inheritance dispatch for you.
To subclass another guest, specify that guest's name as a second parameter

8
website/content/docs/plugins/host-capabilities.mdx
View File

@ -9,17 +9,17 @@ description: >-
# Plugin Development: Host Capabilities
This page documents how to add new capabilities for [hosts](/docs/plugins/hosts)
This page documents how to add new capabilities for [hosts](/vagrant/docs/plugins/hosts)
to Vagrant, allowing Vagrant to perform new actions on specific host
operating systems.
Prior to reading this, you should be familiar
with the [plugin development basics](/docs/plugins/development-basics).
with the [plugin development basics](/vagrant/docs/plugins/development-basics).
~> **Warning: Advanced Topic!** Developing plugins is an
advanced topic that only experienced Vagrant users who are reasonably
comfortable with Ruby should approach.
Host capabilities augment [hosts](/docs/plugins/hosts) by attaching
Host capabilities augment [hosts](/vagrant/docs/plugins/hosts) by attaching
specific "capabilities" to the host, which are actions that can be performed
in the context of that host operating system.
@ -31,7 +31,7 @@ core of Vagrant and was not easily augmented.
## Definition and Implementation
The definition and implementation of host capabilities is identical
to [guest capabilities](/docs/plugins/guest-capabilities).
to [guest capabilities](/vagrant/docs/plugins/guest-capabilities).
The main difference from guest capabilities, however, is that instead of
taking a machine as the first argument, all host capabilities take an

8
website/content/docs/plugins/hosts.mdx
View File

@ -13,7 +13,7 @@ description: |-
This page documents how to add new host OS detection to Vagrant, allowing
Vagrant to properly execute host-specific operations on new operating systems.
Prior to reading this, you should be familiar
with the [plugin development basics](/docs/plugins/development-basics).
with the [plugin development basics](/vagrant/docs/plugins/development-basics).
~> **Warning: Advanced Topic!** Developing plugins is an
advanced topic that only experienced Vagrant users who are reasonably
@ -22,7 +22,7 @@ comfortable with Ruby should approach.
Vagrant has some features that require host OS-specific actions, such as
exporting NFS folders. These tasks vary from operating system to operating
system. Vagrant uses host detection as well as
[host capabilities](/docs/plugins/host-capabilities) to perform these
[host capabilities](/vagrant/docs/plugins/host-capabilities) to perform these
host OS-specific operations.
## Definition Component
@ -61,7 +61,7 @@ end
```
After detecting an OS, that OS is used for various
[host capabilities](/docs/plugins/host-capabilities) that may be
[host capabilities](/vagrant/docs/plugins/host-capabilities) that may be
required.
## Host Inheritance
@ -73,7 +73,7 @@ Inheritance allows hosts to share a lot of common behavior while allowing
distro-specific overrides.
Inheritance is not done via standard Ruby class inheritance because Vagrant
uses a custom [capability-based](/docs/plugins/host-capabilities) system.
uses a custom [capability-based](/vagrant/docs/plugins/host-capabilities) system.
Vagrant handles inheritance dispatch for you.
To subclass another host, specify that host's name as a second parameter

4
website/content/docs/plugins/packaging.mdx
View File

@ -12,9 +12,9 @@ description: |-
This page documents how to organize the file structure of your plugin
and distribute it so that it is installable using
[standard installation methods](/docs/plugins/usage).
[standard installation methods](/vagrant/docs/plugins/usage).
Prior to reading this, you should be familiar
with the [plugin development basics](/docs/plugins/development-basics).
with the [plugin development basics](/vagrant/docs/plugins/development-basics).
~> **Warning: Advanced Topic!** Developing plugins is an
advanced topic that only experienced Vagrant users who are reasonably

14
website/content/docs/plugins/providers.mdx
View File

@ -10,13 +10,13 @@ description: |-
# Plugin Development: Providers
This page documents how to add support for new [providers](/docs/providers/)
This page documents how to add support for new [providers](/vagrant/docs/providers/)
to Vagrant, allowing Vagrant to run and manage machines powered by a
system other than VirtualBox. Prior to reading this, you should be familiar
with the [plugin development basics](/docs/plugins/development-basics).
with the [plugin development basics](/vagrant/docs/plugins/development-basics).
Prior to developing a provider you should also be familiar with how
[providers work](/docs/providers/) from
[providers work](/vagrant/docs/providers/) from
a user standpoint.
~> **Warning: Advanced Topic!** Developing plugins is an
@ -74,7 +74,7 @@ create your provider.
Each provider is responsible for having its own box format. This is
actually an extremely simple step due to how generic boxes are. Before
explaining you should get familiar with the general
[box file format](/docs/boxes/format).
[box file format](/vagrant/docs/boxes/format).
The only requirement for your box format is that the `metadata.json`
file have a `provider` key which matches the name of your provider you
@ -162,13 +162,13 @@ from this directory.
## Configuration
Vagrant supports [provider-specific configuration](/docs/providers/configuration),
Vagrant supports [provider-specific configuration](/vagrant/docs/providers/configuration),
allowing for users to finely tune and control specific providers from
Vagrantfiles. It is easy for your custom provider to expose custom configuration
as well.
Provider-specific configuration is a special case of a normal
[configuration plugin](/docs/plugins/configuration). When defining the
[configuration plugin](/vagrant/docs/plugins/configuration). When defining the
configuration component, name the configuration the same as the provider,
and as a second parameter, specify `:provider`, like so:
@ -191,7 +191,7 @@ end
```
The configuration class returned from the `config` component in the plugin
is the same as any other [configuration plugin](/docs/plugins/configuration),
is the same as any other [configuration plugin](/vagrant/docs/plugins/configuration),
so read that page for more information. Vagrant automatically handles
configuration validation and such just like any other configuration piece.

4
website/content/docs/plugins/provisioners.mdx
View File

@ -10,10 +10,10 @@ script: |-
# Plugin Development: Provisioners
This page documents how to add new [provisioners](/docs/provisioning/) to Vagrant,
This page documents how to add new [provisioners](/vagrant/docs/provisioning/) to Vagrant,
allowing Vagrant to automatically install software and configure software
using a custom provisioner. Prior to reading this, you should be familiar
with the [plugin development basics](/docs/plugins/development-basics).
with the [plugin development basics](/vagrant/docs/plugins/development-basics).
~> **Warning: Advanced Topic!** Developing plugins is an
advanced topic that only experienced Vagrant users who are reasonably

2
website/content/docs/providers/basic_usage.mdx
View File

@ -91,7 +91,7 @@ Vagrant attempts to find the default provider in the following order:
Using this method, there are very few cases that Vagrant does not find the
correct provider for you. This also allows each
[Vagrantfile](/docs/vagrantfile/) to define what providers
[Vagrantfile](/vagrant/docs/vagrantfile/) to define what providers
the development environment is made for by ordering provider configurations.
A trick is to use `config.vm.provider` with no configuration at the top of

2
website/content/docs/providers/custom.mdx
View File

@ -9,4 +9,4 @@ description: |-
# Custom Provider
To learn how to make your own custom Vagrant providers, read the Vagrant plugin
development guide on [creating custom providers](/docs/plugins/providers).
development guide on [creating custom providers](/vagrant/docs/plugins/providers).

2
website/content/docs/providers/docker/basics.mdx
View File

@ -121,5 +121,5 @@ end
The host VM will be spun up at the first `vagrant up` where the provider
is Docker. To control this host VM, use the
[global-status command](/docs/cli/global-status)
[global-status command](/vagrant/docs/cli/global-status)
along with global control.

2
website/content/docs/providers/docker/index.mdx
View File

@ -18,7 +18,7 @@ it provides for a good workflow for developing Dockerfiles.
~> **Warning: Docker knowledge assumed.** We assume that
you know what Docker is and that you are comfortable with the basics
of Docker. If not, we recommend starting with another provider such
as [VirtualBox](/docs/providers/virtualbox).
as [VirtualBox](/vagrant/docs/providers/virtualbox).
Use the navigation to the left to find a specific Docker topic
to read more about.

10
website/content/docs/providers/hyperv/boxes.mdx
View File

@ -8,18 +8,18 @@ description: |-
# Creating a Base Box
As with [every Vagrant provider](/docs/providers/basic_usage), the
As with [every Vagrant provider](/vagrant/docs/providers/basic_usage), the
Vagrant Hyper-V 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). Actually,
[general guide to creating base boxes](/vagrant/docs/boxes/base). 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).
[basics of the box file format](/vagrant/docs/boxes/format).
~> **Advanced topic!** This is a reasonably advanced topic that
a beginning user of Vagrant does not need to understand. If you are
@ -30,7 +30,7 @@ your own custom boxes, this is for you.
## Additional Software
In addition to the software that should be installed based on the
[general guide to creating base boxes](/docs/boxes/base),
[general guide to creating base boxes](/vagrant/docs/boxes/base),
Hyper-V base boxes require some additional software.
### Hyper-V Kernel Modules
@ -77,7 +77,7 @@ provider and can only add to the size of the box if there are snapshots
in that folder.
Then, create the "metadata.json" file necessary for the box, as documented
in [basics of the box file format](/docs/boxes/format). The proper
in [basics of the box file format](/vagrant/docs/boxes/format). The proper
provider value to use for the metadata is "hyperv".
Finally, create an archive of those contents (but _not_ the parent folder)

2
website/content/docs/providers/hyperv/usage.mdx
View File

@ -9,7 +9,7 @@ description: |-
# Usage
The Vagrant Hyper-V provider is used just like any other provider. Please
read the general [basic usage](/docs/providers/basic_usage) page for
read the general [basic usage](/vagrant/docs/providers/basic_usage) page for
providers.
The value to use for the `--provider` flag is `hyperv`.

2
website/content/docs/providers/installation.mdx
View File

@ -10,6 +10,6 @@ description: |-
# Provider Installation
Providers are distributed as Vagrant plugins, and are therefore installed
using [standard plugin installation steps](/docs/plugins/usage). After
using [standard plugin installation steps](/vagrant/docs/plugins/usage). After
installing a plugin which contains a provider, the provider should
immediately be available.

8
website/content/docs/providers/virtualbox/boxes.mdx
View File

@ -8,19 +8,19 @@ description: |-
# Creating a Base Box
As with [every Vagrant provider](/docs/providers/basic_usage), the
As with [every Vagrant provider](/vagrant/docs/providers/basic_usage), 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). Actually,
[general guide to creating base boxes](/vagrant/docs/boxes/base). 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).
[basics of the box file format](/vagrant/docs/boxes/format).
~> **Advanced topic!** This is a reasonably advanced topic that
a beginning user of Vagrant does not need to understand. If you are
@ -47,7 +47,7 @@ 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),
[general guide to creating base boxes](/vagrant/docs/boxes/base),
VirtualBox base boxes require some additional software.
### VirtualBox Guest Additions

2
website/content/docs/providers/virtualbox/usage.mdx
View File

@ -9,7 +9,7 @@ description: |-
# Usage
The Vagrant VirtualBox provider is used just like any other provider. Please
read the general [basic usage](/docs/providers/basic_usage) page for
read the general [basic usage](/vagrant/docs/providers/basic_usage) page for
providers.
The value to use for the `--provider` flag is `virtualbox`.

6
website/content/docs/providers/vmware/boxes.mdx
View File

@ -8,7 +8,7 @@ description: |-
# Boxes
As with [every Vagrant provider](/docs/providers/basic_usage), the
As with [every Vagrant provider](/vagrant/docs/providers/basic_usage), the
Vagrant VMware providers have a custom box format.
This page documents the format so that you can create your own base boxes.
@ -23,7 +23,7 @@ box. If you are an experienced user of Vagrant and want to create
your own custom boxes, this is for you.
Prior to reading this page, please understand the
[basics of the box file format](/docs/boxes/format).
[basics of the box file format](/vagrant/docs/boxes/format).
## Contents
@ -52,7 +52,7 @@ nvram, vmsd, vmx, vmxf, and vmdk files.
There is also the "metadata.json" file used by Vagrant itself. This file
contains nothing but the defaults which are documented on the
[box format](/docs/boxes/format) page.
[box format](/vagrant/docs/boxes/format) page.
When bringing up a VMware backed machine, Vagrant copies all of the contents
in the box into a privately managed "vmwarevm" folder, and uses the first

2
website/content/docs/providers/vmware/faq.mdx
View File

@ -31,7 +31,7 @@ $ vagrant plugin install vagrant-vmware-desktop
```
To upgrade the Vagrant VMware utility, download the latest version from the
[Vagrant VMware utility downloads page](/vmware/downloads) and install the
[Vagrant VMware utility downloads page](/vagrant/downloads/vmware) and install the
system package to your local system.
## Q: Do I need a license for the Vagrant VMware plugin?

2
website/content/docs/providers/vmware/index.mdx
View File

@ -13,7 +13,7 @@ description: |-
[HashiCorp](https://www.hashicorp.com) develops an official
[VMware Fusion](https://www.vmware.com/products/fusion/overview.html)
and [VMware Workstation](https://www.vmware.com/products/workstation/)&nbsp;
[provider](/docs/providers/) for Vagrant. This provider allows
[provider](/vagrant/docs/providers/) for Vagrant. This provider allows
Vagrant to power VMware based machines and take advantage of the
improved stability and performance that VMware software offers.

4
website/content/docs/providers/vmware/installation.mdx
View File

@ -15,7 +15,7 @@ being managed by Vagrant. Then continue with the instructions below.
Installation of the Vagrant VMware provider requires two steps. First the
Vagrant VMware Utility must be installed. This can be done by downloading
and installing the correct system package from the [Vagrant VMware Utility
downloads page](/vmware/downloads).
downloads page](/vagrant/downloads/vmware).
Next, install the Vagrant VMware provider plugin using the standard plugin
installation procedure:
@ -25,7 +25,7 @@ $ vagrant plugin install vagrant-vmware-desktop
```
For more information on plugin installation, please see the
[Vagrant plugin usage documentation](/docs/plugins/usage).
[Vagrant plugin usage documentation](/vagrant/docs/plugins/usage).
## Upgrading to v1.x

2
website/content/docs/providers/vmware/usage.mdx
View File

@ -9,7 +9,7 @@ description: |-
# Usage
The Vagrant VMware provider is used just like any other provider. Please
read the general [basic usage](/docs/providers/basic_usage) page for
read the general [basic usage](/vagrant/docs/providers/basic_usage) page for
providers.
The value to use for the `--provider` flag is `vmware_desktop`. For compatibility

4
website/content/docs/providers/vmware/vagrant-vmware-utility.mdx
View File

@ -37,7 +37,7 @@ generate the required certificates:
$ sudo /opt/vagrant-vmware-desktop/bin/vagrant-vmware-utility certificate generate
```
The path provided from this command can be used to set the [`utility_certificate_path`](/docs/providers/vmware/configuration#utility_certificate_path) in the Vagrantfile
The path provided from this command can be used to set the [`utility_certificate_path`](/vagrant/docs/providers/vmware/configuration#utility_certificate_path) in the Vagrantfile
configuration if installing to a non-standard path.
Finally, install the service. This will also enable the service.
@ -153,7 +153,7 @@ api {
### API options
- `port` (int) - Port to bind the API (changes require changes to [Vagrant configuration](/docs/providers/vmware/configuration#utility_port))
- `port` (int) - Port to bind the API (changes require changes to [Vagrant configuration](/vagrant/docs/providers/vmware/configuration#utility_port))
- `driver` (string) - Internal driver to use (utility will auto-detect correct driver)
- `license_override` (string) - Override the detected VMware license (standard or professional)

14
website/content/docs/provisioning/ansible.mdx
View File

@ -13,7 +13,7 @@ description: |-
The Vagrant Ansible provisioner allows you to provision the guest using [Ansible](http://ansible.com) playbooks by executing **`ansible-playbook` from the Vagrant host**.
~> **Warning:**
If you are not familiar with Ansible and Vagrant already, we recommend starting with the [shell provisioner](/docs/provisioning/shell). However, if you are comfortable with Vagrant already, Vagrant is a great way to learn Ansible.
If you are not familiar with Ansible and Vagrant already, we recommend starting with the [shell provisioner](/vagrant/docs/provisioning/shell). However, if you are comfortable with Vagrant already, Vagrant is a great way to learn Ansible.
## Setup Requirements
@ -21,11 +21,11 @@ If you are not familiar with Ansible and Vagrant already, we recommend starting
- Your Vagrant host should ideally provide a recent version of OpenSSH that [supports ControlPersist](https://docs.ansible.com/faq.html#how-do-i-get-ansible-to-reuse-connections-enable-kerberized-ssh-or-have-ansible-pay-attention-to-my-local-ssh-config-file).
If installing Ansible directly on the Vagrant host is not an option in your development environment, you might be looking for the [Ansible Local provisioner](/docs/provisioning/ansible_local) alternative.
If installing Ansible directly on the Vagrant host is not an option in your development environment, you might be looking for the [Ansible Local provisioner](/vagrant/docs/provisioning/ansible_local) alternative.
## Usage
This page only documents the specific parts of the `ansible` (remote) provisioner. General Ansible concepts like Playbook or Inventory are shortly explained in the [introduction to Ansible and Vagrant](/docs/provisioning/ansible_intro).
This page only documents the specific parts of the `ansible` (remote) provisioner. General Ansible concepts like Playbook or Inventory are shortly explained in the [introduction to Ansible and Vagrant](/vagrant/docs/provisioning/ansible_intro).
### Simplest Configuration
@ -46,7 +46,7 @@ end
## Options
This section lists the _specific_ options for the Ansible (remote) provisioner. In addition to the options listed below, this provisioner supports the [**common options** for both Ansible provisioners](/docs/provisioning/ansible_common).
This section lists the _specific_ options for the Ansible (remote) provisioner. In addition to the options listed below, this provisioner supports the [**common options** for both Ansible provisioners](/vagrant/docs/provisioning/ansible_common).
- `ask_become_pass` (boolean) - require Ansible to [prompt for a password](https://docs.ansible.com/intro_getting_started.html#remote-connection-information) when switching to another user with the [become/sudo mechanism](http://docs.ansible.com/ansible/become.html).
@ -61,7 +61,7 @@ This section lists the _specific_ options for the Ansible (remote) provisioner.
The default value is `false`.
* `force_remote_user` (boolean) - require Vagrant to set the `ansible_ssh_user` setting in the generated inventory, or as an extra variable when a static inventory is used. All the Ansible `remote_user` parameters will then be overridden by the value of `config.ssh.username` of the [Vagrant SSH Settings](/docs/vagrantfile/ssh_settings).
* `force_remote_user` (boolean) - require Vagrant to set the `ansible_ssh_user` setting in the generated inventory, or as an extra variable when a static inventory is used. All the Ansible `remote_user` parameters will then be overridden by the value of `config.ssh.username` of the [Vagrant SSH Settings](/vagrant/docs/vagrantfile/ssh_settings).
If this option is set to `false` Vagrant will set the Vagrant SSH username as a default Ansible remote user, but `remote_user` parameters of your Ansible plays or tasks will still be taken into account and thus override the Vagrant configuration.
@ -83,7 +83,7 @@ This section lists the _specific_ options for the Ansible (remote) provisioner.
### Ansible Parallel Execution
Vagrant is designed to provision [multi-machine environments](/docs/multi-machine) in sequence, but the following configuration pattern can be used to take advantage of Ansible parallelism:
Vagrant is designed to provision [multi-machine environments](/vagrant/docs/multi-machine) in sequence, but the following configuration pattern can be used to take advantage of Ansible parallelism:
```ruby
# Vagrant 1.7+ automatically inserts a different
@ -120,7 +120,7 @@ If you apply this parallel provisioning pattern with a static Ansible inventory,
you will have to organize the things so that [all the relevant private keys are
provided to the `ansible-playbook` command](https://github.com/hashicorp/vagrant/pull/5765#issuecomment-120247738).
The same kind of considerations applies if you are using multiple private keys
for a same machine (see [`config.ssh.private_key_path` SSH setting](/docs/vagrantfile/ssh_settings)).
for a same machine (see [`config.ssh.private_key_path` SSH setting](/vagrant/docs/vagrantfile/ssh_settings)).
### Force Paramiko Connection Mode

10
website/content/docs/provisioning/ansible_common.mdx
View File

@ -8,8 +8,8 @@ description: This page details the common options to the Vagrant Ansible provisi
The following options are available to both Vagrant Ansible provisioners:
- [`ansible`](/docs/provisioning/ansible)
- [`ansible_local`](/docs/provisioning/ansible_local)
- [`ansible`](/vagrant/docs/provisioning/ansible)
- [`ansible_local`](/vagrant/docs/provisioning/ansible_local)
These options get passed to the `ansible-playbook` command that ships with Ansible, either via command line arguments or environment variables, depending on Ansible own capabilities.
@ -41,7 +41,7 @@ Some of these options are for advanced usage only and should not be used unless
- `config_file` (string) - The path to an [Ansible Configuration file](https://docs.ansible.com/ansible/latest/intro_configuration.html).
By default, this option is not set, and Ansible will [search for a possible configuration file in some default locations](/docs/provisioning/ansible_intro#the-ansible-configuration-file).
By default, this option is not set, and Ansible will [search for a possible configuration file in some default locations](/vagrant/docs/provisioning/ansible_intro#the-ansible-configuration-file).
- `extra_vars` (string or hash) - Pass additional variables (with highest priority) to the playbook.
@ -88,7 +88,7 @@ Some of these options are for advanced usage only and should not be used unless
By default, this option is set to `nil`, which means that the Galaxy roles will be installed in a `roles` subdirectory located in the parent directory of the `playbook` file.
- `groups` (hash) - Set of inventory groups to be included in the [auto-generated inventory file](/docs/provisioning/ansible_intro).
- `groups` (hash) - Set of inventory groups to be included in the [auto-generated inventory file](/vagrant/docs/provisioning/ansible_intro).
Example:
@ -192,4 +192,4 @@ Some of these options are for advanced usage only and should not be used unless
When this option is set to `"latest"`, no version check is applied.
-> **Tip:** With the `ansible_local` provisioner, it is currently possible to use this option
to specify which version of Ansible must be automatically installed, but **only** in combination with the [**`install_mode`**](/docs/provisioning/ansible_local#install_mode) set to **`:pip`**.
to specify which version of Ansible must be automatically installed, but **only** in combination with the [**`install_mode`**](/vagrant/docs/provisioning/ansible_local#install_mode) set to **`:pip`**.

22
website/content/docs/provisioning/ansible_intro.mdx
View File

@ -10,10 +10,10 @@ description: |-
The information below is applicable to both Vagrant Ansible provisioners:
- [`ansible`](/docs/provisioning/ansible), where Ansible is executed on the **Vagrant host**
- [`ansible_local`](/docs/provisioning/ansible_local), where Ansible is executed on the **Vagrant guest**
- [`ansible`](/vagrant/docs/provisioning/ansible), where Ansible is executed on the **Vagrant host**
- [`ansible_local`](/vagrant/docs/provisioning/ansible_local), where Ansible is executed on the **Vagrant guest**
The list of common options for these two provisioners is documented in a [separate documentation page](/docs/provisioning/ansible_common).
The list of common options for these two provisioners is documented in a [separate documentation page](/vagrant/docs/provisioning/ansible_common).
This documentation page will not go into how to use Ansible or how to write Ansible playbooks, since Ansible is a complete deployment and configuration management system that is beyond the scope of Vagrant documentation.
@ -44,7 +44,7 @@ You can of course target other operating systems that do not have YUM by changin
### Running Ansible
The `playbook` option is strictly required by both Ansible provisioners ([`ansible`](/docs/provisioning/ansible) and [`ansible_local`](/docs/provisioning/ansible_local)), as illustrated in this basic `Vagrantfile` configuration:
The `playbook` option is strictly required by both Ansible provisioners ([`ansible`](/vagrant/docs/provisioning/ansible) and [`ansible_local`](/vagrant/docs/provisioning/ansible_local)), as illustrated in this basic `Vagrantfile` configuration:
```ruby
Vagrant.configure("2") do |config|
@ -89,7 +89,7 @@ When using Ansible, it needs to know on which machines a given playbook should r
The first and simplest option is to not provide one to Vagrant at all. Vagrant will generate an inventory file encompassing all of the virtual machines it manages, and use it for provisioning machines.
#### Example with the [`ansible`](/docs/provisioning/ansible) provisioner
#### Example with the [`ansible`](/vagrant/docs/provisioning/ansible) provisioner
```text
# Generated by Vagrant
@ -100,7 +100,7 @@ default ansible_host=127.0.0.1 ansible_port=2200 ansible_user='vagrant' ansible_
Note that the generated inventory file is stored as part of your local Vagrant environment in
`.vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory`.
#### Example with the [`ansible_local`](/docs/provisioning/ansible_local) provisioner
#### Example with the [`ansible_local`](/vagrant/docs/provisioning/ansible_local) provisioner
```text
# Generated by Vagrant
@ -108,11 +108,11 @@ Note that the generated inventory file is stored as part of your local Vagrant e
default ansible_connection=local
```
Note that the generated inventory file is uploaded to the guest VM in a subdirectory of [`tmp_path`](/docs/provisioning/ansible_local), e.g. `/tmp/vagrant-ansible/inventory/vagrant_ansible_local_inventory`.
Note that the generated inventory file is uploaded to the guest VM in a subdirectory of [`tmp_path`](/vagrant/docs/provisioning/ansible_local), e.g. `/tmp/vagrant-ansible/inventory/vagrant_ansible_local_inventory`.
#### Host Variables
As of Vagrant 1.8.0, the [`host_vars`](/docs/provisioning/ansible_common#host_vars) option can be used to set [variables for individual hosts](https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html#assigning-a-variable-to-one-machine-host-variables) in the generated inventory file (see also the notes on group variables below).
As of Vagrant 1.8.0, the [`host_vars`](/vagrant/docs/provisioning/ansible_common#host_vars) option can be used to set [variables for individual hosts](https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html#assigning-a-variable-to-one-machine-host-variables) in the generated inventory file (see also the notes on group variables below).
With this configuration example:
@ -143,7 +143,7 @@ host2 ansible_host=... http_port=303 maxRequestsPerChild=909
#### Groups and Group Variables
The [`groups`](/docs/provisioning/ansible_common#groups) option can be used to pass a hash of group names and group members to be included in the generated inventory file.
The [`groups`](/vagrant/docs/provisioning/ansible_common#groups) option can be used to pass a hash of group names and group members to be included in the generated inventory file.
As of Vagrant 1.8.0, it is also possible to specify [group variables](https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html#assigning-a-variable-to-many-machines-group-variables), and group members as [host ranges (with numeric or alphabetic patterns)](https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html#inventory-basics-formats-hosts-and-groups).
@ -223,7 +223,7 @@ variable2=example
The second option is for situations where you would like to have more control over the inventory management.
With the [`inventory_path`](/docs/provisioning/ansible_common#inventory_path) option, you can reference a specific inventory resource (e.g. a static inventory file, a [dynamic inventory script](https://docs.ansible.com/intro_dynamic_inventory.html) or even [multiple inventories stored in the same directory](https://docs.ansible.com/intro_dynamic_inventory.html#using-multiple-inventory-sources)). Vagrant will then use this inventory information instead of generating it.
With the [`inventory_path`](/vagrant/docs/provisioning/ansible_common#inventory_path) option, you can reference a specific inventory resource (e.g. a static inventory file, a [dynamic inventory script](https://docs.ansible.com/intro_dynamic_inventory.html) or even [multiple inventories stored in the same directory](https://docs.ansible.com/intro_dynamic_inventory.html#using-multiple-inventory-sources)). Vagrant will then use this inventory information instead of generating it.
A very simple inventory file for use with Vagrant might look like:
@ -257,4 +257,4 @@ When shipping an Ansible configuration file it is good to know that:
- `/etc/ansible/ansible.cfg`
- Ansible commands don't look for a configuration file relative to the playbook file location (e.g. in the same directory)
- an `ansible.cfg` file located in the same directory as your `Vagrantfile` will be used by default.
- it is also possible to reference any other location with the [config_file](/docs/provisioning/ansible_common#config_file) provisioner option. In this case, Vagrant will set the `ANSIBLE_CONFIG` environment variable accordingly.
- it is also possible to reference any other location with the [config_file](/vagrant/docs/provisioning/ansible_common#config_file) provisioner option. In this case, Vagrant will set the `ANSIBLE_CONFIG` environment variable accordingly.

18
website/content/docs/provisioning/ansible_local.mdx
View File

@ -14,11 +14,11 @@ description: >-
The Vagrant Ansible Local provisioner allows you to provision the guest using [Ansible](http://ansible.com) playbooks by executing **`ansible-playbook` directly on the guest machine**.
~> **Warning:** If you are not familiar with Ansible and Vagrant already, we recommend starting with the [shell provisioner](/docs/provisioning/shell). However, if you are comfortable with Vagrant already, Vagrant is a great way to learn Ansible.
~> **Warning:** If you are not familiar with Ansible and Vagrant already, we recommend starting with the [shell provisioner](/vagrant/docs/provisioning/shell). However, if you are comfortable with Vagrant already, Vagrant is a great way to learn Ansible.
## Setup Requirements
The main advantage of the Ansible Local provisioner in comparison to the [Ansible (remote) provisioner](/docs/provisioning/ansible) is that it does not require any additional software on your Vagrant host.
The main advantage of the Ansible Local provisioner in comparison to the [Ansible (remote) provisioner](/vagrant/docs/provisioning/ansible) is that it does not require any additional software on your Vagrant host.
On the other hand, [Ansible must obviously be installed](https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html) on your guest machine(s).
@ -26,9 +26,9 @@ On the other hand, [Ansible must obviously be installed](https://docs.ansible.co
## Usage
This page only documents the specific parts of the `ansible_local` provisioner. General Ansible concepts like Playbook or Inventory are shortly explained in the [introduction to Ansible and Vagrant](/docs/provisioning/ansible_intro).
This page only documents the specific parts of the `ansible_local` provisioner. General Ansible concepts like Playbook or Inventory are shortly explained in the [introduction to Ansible and Vagrant](/vagrant/docs/provisioning/ansible_intro).
The Ansible Local provisioner requires that all the Ansible Playbook files are available on the guest machine, at the location referred by the `provisioning_path` option. Usually these files are initially present on the host machine (as part of your Vagrant project), and it is quite easy to share them with a Vagrant [Synced Folder](/docs/synced-folders/).
The Ansible Local provisioner requires that all the Ansible Playbook files are available on the guest machine, at the location referred by the `provisioning_path` option. Usually these files are initially present on the host machine (as part of your Vagrant project), and it is quite easy to share them with a Vagrant [Synced Folder](/vagrant/docs/synced-folders/).
### Simplest Configuration
@ -47,11 +47,11 @@ end
- The `playbook.yml` file is stored in your Vagrant's project home directory.
- The [default shared directory](/docs/synced-folders/basic_usage) is enabled (`.` &rarr; `/vagrant`).
- The [default shared directory](/vagrant/docs/synced-folders/basic_usage) is enabled (`.` &rarr; `/vagrant`).
## Options
This section lists the _specific_ options for the Ansible Local provisioner. In addition to the options listed below, this provisioner supports the [**common options** for both Ansible provisioners](/docs/provisioning/ansible_common).
This section lists the _specific_ options for the Ansible Local provisioner. In addition to the options listed below, this provisioner supports the [**common options** for both Ansible provisioners](/vagrant/docs/provisioning/ansible_common).
- `install` (boolean) - Try to automatically install Ansible on the guest system.
@ -60,8 +60,8 @@ This section lists the _specific_ options for the Ansible Local provisioner. In
Vagrant will try to install (or upgrade) Ansible when one of these conditions are met:
- Ansible is not installed (or cannot be found).
- The [`version`](/docs/provisioning/ansible_common#version) option is set to `"latest"`.
- The current Ansible version does not correspond to the [`version`](/docs/provisioning/ansible_common#version) option.
- The [`version`](/vagrant/docs/provisioning/ansible_common#version) option is set to `"latest"`.
- The current Ansible version does not correspond to the [`version`](/vagrant/docs/provisioning/ansible_common#version) option.
~> **Attention:**
There is no guarantee that this automated installation will replace a custom Ansible setup, that might be already present on the Vagrant box.
@ -73,7 +73,7 @@ This section lists the _specific_ options for the Ansible Local provisioner. In
- On Ubuntu-like systems, the latest Ansible release is installed from the `ppa:ansible/ansible` repository. The compatibility is maintained only for active long-term support (LTS) versions.
- On RedHat-like systems, the latest Ansible release is installed from the [EPEL](http://fedoraproject.org/wiki/EPEL) repository.
- `:pip`: Ansible is installed from [PyPI](https://pypi.python.org/pypi) with [pip](https://pip.pypa.io) package installer. With this mode, Vagrant will systematically try to [install the latest pip version](https://pip.pypa.io/en/stable/installing/#installing-with-get-pip-py). With the `:pip` mode you can optionally install a specific Ansible release by setting the [`version`](/docs/provisioning/ansible_common#version) option.
- `:pip`: Ansible is installed from [PyPI](https://pypi.python.org/pypi) with [pip](https://pip.pypa.io) package installer. With this mode, Vagrant will systematically try to [install the latest pip version](https://pip.pypa.io/en/stable/installing/#installing-with-get-pip-py). With the `:pip` mode you can optionally install a specific Ansible release by setting the [`version`](/vagrant/docs/provisioning/ansible_common#version) option.
Example:

16
website/content/docs/provisioning/basic_usage.mdx
View File

@ -27,13 +27,13 @@ option is what type a provisioner is:
values are `:each` or `:all`, which makes the provisioner run before each and
every root provisioner, or before all provisioners respectively.
**Note**: This option is currently experimental, so it needs to be explicitly
enabled to work. More info can be found [here](/docs/experimental).
enabled to work. More info can be found [here](/vagrant/docs/experimental).
- `after` (string or symbol) - The exact name of an already defined provisioner
that _this_ provisioner should run after. If defined as a symbol, its only valid
values are `:each` or `:all`, which makes the provisioner run after each and
every root provisioner, or before all provisioners respectively.
**Note**: This option is currently experimental, so it needs to be explicitly
enabled to work. More info can be found [here](/docs/experimental).
enabled to work. More info can be found [here](/vagrant/docs/experimental).
* `communicator_required` (boolean) - Specifies the machine must be accessible by
Vagrant in order to run the provisioner. If set to true, the provisioner will
@ -46,7 +46,7 @@ More information about how to use `before` and `after` options can be read [belo
## Configuration
First, every provisioner is configured within your
[Vagrantfile](/docs/vagrantfile/)
[Vagrantfile](/vagrant/docs/vagrantfile/)
using the `config.vm.provision` method call. For example, the Vagrantfile
below enables shell provisioning:
@ -162,8 +162,8 @@ can take over later.
If you define provisioners at multiple "scope" levels (such as globally
in the configuration block, then in a
[multi-machine](/docs/multi-machine/) definition, then maybe
in a [provider-specific override](/docs/providers/configuration)),
[multi-machine](/vagrant/docs/multi-machine/) definition, then maybe
in a [provider-specific override](/vagrant/docs/providers/configuration)),
then the outer scopes will always run _before_ any inner scopes. For
example, in the Vagrantfile below:
@ -193,8 +193,8 @@ an advanced topic that really only becomes useful if you are already
using multi-machine and/or provider overrides. If you are just getting
started with Vagrant, you can safely skip this.
When using features such as [multi-machine](/docs/multi-machine/)
or [provider-specific overrides](/docs/providers/configuration),
When using features such as [multi-machine](/vagrant/docs/multi-machine/)
or [provider-specific overrides](/vagrant/docs/providers/configuration),
you may want to define common provisioners in the global configuration
scope of a Vagrantfile, but override certain aspects of them internally.
Vagrant allows you to do this, but has some details to consider.
@ -269,7 +269,7 @@ VAGRANT_EXPERIMENTAL="dependency_provisioners"
```
Please note that `VAGRANT_EXPERIMENTAL` is an environment variable. For more
information about this flag visit the [Experimental docs page](/docs/experimental/)
information about this flag visit the [Experimental docs page](/vagrant/docs/experimental/)
for more info. Without this flag enabled, provisioners with the `before` and
`after` option will be ignored.

4
website/content/docs/provisioning/cfengine.mdx
View File

@ -16,10 +16,10 @@ The Vagrant CFEngine provisioner allows you to provision the guest using
[CFEngine](https://cfengine.com/). It can set up both CFEngine
policy servers and clients. You can configure both the policy server
and the clients in a single
[multi-machine `Vagrantfile`](/docs/multi-machine/).
[multi-machine `Vagrantfile`](/vagrant/docs/multi-machine/).
~> **Warning:** If you are not familiar with CFEngine and Vagrant already,
it is recommended to start with the [shell provisioner](/docs/provisioning/shell).
it is recommended to start with the [shell provisioner](/vagrant/docs/provisioning/shell).
However, if you are comfortable with Vagrant already, Vagrant is the best way to learn CFEngine.
Let us look at some common examples first. See the bottom of this

4
website/content/docs/provisioning/chef_apply.mdx
View File

@ -19,7 +19,7 @@ Chef ecosystem. Specifically, this documentation page does not cover how use
Chef or how to write Chef recipes.
~> **Warning:** If you are not familiar with Chef and Vagrant already,
we recommend starting with the [shell provisioner](/docs/provisioning/shell).
we recommend starting with the [shell provisioner](/vagrant/docs/provisioning/shell).
## Options
@ -40,7 +40,7 @@ available below this section.
Vagrant to prevent collisions.
In addition to all the options listed above, the Chef Apply provisioner supports
the [common options for all Chef provisioners](/docs/provisioning/chef_common).
the [common options for all Chef provisioners](/vagrant/docs/provisioning/chef_common).
## Specifying a Recipe

6
website/content/docs/provisioning/chef_client.mdx
View File

@ -17,11 +17,11 @@ to an existing Chef Server and registering the Vagrant machine as a
node within your infrastructure.
If you are just learning Chef for the first time, you probably want
to start with the [Chef Solo](/docs/provisioning/chef_solo)
to start with the [Chef Solo](/vagrant/docs/provisioning/chef_solo)
provisioner.
~> **Warning:** If you are not familiar with Chef and Vagrant already,
it is recommended to start with the [shell provisioner](/docs/provisioning/shell).
it is recommended to start with the [shell provisioner](/vagrant/docs/provisioning/shell).
## Authenticating
@ -88,7 +88,7 @@ of these variables.
- `validation_client_name`
In addition to all the options listed above, the Chef Client provisioner supports
the [common options for all Chef provisioners](/docs/provisioning/chef_common).
the [common options for all Chef provisioners](/vagrant/docs/provisioning/chef_common).
## Cleanup

2
website/content/docs/provisioning/chef_common.mdx
View File

@ -78,7 +78,7 @@ understand their purpose.
## Runner Chef Provisioners
The following options are available to any of the Chef "runner" provisioners
which include [Chef Solo](/docs/provisioning/chef_solo), [Chef Zero](/docs/provisioning/chef_zero), and [Chef Client](/docs/provisioning/chef_client).
which include [Chef Solo](/vagrant/docs/provisioning/chef_solo), [Chef Zero](/vagrant/docs/provisioning/chef_zero), and [Chef Client](/vagrant/docs/provisioning/chef_client).
- `arguments` (string) - A list of additional arguments to pass on the
command-line to Chef. Since these are passed in a shell-like environment,

4
website/content/docs/provisioning/chef_solo.mdx
View File

@ -21,7 +21,7 @@ Chef cookbooks, since Chef is a complete system that is beyond the scope
of a single page of documentation.
~> **Warning:** If you are not familiar with Chef and Vagrant already,
it is recommended to start with the [shell provisioner](/docs/provisioning/shell).
it is recommended to start with the [shell provisioner](/vagrant/docs/provisioning/shell).
However, if you are comfortable with Vagrant already, Vagrant
is the best way to learn Chef.
@ -62,7 +62,7 @@ available below this section.
to "nfs" to use NFS synced folders.
In addition to all the options listed above, the Chef Solo provisioner supports
the [common options for all Chef provisioners](/docs/provisioning/chef_common).
the [common options for all Chef provisioners](/vagrant/docs/provisioning/chef_common).
## Specifying a Run List

8
website/content/docs/provisioning/chef_zero.mdx
View File

@ -15,12 +15,12 @@ The Vagrant Chef Zero provisioner allows you to provision the guest using
[Chef Zero/local mode](https://docs.getchef.com/ctl_chef_client.html#run-in-local-mode).
This new provisioner is a middle ground between running a full blown
Chef Server and using the limited [Chef Solo](/docs/provisioning/chef_solo)
Chef Server and using the limited [Chef Solo](/vagrant/docs/provisioning/chef_solo)
provisioner. It runs a local in-memory Chef Server and fakes the validation
and client key registration.
~> **Warning:** If you are not familiar with Chef and Vagrant already,
we recommend starting with the [shell provisioner](/docs/provisioning/shell).
we recommend starting with the [shell provisioner](/vagrant/docs/provisioning/shell).
However, if you are comfortable with Vagrant already, Vagrant
is the best way to learn Chef.
@ -59,12 +59,12 @@ available below this section.
to "nfs" to use NFS synced folders.
In addition to all the options listed above, the Chef Zero provisioner supports
the [common options for all Chef provisioners](/docs/provisioning/chef_common).
the [common options for all Chef provisioners](/vagrant/docs/provisioning/chef_common).
## Usage
The Chef Zero provisioner is configured basically the same way as the Chef Solo
provisioner. See the [Chef Solo documentations](/docs/provisioning/chef_solo)
provisioner. See the [Chef Solo documentations](/vagrant/docs/provisioning/chef_solo)
for more information.
A basic example could look like this:

4
website/content/docs/provisioning/docker.mdx
View File

@ -29,7 +29,7 @@ with the Docker provisioner.
-> **Note:** This documentation is for the Docker
_provisioner_. If you are looking for the Docker _provider_, visit the
[Docker provider documentation](/docs/providers/docker/).
[Docker provider documentation](/vagrant/docs/providers/docker/).
## Options
@ -49,7 +49,7 @@ of these functions have examples in more detailed sections below.
- `pull_images` - Pull the given images. This does not start these images.
- `post_install_provisioner` - A [provisioner block](/docs/provisioning) that runs post docker
- `post_install_provisioner` - A [provisioner block](/vagrant/docs/provisioning) that runs post docker
installation.
- `run` - Run a container and configure it to start on boot. This can

2
website/content/docs/provisioning/file.mdx
View File

@ -78,7 +78,7 @@ _SSH or PowerShell user_. This is important since these users generally
do not have elevated privileges on their own. If you want to upload files to
locations that require elevated privileges, we recommend uploading them
to temporary locations and then using the
[shell provisioner](/docs/provisioning/shell)
[shell provisioner](/vagrant/docs/provisioning/shell)
to move them into place.
## Options

4
website/content/docs/provisioning/index.mdx
View File

@ -11,7 +11,7 @@ description: >-
Provisioners in Vagrant allow you to automatically install software, alter configurations,
and more on the machine as part of the `vagrant up` process.
This is useful since [boxes](/docs/boxes) typically are not
This is useful since [boxes](/vagrant/docs/boxes) typically are not
built _perfectly_ for your use case. Of course, if you want to just use
`vagrant ssh` and install the software by hand, that works. But by using
the provisioning systems built-in to Vagrant, it automates the process so
@ -24,7 +24,7 @@ simple shell scripts to more complex, industry-standard configuration
management systems.
If you've never used a configuration management system before, it is
recommended you start with basic [shell scripts](/docs/provisioning/shell)
recommended you start with basic [shell scripts](/vagrant/docs/provisioning/shell)
for provisioning.
You can find the full list of built-in provisioners and usage of these

2
website/content/docs/provisioning/podman.mdx
View File

@ -46,7 +46,7 @@ of these functions have examples in more detailed sections below.
- `pull_images` - Pull the given images. This does not start these images.
- `post_install_provisioner` - A [provisioner block](/docs/provisioning) that runs post podman
- `post_install_provisioner` - A [provisioner block](/vagrant/docs/provisioning) that runs post podman
installation.
- `run` - Run a container and configure it to start on boot. This can

2
website/content/docs/provisioning/puppet_agent.mdx
View File

@ -17,7 +17,7 @@ calling `puppet agent`, connecting to a Puppet master, and retrieving
the set of modules and manifests from there.
~> **Warning:** If you are not familiar with Puppet and Vagrant already,
it is recommended to start with the [shell provisioner](/docs/provisioning/shell).
it is recommended to start with the [shell provisioner](/vagrant/docs/provisioning/shell).
However, if you are comfortable with Vagrant already, Vagrant
is the best way to learn Puppet.

2
website/content/docs/provisioning/puppet_apply.mdx
View File

@ -15,7 +15,7 @@ The Vagrant Puppet provisioner allows you to provision the guest using
calling `puppet apply`, without a Puppet Master.
~> **Warning:** If you are not familiar with Puppet and Vagrant already,
it is recommended to start with the [shell provisioner](/docs/provisioning/shell).
it is recommended to start with the [shell provisioner](/vagrant/docs/provisioning/shell).
However, if you are comfortable with Vagrant already, Vagrant
is the best way to learn Puppet.

2
website/content/docs/push/index.mdx
View File

@ -55,4 +55,4 @@ $ vagrant push staging
Vagrant Push is the easiest way to deploy your application. You can read more
in the documentation links on the sidebar.
[vagrant providers]: /docs/providers/ 'Vagrant Providers'
[vagrant providers]: /vagrant/docs/providers/ 'Vagrant Providers'

2
website/content/docs/push/local-exec.mdx
View File

@ -74,4 +74,4 @@ $ vagrant push
### Script Arguments
Refer to [Shell Provisioner](/docs/provisioning/shell).
Refer to [Shell Provisioner](/vagrant/docs/provisioning/shell).

Some files were not shown because too many files have changed in this diff Show More