[lxc-devel] [PATCH 2/2] lxc.container.conf: document the type: lxc.rootfs conventions

[Michael H. Warfield]

On Thu, 2014-05-15 at 15:28 +0000, Serge Hallyn wrote:
> Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > On Thu, 2014-05-15 at 14:33 +0000, Serge Hallyn wrote:
> > > Signed-off-by: Serge Hallyn <serge.hallyn at ubuntu.com>
> > > ---
> > >  doc/lxc.container.conf.sgml.in | 14 ++++++++++++++
> > >  1 file changed, 14 insertions(+)
> > 
> > > diff --git a/doc/lxc.container.conf.sgml.in b/doc/lxc.container.conf.sgml.in
> > > index 6e96889..39de1cc 100644
> > > --- a/doc/lxc.container.conf.sgml.in
> > > +++ b/doc/lxc.container.conf.sgml.in
> > > @@ -876,6 +876,20 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
> > >  	      specified, the container shares its root file system
> > >  	      with the host.
> > >  	    </para>
> > > +	    <para>
> > > +          For directory or simple block-device backed containers,
> > > +          a pathname can be used.  If the rootfs is backed by a nbd
> > > +          device, then <filename>nbd:file:1</filename> specifies that
> > > +          <filename>file</filename> should be attached to a nbd device,
> > > +          and partition 1 should be mounted as the rootfs.
> > > +          <filename>nbd:file</filename> specifies that the nbd device
> > > +          itself should be mounted.  <filename>overlayfs:/lower:/upper</filename>
> > > +          specifies that the rootfs should be an overlay with <filename>/upper</filename>
> > > +          being mounted read-write over a read-only mount of <filename>/lower</filename>.
> > > +          <filename>aufs:/lower:/upper</filename> does the same using aufs in place
> > > +          of overlayfs. <filename>loop:/file</filename> tells lxc to attach
> > > +          <filename>/file</filename> to a loop device and mount the loop device.
> > > +	    </para>
> > >  	  </listitem>
> > >  	</varlistentry>
> > >  
> > > -- 
> > > 1.9.1
> > 
> > I may be off base here but, does this relate to that exchange on the
> > -users list a couple of weeks ago about the Fedora template and an lvm
> > backing store?
> 
> No, don't really recall that exchange.

From: Flo <florian.engelmann at gmail.com>
Date: Thu, 8 May 2014 08:54:57 +0200 (05/08/2014 02:54:57 AM)
Subject: Re: [lxc-users] Fedora 20 template on LVM not working

is the Fedora template currently broken? I tried to create a LVM based Fedora 20 container but it looks like the template gets confused with lvm...

lxc-create -n ipa01-test -B lvm --vgname=lxc1 --fssize=30G --thinpool thin_pool -t fedora -- --release 20

... [SNIP] ...

Copy /var/cache/lxc/fedora/x86_64/20/rootfs to /dev/lxc1/ipa01-test ... 
Copying rootfs to /dev/lxc1/ipa01-test ...mkdir: cannot create directory ‘/dev/lxc1/ipa01-test’: File exists
rsync: ERROR: cannot stat destination "/dev/lxc1/ipa01-test/": Not a directory (20)
rsync error: errors selecting input/output files, dirs (code 3) at main.c(652) [Receiver=3.1.0]

Looks like it was trying to do an rsync straight to the lvm device and
hurling chunks.

You suggested adding some echos to the template, which I just set up but
I get different errors mostly due to my setup.  I've never used an lvm
backing store.

The OP has not gotten back to us.

Regards,
Mike



> > Or is that one of these "simple block-device backed"
> > things?  The OP never got back with us and I haven't tried testing it
> > myself.
> 
> Not sure what you are referring to.  This is just something that is nice
> to have so that users can download a qcow2 image like
> http://cloud-images.ubuntu.com/utopic/current/utopic-server-cloudimg-amd64-disk1.img
> and use it without having to convert it.
> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel
> 

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20140515/39625009/attachment-0001.sig>