On 30/09/2010 20:21, C Anthony Risinger wrote: > On Thu, Sep 30, 2010 at 8:05 AM, Gordon Henderson<gor...@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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-users > ------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
