> 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 [email protected] http://list.linux-vserver.org/mailman/listinfo/vserver
