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

[Tamas Papp]

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.

Anyway, I still don't see, why it cannot be optional and create containers, that are maybe not 
compatible with lxc-clone.

tamas