> That means running them on the host, and my idea was to have as
> absolutely as little as possible on the host.
Still, by giving so much capabilities to the guest you're basically
turning vserver into nice-managament-setup, and all the security goes out
the window (not that my setup with Xorg in guests is that secure, I too
like having clean host and ability to easily backup/move all the
functionality to other machines).
> now, under the assumption that, once installed, VMware won't want to
> alter the nodes.
With VMware Player I just had to setup networking once ( I created two
setups, one NATed and the other bridged ), and now I'm not touching
anything, every new image just uses one of those and that's it. And I don't
even use CAP_NET_RAW on the VMware'd guest.
> The Xen and QEMU comments were a joke.
One man's jokes are the other man's challenges ;)
> On that, I wonder if the vserver patches and Xen patches can co-exist.
They can, and do, check ML archives.
> both in one - the flexibility of Xen (different kernels etc) and the
> efficiency of vservers.
Since I'm using mainly linux under vserver, the only thing I want from xen
is ability to test new kernels. One can imagine such setup -
you boot with ~32M xen monitor, rest of the memory goes to main vserver
host, and you leave ~32M/~64M haning exactly for such a purpose (OTOH, as
balooning driver works quite nice under linux and OK for netbsd, you could
use all the ram for production, and when the time comes for testing new
kernel - you dynamically shrink your production image, boot up testing, and
if all goes well, you switch them.
-- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 Total Existance Failure _______________________________________________ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserverReceived on Fri Apr 21 11:50:16 2006