To Reproduce Steps to reproduce the behavior:

1. Create the libvirt-secret secret with correct structure, and a password of length 60
2. Deploy RHOSO as usual, with minimum two computes
3. Once deployed, connect to one compute
4. sudo -i to become root
5. list VMs on the second compute using virsh -c qemu+tls://SECOND_COMPUTE/system list
6. See the Authentication failure

Expected behavior

 Id   Name   State
--------------------

Bug impact
I hit the issue with a 60-char password, but I don't know what's the actual threshold.

A customer may have specific policies for password length, and they may have to use length over the undocumented limitation.

The authentication failure leads to nova migration issues. In addition, such an error doesn't seem to be properly reported in the console (I'll open another issue).

Known workaround

• I could get it passing with a 16-char password

Additional context

• the issue is located in the way /etc/libvirt/passwd.db is filled[1]
• /etc/libvirt/auth.conf has the correct password with all of the 60 chars
• all .conf files in both /etc/sasl2 and /etc/libvirt have matching sha256sum on both nodes
• manually setting the 60-char password in SASL had it passing, leading to the thoughts about initial password tempering over the configuration steps

*Note*: I'm not sure about the actual component. I couldn't trace back the way the password was injected in the container. I don't know exactly what step was tempering with it either.

[1] https://github.com/openstack-k8s-operators/edpm-ansible/blob/d1270253d8093b2188e57677f55b6e99e6fcf202/roles/edpm_libvirt/tasks/configure.yml#L77-L82