You're getting multiple DMAR errors. That's related to your IOMMU setup, which would be affected if you're turning VT on and off in the BIOS.  That's not really LVM so much as it is something trying to remap your storage device's PCI link after the filesystem was mounted. (Whether by LVM, systemd, mount cmd from the terminal, etc.) Which will cause the underlying block device to become unresponsive. Even worse, it can make the FS get stuck unmounting and prevent a reboot from succeeding after all of the consoles have been killed. Requiring someone to power cycle the machine manually if it cannot be fenced via some power distribution unit. (Speaking from experience here...) As for the issue itself, there's a couple of things you can try: Try booting the machine in question with "intel_iommu=on iommu=pt" on the kernel command line. That will put the IOMMU in passthrough mode which may help. Try moving the physical drives to a different port on the motherboard. Some boards have different IOMMU groups for different ports even if they are of the same kind. Regardless if it's AHCI / M.2 / etc. If you have a real PCI RAID expansion card or something similar, you could try checking the PCI link id it's using and moving it to another link that does work. (Plug it into another PCI slot so it gets a different IOMMU group assignment.) If you're willing to spend money, maybe try getting a PCI AHCI / RAID expansion card if you don't have one. That would at least give you more options if you cannot move the drives to a different port. Long term, the best option would be to move those gluster bricks to another host that isn't acting as a VM hypervisor. These kinds of bugs can crop up with kernel updates, and as the kernel's IOMMU support is still kinda iffy, production-wise it's better to avoid the issue entirely. -Patrick Hibbs On Wed, 2022-02-02 at 12:51 +0000, Strahil Nikolov via Users wrote: