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

[Stéphane Graber]

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).

> 
> tamas



-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130423/9803590b/attachment.pgp>