hashicorp/vagrant · error · VagrantPlugins::Ansible::Errors.AnsibleVersionMismatch
The requested Ansible version (%{required_version}) was not
Error message
The requested Ansible version (%{required_version}) was not found on the %{system}.
Please check the Ansible installation on your Vagrant %{system} system (currently: %{current_version}),
or adapt the provisioner `version` option in your Vagrantfile.
See https://docs.vagrantup.com/v2/provisioning/ansible_common.html#version
for more information. What it means
For host-mode ansible provisioning, after resolving compatibility mode Vagrant compares config.version (when set and not :latest) with the ansible version detected on the host (via python importlib.metadata). Any difference raises AnsibleVersionMismatch. This guards against silently running playbooks with a different ansible than the Vagrantfile was written against.
Source
Thrown at plugins/provisioners/ansible/provisioner/host.rb:53
VAGRANT_ARG_SEPARATOR = 'VAGRANT_ARG_SEP'
def warn_for_unsupported_platform
if Vagrant::Util::Platform.windows?
@machine.env.ui.warn(I18n.t("vagrant.provisioners.ansible.windows_not_supported_for_control_machine") + "\n")
end
end
def check_ansible_version_and_compatibility
# This step will also fetch the Ansible version data into related instance variables
set_and_check_compatibility_mode
# Skip this check when not required, nor possible
if !@gathered_version || config.version.empty? || config.version.to_s.to_sym == :latest
return
end
if config.version != @gathered_version
raise Ansible::Errors::AnsibleVersionMismatch,
system: @control_machine,
required_version: config.version,
current_version: @gathered_version
end
end
def prepare_command_arguments
# Connect with native OpenSSH client
# Other modes (e.g. paramiko) are not officially supported,
# but can be enabled via raw_arguments option.
@command_arguments << "--connection=ssh"
# Increase the SSH connection timeout, as the Ansible default value (10 seconds)
# is a bit demanding for some overloaded developer boxes. This is particularly
# helpful when additional virtual networks are configured, as their availability
# is not controlled during vagrant boot process.
@command_arguments << "--timeout=30"
View on GitHub (pinned to 35f3160f4a)
Solutions
- Change `ansible.version` to the host's actual version, or set it to "latest" (host mode relies on the host install)
- Or install exactly the pinned version on the host (pipx/pip: `pipx install ansible==<version>`)
- Check which copy is detected: `python3 -c "import importlib.metadata; print(importlib.metadata.version('ansible'))"` with vagrant's environment
- Coordinate the pin across the team via a shared requirements file for the host
Example fix
# Vagrantfile — before (host runs 8.6.1) ansible.version = "2.9.9" # after ansible.version = "latest"
Defensive patterns
Strategy: validation
Validate before calling
installed = `python3 -c "import importlib.metadata; print(importlib.metadata.version('ansible'))" 2>/dev/null`.to_s
required = '2.9.9' # the value you plan to set in the Vagrantfile
abort 'host ansible != pinned version' unless required == 'latest' || required == installed.sub('ansible ', '') Type guard
def host_ansible_version_matches?(required)
v = `python3 -c "import importlib.metadata; print(importlib.metadata.version('ansible'))" 2>/dev/null`.to_s.strip
required.to_s == 'latest' || required.to_s == v
end Prevention
- Pin host ansible via pipx/venv in a bootstrap script rather than assuming a system version
- Or leave ansible.version unset/"latest" for host-mode provisioning
When it happens
Trigger: check_ansible_version_and_compatibility during `vagrant provision`/`up`: @gathered_version present, config.version non-empty and != :latest, and config.version != @gathered_version — e.g. version "2.9.9" pinned while the host has 2.9.27, or version pinned for guest-style installs while the host manages its own ansible.
Common situations: Team members with different host ansible versions sharing a pinned Vagrantfile; host ansible upgraded by brew/pip between runs; multiple pythons — vagrant probes one interpreter while PATH's `ansible` comes from another.
Related errors
- The requested Ansible version (%{required_version}) was not
- Ansible failed to complete successfully. Any error output sh
- `%{config_option}` does not exist on the %{system}: %{path}
- The requested Ansible compatibility mode (%{compatibility_mo
- Ansible Provisioner Programming Error: %{message} Internal
AI-assisted analysis of hashicorp/vagrant@35f3160f4a (2026-08-21).
Data as JSON: /api/errors/b132635296c6383b.
Report an issue: GitHub.