debops.libvirt role is designed to use your normal admin account instead of
root account for managing
libvirt via it's API. That way Ansible can
access your own SSH keys through ssh-agent if necessary to connect to the
remote libvirtd instances.
You should still use
debops.libvirt with the
become: True option in your
playbooks, it will automatically run tasks unprivileged when needed.
Because an unprivileged account is used, the role won't work correctly if that
account does not belong to the
libvirt group. On the Ansible Controller this
requires that the user needs to log out and back in before the new group takes
effect. This role will check if the required group is present and won't run
libvirt tasks otherwise to not stop the playbook unnecessarily.
Use via local connection¶
debops.libvirt will try to connect to a libvirtd system
localhost. Your user should be in the
libvirt system group
to be able to do this. The
debops.libvirtd role configures this automatically.
Network and storage pool configuration without specified
applies to default connection. If your main libvirtd daemon is on
a different host, you can change the default connection using the
Use via remote connections¶
You can use
debops.libvirt from your Ansible Controller host to centrally
configure libvirtd instances on remote hosts.
libvirt__connections dict variable to specify libvirt URI connections
with aliases, they will be configured in
the account you use to run Ansible. After that, in each network or storage pool
item.uri parameter with the name of the connection to use for
To run this role directly on libvirtd servers, they should be included
[debops_libvirt] Ansible group:
If you want to use this role on your Ansible Controller, put it in the same group as well:
[debops_service_libvirt] hostname ansible_connection=local
Here's an example playbook which uses the
--- - name: Manage libvirt hosts hosts: [ 'debops_service_libvirt' ] become: True roles: - role: debops.libvirt tags: [ 'role::libvirt' ]