From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Thu 31 Oct 2002 - 13:59:51 GMT
On Thu, Oct 31, 2002 at 08:18:01AM +0100, Andreas Kostyrka wrote:
> Am Mit, 2002-10-30 um 22.52 schrieb Mefford, Aaron:
> > I realize that I am new to the list and do not have much history, but I am
> > considering the possibility of using vserver on a fairly large project and
> > as such would like to at least take a moment to offer my opinion on a couple
> > of items.
> > First, I almost walked away from using the vserver option until after
> > joining the list I saw that the quota issue was being actively addressed.
> > Of the todo's left, quota was the biggest gap for my application. It would
> > be excellent to see the others addressed but without quota it would not be
> > an option.
> It surely should be. Consider using LVM and sticking each vserver on
> it's own logical volume. This way you can statically allocate space to
> vservers and resize their needs online.
- the usual quota behaviour
- a dedicated space for each vserver
- no unification (about 200MB instead of 20MB per server)
- no grace limits (overbooking)
- no simple change in size (needs at least filesystem resize)
- partition management for each vserver
> > As to the specific post, I am not sure that the hard line of not overbooking
> > is a good idea. While for many applications it would be a correct solution
> > there are some where it will not. Every ISP over allocates their available
> > resources. People do not care to pay for dedicated resources.
> > Additionally, with most services now being offered via resellers, it seems
> > unreasonable to not allow the reseller the same option. For instance, if I
> > sell virtual private servers, and joe buys a VPS with the intention of
> > selling individual web sites run within the VPS, I may or may not want to
> > allow Joe to oversubscribe his disk s pace, possibly even on a per VPS basis.
> Thats what "soft" quotas are fore. Depending upon your guidelines when
> someone oversteps the softquota, either the root_at_main or root_at_vserver
> should decide if an upgrade of discstorage is needed and initiate it.
> Basically if you get 500MB/1000MB hard, you can overbook in the same
> ratio your own users, ...
> > I realize that implementing a solution that would support a hybrid approach
> > raises the complexity, but I wanted to state that there is value and need
> > for such an approach.
> Well, the quota approach do have some problems (IMHO). Consider the
> vunified system files. Do they count against the "main" root quota, or
> against the "user" root quota? How is the Security Context a file
> belongs to stored on disc?
In my approach, the new installed server (which should be unified)
counts basically against the "main" (physical) root/user quota,
but any file changed or created within the vserver accounts to
the context/user quota of that vserver ...