I am planning to write a short guide with a different approach using vserver-debiantools (and its script newvserver), but still need to test vserver more thoroughly, which is part of my objectives for the coming week-end.

As for the linux-image, sure, it should be adapted to what you already run and suit your architecture (added to my draft).

Cheers,
Julien

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).