On 2006-03-30, Bastian Blank <[EMAIL PROTECTED]> wrote: > > On Mon, Mar 27, 2006 at 03:28:42PM +0530, Ganesan Rajagopal wrote: >> How about providing this access only in a Xen guest? > > We have vserver enabled kernels for some arches in the archive.
In fact all arches that we support (except for parisc/hppa until the dietlibc-dev syscall fix is uploaded with the patch I submitted last night: #351875). However, I am curious how people are proposing to use something like vservers for this purpose. Probably the best thing would be to allow individual developers to "check out" new vservers. You would have the option of picking a woody, sarge, etch, or sid vserver, and a period of time that the vserver would stay around, after which it would be scheduled for removal. If you had a vserver guest "checked out" on a system, you could "renew" it, thus extending the time it will exist. A simple email can be sent warning you of your vserver's pending removal a few days before, and then after it has been removed. Space may be a problem if too many vservers are "checked out" at one time[1], so there would be some simple limits placed on disks (and other resources) per verserver, and developers would not be able to "check out" a vserver if a certain disk ceiling was currently in affect. I imagine that this would be tremendously useful to developers as it provides you with root access to an environment on an architecture to develop and resolve packaging issues without having to wait on the admin of the machine to install a package you need. micah 1. space issues can be mitigated if the host is running etch because the vhashify vserver ability to "unify" guests to save disk space by performing link inversion immutability operations. The libbeecrypt6 problems were not fixed before sarge released, so this is currently not possible on a sarge system -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
