Re: [Lxc-users] Container Filesystem in a file (loopback mount)
> Sorry, I pulled .38 out of my arse; I didn't mean to imply it was a > meaningful number. > I would be happy if it becomes stable by your other guess. I mean ubuntu 12-04. We shall see. John -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Container Filesystem in a file (loopback mount)
John Drescher writes: >> btrfs isn't stable. When it is, you'll need that kernel (e.g. 2.6.38), >> not just a new btrfs-tools userland. So basically for production you >> should just be waiting until 12.04 LTS. > > I would expect it to be 2.6.42 to 2.6.46. Since 2.6.38 is just 3 months away. Sorry, I pulled .38 out of my arse; I didn't mean to imply it was a meaningful number. -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Container Filesystem in a file (loopback mount)
> btrfs isn't stable. When it is, you'll need that kernel (e.g. 2.6.38), > not just a new btrfs-tools userland. So basically for production you > should just be waiting until 12.04 LTS. I would expect it to be 2.6.42 to 2.6.46. Since 2.6.38 is just 3 months away. John -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Container Filesystem in a file (loopback mount)
Andy Billington writes: > Btrfs-tools says 0.19 as that's what came in from the apt-get. Maybe > newer btrfs versions may work better, but until they "qualify" for an > apt-get in Ubuntu LTS, they aren't options. btrfs-tools version is largely irrelevant, it's a tiny C wrapper to generate appropriate syscalls -- all the smarts are in the kernel itself. $ rmadison -uubuntu,debian btrfs-tools ubuntu: btrfs-tools | 0.8-1 | hardy/universe | source, amd64, i386 btrfs-tools | 0.18-3 | jaunty/universe | source, amd64, i386 btrfs-tools | 0.19-3 | karmic/universe | source, amd64, i386 btrfs-tools | 0.19-8 | lucid/universe | source, amd64, i386 btrfs-tools | 0.19+20100601-3 | maverick | source, amd64, i386 btrfs-tools | 0.19+20100601-3 | natty | source, amd64, i386 debian: btrfs-tools | 0.19+20100601-3 | squeeze | source, amd64, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc btrfs-tools | 0.19+20100601-3 | sid | source, alpha, amd64, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc btrfs-tools | 0.19+20101101-1 | experimental | source, alpha, amd64, armel, i386, ia64, mips, mipsel, powerpc, s390, sparc > ZFS on the other hand has been rock solid in testing in this and other > scenarios for two years, so the problems I've had are not LXC related, > they are btrfs problems with the current LTS version of btrfs. Maybe > someone can get look at getting that upgraded, if there is a stable > release? But, as I said, digressing btrfs isn't stable. When it is, you'll need that kernel (e.g. 2.6.38), not just a new btrfs-tools userland. So basically for production you should just be waiting until 12.04 LTS. -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Container Filesystem in a file (loopback mount)
On Thu, Sep 30, 2010 at 4:22 PM, Andy Billington wrote: > In terms of what I was doing to destroy the file system, I think I can > summarise it for you. No running containers, no open files on filesystem and > no processes even looking at it apart from mount. Run a du -h against it to > check something, crash. > > Btrfs-tools says 0.19 as that's what came in from the apt-get. Maybe newer > btrfs versions may work better, but until they "qualify" for an apt-get in > Ubuntu LTS, they aren't options. ZFS on the other hand has been rock solid > in testing in this and other scenarios for two years, so the problems I've > had are not LXC related, they are btrfs problems with the current LTS > version of btrfs. Maybe someone can get look at getting that upgraded, if > there is a stable release? But, as I said, digressing ah, right, i forget that i use Archlinux for everything (i'm not a host :-), so i'm always running the brandest new spankiest kernels, and i build the btrfs tools from git into a native Arch package. but yes, i would not recommend using it on .32, was only declared ready for [very] early adopters at that point :-D C Anthony -- 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
Re: [Lxc-users] Container Filesystem in a file (loopback mount)
On 30/09/2010 22:26, John Drescher wrote: > I am interested in using btrfs for my containers but I am thinking its > too experimental to use in a work production environment. > > >> Btrfs-tools says 0.19 as that's what came in from the apt-get. Maybe >> newer btrfs versions may work better, but until they "qualify" for an >> apt-get in Ubuntu LTS, they aren't options. ZFS on the other hand has >> been rock solid in testing in this and other scenarios for two years, so >> the problems I've had are not LXC related, they are btrfs problems with >> the current LTS version of btrfs. Maybe someone can get look at getting >> that upgraded, if there is a stable release? But, as I said, digressing >> >> > You mean zfs or zfs-fuse? > > John > ZFS from a Solaris host, either using NFS or iSCSI, worked just fine. Also tried OpenSolaris, worked ok although some initial issues with the combination of Crossbow networking, iSCSI and ZFS, but once through those it was rock solid, even worked seamlessly clustered. In lots of ways it's sad to see OpenSolaris go - while one could use the best bits of each to do the appropriate job, the combination of Linux and OpenSolaris is a fairly strong one. I hope one or more of the supposed follow-ons to OpenSol works out ... -- 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
Re: [Lxc-users] Container Filesystem in a file (loopback mount)
I am interested in using btrfs for my containers but I am thinking its too experimental to use in a work production environment. > Btrfs-tools says 0.19 as that's what came in from the apt-get. Maybe > newer btrfs versions may work better, but until they "qualify" for an > apt-get in Ubuntu LTS, they aren't options. ZFS on the other hand has > been rock solid in testing in this and other scenarios for two years, so > the problems I've had are not LXC related, they are btrfs problems with > the current LTS version of btrfs. Maybe someone can get look at getting > that upgraded, if there is a stable release? But, as I said, digressing > You mean zfs or zfs-fuse? John -- 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
Re: [Lxc-users] Container Filesystem in a file (loopback mount)
On 30/09/2010 22:10, C Anthony Risinger wrote: > On Thu, Sep 30, 2010 at 3:21 PM, Daniel Lezcano > wrote: > >> On 09/30/2010 09:50 PM, Andy Billington wrote: >> >>> On 30/09/2010 20:21, C Anthony Risinger wrote: >>> >>> On Thu, Sep 30, 2010 at 8:05 AM, Gordon Henderson 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 ... >>> >>> >> Yeah, btrfs is still experimental. In the past, I did the same as >> Anthony without visible problems but when I tried recently I crashed my >> filesystem too. I am very impatient to see btrfs more mature because it >> looks very promising. >> > yeah i guess i wouldn't use it for clients at this point, but with > build in raid/compression/etc. its a really sweet deal when combined > w/LXC, so something to keep in mind, as i don't think it will be long > until you will start seeing it everywhere. > > in my case i was running several personal containers, and other > temporary stuff. btrfs made excellent use of the disk space, as every > dom was COW'ed from a template. > > while developing some tools to quickly create containers, i literally > created and destroyed hundreds of containers (btrfs) without problems. > i also use it on several machines, including this laptop, which has > had a btrfs / since .31, again without any issue whatsoever. > > i'm digressing though, but i don't know what people are doing to > destroy their filesystems as i have done a tremendous amount of work > and tinkering, and have yet to ruin one... maybe i'm just lucky though > :-). the btrfs list is pretty quiet; i think most are using it rather > successfully. > > C Anthony > Also digressing, but: In terms of what I was doing to destroy the file system, I think I can summarise it for you. No running containers, no open files on filesystem and no processes even looking at it apart from mount. Run a du -h against it to check something, crash. Btrfs-tools says 0.19 as that's what came in from the apt-get. Maybe newer btrfs versions may work better, but until they "qualify" for an apt-get in Ubuntu LTS, they aren't options. ZFS on the other hand has been rock solid in testing in this and other scenarios for two years, so the problems I've had are not LXC related, they are btrfs problems with the current LTS version of btrfs. Maybe someone can get look at getting that upgraded, if there is a stable release? But, as I said, digressing -- 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
Re: [Lxc-users] Container Filesystem in a file (loopback mount)
On Thu, Sep 30, 2010 at 3:21 PM, Daniel Lezcano wrote: > On 09/30/2010 09:50 PM, Andy Billington wrote: >> On 30/09/2010 20:21, C Anthony Risinger wrote: >> >>> On Thu, Sep 30, 2010 at 8:05 AM, Gordon Henderson >>> 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 ... >> > > Yeah, btrfs is still experimental. In the past, I did the same as > Anthony without visible problems but when I tried recently I crashed my > filesystem too. I am very impatient to see btrfs more mature because it > looks very promising. yeah i guess i wouldn't use it for clients at this point, but with build in raid/compression/etc. its a really sweet deal when combined w/LXC, so something to keep in mind, as i don't think it will be long until you will start seeing it everywhere. in my case i was running several personal containers, and other temporary stuff. btrfs made excellent use of the disk space, as every dom was COW'ed from a template. while developing some tools to quickly create containers, i literally created and destroyed hundreds of containers (btrfs) without problems. i also use it on several machines, including this laptop, which has had a btrfs / since .31, again without any issue whatsoever. i'm digressing though, but i don't know what people are doing to destroy their filesystems as i have done a tremendous amount of work and tinkering, and have yet to ruin one... maybe i'm just lucky though :-). the btrfs list is pretty quiet; i think most are using it rather successfully. C Anthony -- 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
Re: [Lxc-users] Container Filesystem in a file (loopback mount)
On 09/30/2010 09:50 PM, Andy Billington wrote: > On 30/09/2010 20:21, C Anthony Risinger wrote: > >> On Thu, Sep 30, 2010 at 8:05 AM, Gordon Henderson 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 ... > Yeah, btrfs is still experimental. In the past, I did the same as Anthony without visible problems but when I tried recently I crashed my filesystem too. I am very impatient to see btrfs more mature because it looks very promising. -- 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
Re: [Lxc-users] Container Filesystem in a file (loopback mount)
On 30/09/2010 20:21, C Anthony Risinger wrote: > On Thu, Sep 30, 2010 at 8:05 AM, Gordon Henderson 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
Re: [Lxc-users] Container Filesystem in a file (loopback mount)
On Thu, Sep 30, 2010 at 8:05 AM, Gordon Henderson 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 -- 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
Re: [Lxc-users] Container Filesystem in a file (loopback mount)
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! Gordon -- 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
Re: [Lxc-users] Container Filesystem in a file (loopback mount)
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. 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. -- 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
[Lxc-users] Container Filesystem in a file (loopback mount)
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) Cheers, Gordon -- 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
