You are not currently logged in. If you do not have a user account then please consider creating one and logging in before you post your comment. This will allow you to track replies to your comment, and take part in the site much more freely.

To add your comment, fill in all the boxes below and then preview it to make sure you're happy with the way that it looks.

This is the comment you were replying to, attached to the weblog Using vserver

#6 Re: vserver vs xen (and best-practices) Posted by undefined (192.91.xx.xx) on Thu 22 Mar 2007 at 19:10 as you recognized, vserver targets user-land, so your application use (cfengine, dpkg-dev) is very appropriate. vserver does not virtualize the network stack to the point of appearing as separate physical machines (like xen or qemu), but instead virtualizing ip addresses. with an emphasis on security, vserver allows you to have separate ip addresses per vserver with iptables managing them. it is probably possible that tun/tap devices could be associated and used by individual vservers to create simulated networks with limitless possibilities (like qemu). vserver does not allow separate kernels, but neither incurs the overhead of separate kernels (though, yes, paravirtualization does reduce that overhead). are you talking about nfs booting the "host" (the vserver kernel) or the vserver "guests"? there's no reason you shouldn't be able to nfs boot a vserver kernel. and as the filesystem is a kernel-land issue a vserver guest could "boot" (though it's really just init'ing and running) off a nfs filesystem mounted by the host. the difference between xen and vserver boils down to levels of separation. the more separation, the more overhead incurred. - i have ultimate flexibility with physical machines, but that incurs ultimate overhead. - qemu allows me to run multiple computer architectures on a single machine, but incurs resource overhead (processing, memory, storage). - xen allows me the flexibility to run multiple operating systems (or multiple instances of the same os) on a single machine, but with the restraint of a single computer architecture, and again incurs overhead, but less than the previous options. - vserver allows running multiple user-land instances on a single kernel, but with all the restraints that stem from using a single kernel. that separation/freedom is not "free", you pay for it. it's just a matter of being as efficient as possible (minimizing overhead) while fulfilling all requirements (degree of separation). and there's no reason not to use both at the same time, as xen and vserver can coexist (as evident in etch's kernel images). use xen to create virtual networks and run different kernels, but have all your "stable" applications running in a single xen domain, but kept separate in user-land by vserver. some xen users will argue that it's easier for them to just use another xen dom to separate the applications than learning vserver, but they are just trading one resource (their time & mental capacities) for another (computer resource overhead). personally, i don't need anything fancy on the kernel-side, but i want user-land isolation for security and managability. for instance every php application i have runs in its own vserver (but with a unified url namespace by using a reverse-proxy apache in its own vserver), but by using vserver and hardlinks my apache+php vserver instances have an equivalent footprint (processor, memory, storage) as a single apache+php installation. sometimes i think xen users advocate their mallet as the best hammer (even if only implicitly), misleading those who would be better served by a claw hammer (and admins should know and apply both as appropriate).

Username:	Anonymous
Title:
Your Comment:
Posting Format:	BBCode HTML Text Plain Text Textile

Inappropriate comments will be removed.

Username:

Password:

[ Advanced Login ]

Register Account