[lxc-devel] [PATCH 1/1] lxc-create: add zfs support

[Serge Hallyn]

Quoting Stéphane Graber (stgraber at ubuntu.com):
> On 04/23/2013 10:41 PM, Tamas Papp wrote:
> > On 04/23/2013 09:59 PM, Stéphane Graber wrote:
> >> On 04/23/2013 01:28 AM, Serge Hallyn wrote:
> >>> Quoting Stéphane Graber (stgraber at ubuntu.com):
> >>>> I'm not a big user of lxc-clone (yet) but I think as we redesign that
> >>>> part of the code, consistency across backend should be a primary goal
> >>>> even if that causes some slight changes in behaviour from previous
> >>>> implementations.
> >>>
> >>> Ok it finally dawned on me that if we want consistency, then we can't
> >>> do it the new way.  LVM backed containers are the primary counter
> >>> example.  To have $lxc_path/$lxc_name be lvm-backed would require
> >>> the LV to be mounted at host boot.
> >>>
> >>> So what I'm going to do is implement a few more backing stores and
> >>> a tiny temporary toy lxc-clone c program for easier testing, with
> >>> zfs for now switched to only its rootfs being a separate zfs unit.
> >>> We can't decide to switch all backing stores to the other way, but
> >>> if we decide to later support zfs and btrfs having $lxcpath/$lxcname
> >>> be separate units/subvolumes, it shouldn't be a big deal to special
> >>> case that and support both.  But I'd rather not complicate what I'm
> >>> doing with that now.
> >>>
> >>> -serge
> >>
> >> I'm perfectly happy with only the rootfs being on a separate backend.
> >>
> >> Technically all block based backends (lvm, qcow2, raw disk image, ...)
> >> will require that anyway. The only two cases where that's not
> >> necessarily true is zfs and btrfs as those two aren't blocks but fs
> >> sub-volumes and so effectively visible as directories and don't require
> >> explicit mounting to be accessible.
> > 
> > Why does LVM require that? As I understand, only image based setups do.
> > Or you mean rootfs will be specified as a block device? I think it's
> > possible with btrfs and zfs as well.
> 
> If we don't set the block device as lxc.rootfs, then the host has to
> mount the LVM outside of the container's mount namespace, which we
> prefer not to have to do, especially as you get into a chicken and egg
> problem where the LVM path is set in the file that's stored on an
> unmounted LVM partition :)
> 
> > Anyway, I still don't see, why it cannot be optional and create
> > containers, that are maybe not compatible with lxc-clone.
> 
> We won't prevent you from putting your container on whatever storage you
> want and setting lxc.rootfs to a standard fs path. That'll still work,
> it's just that clone won't detect it's LVM backed and so won't create a
> new LV (instead it'll just create a new entry under /var/lib/lxc and
> rsync the content).

In fact it shouldn't be much work to add automatic detection of that
at clone - i just see that as a special case and so want to wait to add
it to the api clone until the harder stuff is done.

My main question was what to do for the general case, and so the answer
is that the lxc.rootfs being a blockdev or btrfs subvolume or overlayfs
is going to be the normal case.  (overlayfs is another case which would
nto do well with $lxc_npath/$lxc_name being the overlay, because it
leaves no good place to put the delta directory)

thanks,
-serge