libvirt users - Feb 2014 - libvirt_lxc namespace and umount in global namespace

Hi,

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.


Currently, I wanted to test the setns tool to enter the namespace and
umount the mount point. But I am currently on Ubuntu 12.04 with a 3.2.0-59
kernel which does not have /proc/[pid]/ns/mnt
I can't upgrade to 3.8 (which have the proc mnt file) as the drbd tools are
not compatible.

Do you have an idea of what I could try ?

Here I the steps I do to reproduce the issue:
- Mount a drbd file system
- Start a lxc instance with libvirt
- Umount the drbd file system
- Set the drbd resource as secondary. => Does not work

On Thu, Feb 20, 2014 at 01:47:52PM +0100, Olivier Nicaise
wrote:
> Hi,
> 
> 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.
> 
> 
> Currently, I wanted to test the setns tool to enter the namespace and
> umount the mount point. But I am currently on Ubuntu 12.04 with a 3.2.0-59
> kernel which does not have /proc/[pid]/ns/mnt
> I can't upgrade to 3.8 (which have the proc mnt file) as the drbd tools
are
> not compatible.
> 
> Do you have an idea of what I could try ?
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. Can you file a bug about this, so it doesn't get forgotten.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Thanks for your fast feedback!

I created the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1067489




2014-02-20 15:03 GMT+01:00 Daniel P. Berrange <berrange@redhat.com>:
> On Thu, Feb 20, 2014 at 01:47:52PM +0100, Olivier Nicaise wrote:
> > Hi,
> >
> > 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.
> >
> >
> > Currently, I wanted to test the setns tool to enter the namespace and
> > umount the mount point. But I am currently on Ubuntu 12.04 with a
> 3.2.0-59
> > kernel which does not have /proc/[pid]/ns/mnt
> > I can't upgrade to 3.8 (which have the proc mnt file) as the drbd
tools
> are
> > not compatible.
> >
> > Do you have an idea of what I could try ?
>
> 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. Can you file a bug about this, so it doesn't get forgotten.
>
> Daniel
> --
> |: http://berrange.com      -o-   
http://www.flickr.com/photos/dberrange/:|
> |: http://libvirt.org              -o-            
http://virt-manager.org:|
> |: http://autobuild.org       -o-        
http://search.cpan.org/~danberr/:|
> |: http://entangle-photo.org       -o-      
http://live.gnome.org/gtk-vnc:|
>