# LVM facts don't include all LVs and VGs **URL:** \ **Category:** Get Help\ **Tags:** breaking-changes, facts, linux\ **Created:** [June 13, 2026, 2:38pm UTC](https://forum.ansible.com/t/lvm-facts-dont-include-all-lvs-and-vgs/45914 "2026-06-13T14:38:03Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![ProfessorLogout](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/professorlogout/32/7564_2.png) [@ProfessorLogout](https://forum.ansible.com/u/ProfessorLogout)\ **Post date:** [June 13, 2026, 2:38pm UTC](https://forum.ansible.com/t/lvm-facts-dont-include-all-lvs-and-vgs/45914/1 "2026-06-13T14:38:03Z")
Hello all, sharing this here in parts to have it recorded somewhere and in other parts to get some feedback from the community. I’ve spent a bunch of effort deep in Ansible trying to optimize the time it takes to gather facts on linux systems recently, more on that in a later post once I polished up some things. While testing some performance improvements I noticed a bug in the way `lvs` and `vgs` facts are generated into the `lvm` fact. Ansible treats the names of both of them as globally unique, which is unfortunately not true. They are only guaranteed to be unique in relation to their parent `vg` and `pv` respectively. In effect this leads to the resulting fact not containing all `lvs` or `vgs` as the last one (as determined by default sort order) always overwrites the previous one(s). Believing this to be both a bug and a breaking change if it were to be fixed I headed over to the issue tracker and apparently this issue was already identified quite a while ago in 2020. [https://github.com/ansible/ansible/issues/71041](https://github.com/ansible/ansible/issues/71041) Unfortunately no work happened on it back then, which either means no one is really affected by this bug or all parties affected are working around this in private. So I guess my real question is this: Have you ever been bitten by this bug in your environment and if yes, are you maintaining a local workaround? Ps: The code changes to make these facts behave more in-line with the underlying reality are not complex and I’d be happy to provide them - But the factual breaking behavior change is a very different story, which I do not feel comfortable without upfront discussions and guidance from someone more experienced in Ansible core development. ---
**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\ **Post date:** [June 13, 2026, 3:36pm UTC](https://forum.ansible.com/t/lvm-facts-dont-include-all-lvs-and-vgs/45914/2 "2026-06-13T15:36:59Z")
I’ve been giving this a lot of thought, but I don’t have a good solution: - make this part of a larger project to phase out setup.py and move to new modules `ansible_lvm_facts` for this case, which would use a proper return schema that does match reality. - change the current schema to allow for lists, this is still backwards incompatible, but will only affect those with this exact issue, then they can test for list existence as way to find the multiple matches. - add a new root to the existing schema that deals with a hierarchical version of the same data. - create unique numbered entries with ‘real\_name’ key underneath Every option has different pro/cons and I’m not sure there is a clear winner. ---
**Author:** ![ProfessorLogout](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/professorlogout/32/7564_2.png) [@ProfessorLogout](https://forum.ansible.com/u/ProfessorLogout)\ **Post date:** [June 15, 2026, 7:16am UTC](https://forum.ansible.com/t/lvm-facts-dont-include-all-lvs-and-vgs/45914/3 "2026-06-15T07:16:57Z")
Having thought along these lines as well I’d personally prefer a “schema fix”, though handled properly given it’s of course a break in schema. Unrelated to this I was thinking it would be easy to emit a warning in the code when the current behavior overwrites data, which might be helpful a) to estimate how many users are actually affected and b) help people like might stumbling across this and figuring it out on their own. I’m not 100% sure how the project thinks on emitting such warnings, but I’d be happy to propose such a change to the code base directly. ---
**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\ **Post date:** [June 15, 2026, 7:35pm UTC](https://forum.ansible.com/t/lvm-facts-dont-include-all-lvs-and-vgs/45914/4 "2026-06-15T19:35:09Z")
I think warning is fine, the schema change, depends on which one, I do have issues with if breaks current usage for a good chunk of users. ---
**Author:** ![ProfessorLogout](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/professorlogout/32/7564_2.png) [@ProfessorLogout](https://forum.ansible.com/u/ProfessorLogout)\ **Post date:** [June 29, 2026, 7:39pm UTC](https://forum.ansible.com/t/lvm-facts-dont-include-all-lvs-and-vgs/45914/5 "2026-06-29T19:39:35Z")
I went ahead and opened a PR to that effect 🙂 > > > \##### SUMMARY > > LinuxHardware.get\_lvm\_facts() silently overwrites data for: > > …- VGs, if multiple VGs with the same name exist across PVs > \- LVs, if multiple LVs with the same name exist across VGs > > This change does not change this behavior, > it does add a WARN log if this overwrite happened during fact collection. > > See also previous discussions in https://forum.ansible.com/t/lvm-facts-dont-include-all-lvs-and-vgs/45914 > and issue #71041 > > \##### ISSUE TYPE > > \- Bugfix Pull Request