Bug 1067489

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.