[Lxc-users] Container Filesystem in a file (loopback mount)

[Andy Billington]

On 30/09/2010 20:21, C Anthony Risinger wrote:
> On Thu, Sep 30, 2010 at 8:05 AM, Gordon Henderson<gordon at drogon.net>  wrote:
>    
>> On Thu, 30 Sep 2010, Daniel Lezcano wrote:
>>
>>      
>>> On 09/30/2010 11:04 AM, Gordon Henderson wrote:
>>>        
>>>> Looking to put "hard" limits on a containers filesystem size by creating a
>>>> fixed-length file, putting a filesystem in it, loopback mounting it, then
>>>> using that as the containers root ...
>>>>
>>>> I've not tried it yet, but wondering if anyone has done anything like
>>>> this? Any pitfalls? (Other than maybe performance)
>>>>          
>>> Yep, I tried, no problem.
>>>        
>> Great.
>>
>>      
>>> In a near future, we will be able to specify directly the image in
>>> lxc.rootfs. The code doing that is ready but there are some problems with the
>>> consoles I have to fix before.
>>>        
>> Sounds good, thanks!
>>      
> in the past i used a btrfs filesystem, and put each system in a
> subvolume; this let me create templates that were instantly cloneable,
> and able to run within seconds.
>
> IIRC, you can't do this right now, but soon you will be able to place
> quotas on the subvolumes.  also, you can snapshot them the make a
> backup instantly.  just a suggestion, it worked extremely well.
>
> C Anthony
>
>    
I've been experimenting with btrfs and cloning this afternoon; once I'd 
got over an unrecoverable btrfs error and loss of all test data, it 
worked fairly smoothly. I wasn't using subvolumes or playing with quotas 
though, so not sure that helps this discussion :) With a few bits of 
easy scripting, creating new systems and starting them up was taking 
tens of  seconds; backups quicker - on a desktop PC, with the LXC host 
running inside a VMware virtual machine. The experience of losing an 
entire filesystem due to a btrfs fault though means I don't think it's a 
sensible route to take at this point .......

One thing that worked way better in the past, that I haven't had a 
chance to do today, was iSCSI-presented ZFS volumes from a Solaris host; 
that worked just fine with quotas and thin provisioning, no problem at 
all. Maybe when btrfs is usable it'll be possible to do the same sort of 
thing; right now, no way. When iSCSI can be presented directly and 
seamlessly from btrfs and when there is documentation, I can probably 
persuade the customer to take it as an option. The application I'm 
testing is a hybrid; some containers will have real jobs to do, some 
will be experimental only - I might try putting the 'real' ones on a 
sensible filesystem and the experimentals on btrfs, then trying to make 
the case for that if I'm happy. I'll try to apply some quota-ing while 
I'm testing that, might be a couple of days though.

Andy

> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Lxc-users mailing list
> Lxc-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-users
>