Hi I don't mean this to be an aggressive reply, especially since it was me who asked YOU for the feedback. However, I just wanted to comment on your notes?
> EW> Hi, I'm an enthusiastic linux-vserver user. Any particular > EW> reason you moved away? > > The only real reason was that after upgrading the host to Debian 6.0 > OpenAFS access stopped to work in my VServer guests which was a big > trouble for me. Curious. It's not something I use, but is there a systemic reason why this doesn't work? In my experience vserver never stops you doing something, only stops you doing something if you don't want to give up the security of a full container? > I couldn't find any quick solution and because Debian > is going to drop VServer support in the next major release anyway, I'm actually unsure what you mean by that since there has been no real "support" from debian in the past? I guess if you mean that the official debian project ships some antique kernels with patches some many years out of date, then yes I hear that might go away, but in any case a debian user would seem to be creating problems for themselves not to just use a modern kernel from Bristol Wireless or a self patched kernel? Basically linux-vserver exists as a patch external to official kernels. To my eye this is no great problem, but to others it may be. Do consider trying to compile your own kernel though - it seems to hold a lot of fear, but given that you are apparently happy to add aufs2 patches yourself (surely Debian doesn't patch these in?), then I really don't see the issue with adding in linux-vserver also? Anyway, this sounds like a bash at you, it isn't meant to be, I was more philosophising. I have heard others shape their plans based on whether Debian continued to ship a patched kernel with completely out of date vserver patches or not - to my mind debian kernels are just antique however you look at it and not worth the effort? with > LXC being the suggested replacement, I decided to move to LXC right now > to save me from both current and future troubles. See, I have stuck with vservers because I'm worried about the "current"? Seems like eventually LXC will mature and gradually become the future, but right now seems like it lacks the security and isolation that you get from the vserver patch? I don't see that LXC (yet) really secures the guest completely and if you don't do that then to some extent, what's the point? > It provides better device and network isolation, e.g. `mknod /dev/null' I think this can be allowed with vservers also? It's a security option to disallow it, but you can either have the host run the mknod in the guest, or give the guest the correct capabilities (disabled by default though)? > is easily possible and each container can have its own routing and > filtering rules. I believe this works with vservers also? The routing either needs to be done by the host with the default setup, OR you can enable the full network isolation as per LXC and use the virtualised network stuff in vservers? I understand that most use the former because it's lighter weight, but the full network isolation can be useful for advanced situations where the extra virtualisation overhead is not important? > I can run OpenVPN in a container (no previous success > with VServer), I don't believe this is a problem, other than assigning IPs to the guest (which is disallowed by default, but enabled by capabilities)? I would suspect using full network isolation would enable you to easily use vservers also? > X server works also fine (not considering security) Hmm, do you mean server or client? If you mean server then I guess that's a fairly unusual and specific setup? I think you need to giveup a lot of isolation to run X server in a vserver, or switch to something like KVM? Generally you want the X server on the machine with the keyboard and mouse? > It's possible to run just a > single application in an isolated environment. Obviously you can do the same with vserver, so I suspect you mean something much more subtle? Is there some easy way to create a more functional "chroot" in LXC then? > I've experienced some annoying bugs, at least with > the kernel included in Debian stable, I don't use Debian, but all I hear is "bugs", "old and stale", "source install"? I don't quite get why many users use Debian - seems like it excels in "stable", but most users at some point want "latest and greatest", at which point you need to giveup Debian and turn to source, which to my eye removes most of the point of using a creaky old stable distro? If you just want more modern kernels then there are a few people apparently building modern kernels (2.6.x !!) with various patches on and maintaining them. I see such a kernel regularly advertised on the vserver mailing list for example? Surely the problem with sticking to official Debian kernels is that you are stuck with some 2.4.x or 2.6.antique anyway, so you don't get all the latest LXC fixes? > Generally, I could basically move my guests to LXC rather easily and it > solved some problems I had previously with VServer. Curious - what problems (apart from the above, ie AFS and XServer?) > One of them being how to get a hashify equivalent I guess the COW chunk of the vserver kernel patch could be broken out thought? I believe there are other COW implementations also? > (well, I'm > not completely off-topic!:-) to better utilize hardware resources > (especially memory related). It seems something like aufs + aubrsync + > hardlink could solve the problem partially if I can get it working. > Another problem is how to run aubrsync without stopping the containers > running on the aufs file system (aubrsync remounts it read-only for a > while). There used to be a Vserver+aufs howto? I never read it, but there are references to it on the aufs website? Presumably this would have some interesting clues if you could locate it? I suspect a sensible solution would be to reverse the hashify solution. Mount an aufs writeable root over a base filesystem. Then allow it to evolve. Next update the base filesystem in a way which should remove most of the changes in the clients. Finally stop the clients and use something like rsync to build a new client (new changes dir mounted over new base, make it match the old client)? Does that work? Thanks for sharing, good luck Ed W ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar
