Description of problem: I am currently having an issue with the libvirt_lxc binary that is launched when starting a lxc instance using libvirt. This process seems to have its own namespace for mounts. What happens is that if I umount something in the global namespace, it stays mounted in the libvirt_lxc namespace. I'm working with drbd, and after unmounting the mount point, I want to change the state of the drbd resource as Secondary. But if fails. Indeed, libvirt_lxc has still the resource which is mounted in its namespace. Version-Release number of selected component (if applicable): 1.1.1 How reproducible: Everytime Steps to Reproduce: - Mount a drbd file system - Start a lxc instance with libvirt (which does not involve the drbd file system mounted in point 1) - Umount the drbd file system - Set the drbd resource as secondary. => Does not work I think it should also fail with other device types that can be unloaded but I did not test it (LVM, loop devices,...) Expected results: Drbd resource successfully changes state to secondary Additional info: Confirmed as a bug by Daniel P. Berrange on the user mailing list: Ahh, interesting scenario that I'd not considered. With LXC there are in fact 3 mounts namespaces in play - The host OS namespace - The libvirt_lxc namespace - The actual container namespace The libvirt_lxc namespace is basically the same as the host namespace, but with the addition of a devpts for the container's /dev/pts. We explicitly don't allow dynamic changes to propagate from the host OS to the container namespace, however, it sounds like we *should* allow host OS changes to propagage to the libvirt_lxc process namespace.
Sorry this bug never received a response Olivier. Do you know if this is still relevant with newer libvirt?
Since there's no response, closing as DEFERRED. But if anyone is still affected with newer libvirt versions, please re-open and we can triage from there