[00:10] tanjix (ViRu_@pD9049C46.dip.t-dialin.net) left irc: [00:14] serving- (~serving@213.186.189.38) left irc: Ping timeout: 499 seconds [01:06] Nick change: BobR_oO -> BobR [01:30] stubbsd (~stubbsd@public2-birk1-6-cust176.manc.broadband.ntl.com) joined #vserver. [01:30] BobR (~georg@MAIL.13thfloor.at) left #vserver. [01:30] hi, anybody know it there should be any problem running nss_ldap on vservers? [01:32] I can't see any reason you would have a problem [01:32] thanks, must be something else then, I will keep on looking. [01:33] heh [01:33] I'm no expert [01:33] so take my answer as final [01:33] but, I can't see any reason why it wouldn't work in a vserver [01:33] what's wrong [01:33] ? [01:34] *don't take [01:34] gotta go [01:34] Just doesn't work, [01:35] Nick change: WSU -> WSU_away [01:36] sorted, dan reverse lookup :-), sorry all. [01:46] Doener (~doener@p5082DF3B.dip.t-dialin.net) joined #vserver. [01:57] ensc (~ircensc@ultra.csn.tu-chemnitz.de) left irc: Quit: Terminated with extreme prejudice - dircproxy 1.0.5 [01:57] hi Doener! [01:58] hi bertl [02:00] DazeDark (~chris@82-32-130-79.cable.ubr05.hawk.blueyonder.co.uk) left irc: Ping timeout: 499 seconds [02:06] serving (~serving@213.186.189.38) joined #vserver. [02:06] hi serving! [02:07] HI Bertl [02:07] that was an automatic signup but this time i caught your greeting :) [02:08] cool! [02:08] I could not solve that socket.c1111 problem of this morning [02:08] hmm, it is still there? [02:09] yep. [02:23] well, IIRC we found the following true: your command triggers the modules loader, but that tool isn't able to find/load that module ... [02:24] an educated guess would be: either you didn't install those modules properly or they are broken ... [02:24] rmoriz (rmoriz@rmoriz.cpan.de) joined #vserver. [02:24] hi [02:24] hi rmoriz, are you working with perl? [02:24] is there a quota/limit patch available for 1.3.4/2.4.24 ? [02:24] Bertl: yes [02:25] no, there is no patch available, would you like to test one? [02:25] Bertl: it's my fav. programming language ;-) [02:25] it would be nice. [02:29] Bertl: I did a standard make modules [02:30] when installing a fresh kernel [02:31] how can I find out which module loader is doing this ? [02:32] Zoiah (Zoiah@matryoshka.zoiah.net) got netsplit. [02:32] Bertl (~herbert@MAIL.13thfloor.at) got netsplit. [02:32] lp (~lpressl@interner.SerNet.DE) got netsplit. [02:32] infowolfe (~infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net) got netsplit. [02:32] micah (micah@micha.hampshire.edu) got netsplit. [02:32] CosmicRay (~jgoerzen@glockenspiel.complete.org) got netsplit. [02:32] deadguy (deadguy@bananajoe.big.du.se) got netsplit. [02:32] maharaja (maharaja@ipax.tk) got netsplit. [02:32] Medivh (ck@62.93.217.199) got netsplit. [02:33] Medivh (ck@62.93.217.199) returned to #vserver. [02:33] Bertl (~herbert@MAIL.13thfloor.at) returned to #vserver. [02:33] maharaja (maharaja@ipax.tk) returned to #vserver. [02:33] ah, another split .. what did I miss? [02:34] Zoiah (Zoiah@matryoshka.zoiah.net) returned to #vserver. [02:34] micah (micah@micha.hampshire.edu) returned to #vserver. [02:34] [N] Join synched in 23170.658 seconds. [02:34] now that took long :p [02:34] damn client hehe [02:36] you only been gone for 2 minutes [02:36] i know ;) [02:36] deadguy (deadguy@bananajoe.big.du.se) returned to #vserver. [02:36] looks like some silly bug in my client [02:36] Bertl: you don't like the idea of running vserver contexts on filesystem images? [02:36] hmm, how would you do that? [02:37] put the vserver stuff on a mounted filesystem loop [02:37] hmm, you mean using aloop device for the vserver root fs, right? [02:37] i head that some major german "vserver" companies do that instead of using the quota patches [02:37] CosmicRay (~jgoerzen@glockenspiel.complete.org) returned to #vserver. [02:37] i got it running like that on one machine, works really nice [02:37] Bertl: yes [02:37] s/head/read/ [02:38] JonB (~jon@129.142.112.33) left irc: Quit: Client exiting [02:38] well, if they want, probably the best way to get rid of your resources ;) [02:39] does it use a lot of resources? [02:39] you know vd-server.de? [02:39] didn't notice any performance impact at all [02:39] (okay that's a UML based service) [02:39] well, look at it this way: what do you want to gain with a loop mounted root fs? [02:39] i know FastIT GmbH in Germany uses "our" patch [02:40] Medivh: defined "our" patch? [02:40] well linux-vserver ;) [02:40] Bertl: hard size limits [02:40] Medivh: also smart-applications [02:40] smart-weblications or how the companie is called [02:40] never heard of [02:40] not sure what 1st-housing uses. [02:40] Medivh: it's a pricebreaker on webhostlist.de [02:40] i used to work for FastIT years ago, so I'm keeping myself updated on what they're doing now ;) [02:41] http://vserver.13thfloor.at/Experimental/patch-2.4.24-vs1.3.4-q0.12.diff [02:41] http://www.webhostlist.de/host/data/pf2.php4?virtuell=1&hd=&managed=&standort=1 [02:41] Bertl: thanks :) [02:41] okay hard size limits, fine, why not use lvm partitions? [02:41] on a shared device? [02:42] maybe because noone really uses LVM ;) [02:42] well, you can't consider a loop file a shared device, do you? [02:42] omfg, 50 euros including 250 gigs of traffic [02:42] wonder how they finance such offers if people go use their included traffic [02:42] Medivh: the can't [02:42] +y [02:42] and putting files on a disk partition and mounting it via a loop device, actually means that you get the I/O twice ... [02:43] infowolfe (~infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net) got lost in the net-split. [02:43] lp (~lpressl@interner.SerNet.DE) got lost in the net-split. [02:43] hm... [02:43] can i make 250 LVM partitions? [02:43] sure, why not? [02:43] hm never tried it. [02:43] it's even simpler to extend ... [02:43] if you decide to add another disk, just add it to the vg ... [02:43] 20 cents/gb ... that's a price i'd dream of buying my traffic for heh [02:44] heh [02:44] Medivh: your dream, my reality ;) [02:44] rmoriz: I would suggest to add a fix to vs1.3.4, otherwise you will get fork() issues ... [02:44] http://vserver.13thfloor.at/Experimental/patch-vs1.3.4-fix01.diff [02:44] rmoriz, i'm sure you buy a large amount of bandwidth though, and not on per-gb basis then? ;) [02:45] Bertl: ok thanks [02:45] Medivh: on GB base [02:45] but there is no need to pricedump anyway. [02:45] why should i shell too cheap? i like small business customers paying 1-2 eur/GB [02:45] and they like me. [02:45] i buy my bandwith by the Mbit [02:45] =0) [02:46] i can decide to do that. [02:46] but i only make a few GB...i'm a very small one :) [02:46] rmoriz, same here, my customers pay 1-2 eur/gb also ... and they're satisfied, what else can i ask for ;) [02:47] GB/month is usually used with hosting [02:47] mugwump (~sv@202-0-63-138.adsl.paradise.net.nz) joined #vserver. [02:47] hey sam! [02:47] 95th percentile is usually used with real links [02:47] eeeppp... it's the scary sam person [02:48] Hey Herb. Sorry I've been a little disconnected of late. A collegue says you're after me.. [02:48] oh, there he is [02:48] yeah, that is right ... [02:48] btw, Bertl, any news on the vnet stuff? ;) [02:48] no unfortunately nothing ... [02:49] he hasn't been asking for support on the hairy custom merge has he ? :) [02:49] btw Bertl, if anyone needs IPv6 peering, i can get tunnels setup for y'all [02:49] kungfuftr: we'll come back to that, I'm sure ... [02:49] and you'll only be sharing an ADSL line with the rest of asia? :) [02:49] mugwump: nah... uunet bandwidth [02:49] i can provide ipv6 upstream too if needed ;) [02:49] mugwump: ipv6.xede.org =0) [02:50] okay, give Sam and me a few minutes to talk ... then you can eat him ;) [02:50] i route most of europe and asia to the UK... east coast US too [02:50] uk6x? [02:50] mugwump: a mate of mine from back home is the OFTC chairman... [02:50] Medivh: nah... glbx [02:51] Action: mugwump sends kungfuftr SIGPIPE [02:51] mugwump: so i'm already on here, so was handy that vserver was here... i bloody hate freenode [02:52] Funny, here was the channel that FreeNode vs OFTC ``debate'' was being held [02:52] okay, Sam,the following issues are to be discussed: ILI, ILI, ILI, and a little Scheduler ... [02:52] bertl: ok, let me guess. You want me to look over recent ILI changes? Or actually get around to porting the Scheduler... [02:52] heh [02:52] neither nor ... [02:53] ok. ILI first. [02:53] okay, I decided to rename that stuff to Immutable Unlink [02:53] Sufficiently vague to encompass it's double meaning. Nice. [02:54] done that, I removed the IMMUTABLE_FILE and replaced IMMUTABLE_LINK by IUNLINK [02:54] this is just cosmetics, but I would like to know what you think of that [02:55] I also modified the IS_IUNLINK to check for Immutable and IUNLINK [02:55] insted of xoring them [02:55] My gut feeling is that "I" is an over-zealous contraction of IMMUTABLE. [02:56] yeah, sure ... [02:56] you've canned the XOR ? But that leaves one unreachable condition... [02:56] ie, mutable file, immutable link [02:57] now that doesn't lead to any issues I guess ... [02:57] or what is that combo be supposed to do? [02:57] just that. Files you can change the contents of, but cannot unlink/rename/link [02:58] hmm, did this actually work? [02:58] Yes [02:58] *rebooting testbox* [02:58] hrm, if i may ask an offtopic question, is there a way to tell rpmbuild to look for includes in another path except for modifying the spec file? [02:58] At one point, anyway. [02:58] okay, we do not want to loose any features, so I'll try to add this back ... if it worked ;) [02:58] medivh: try setting CCOPT=-Ifoo [02:58] thanks, gonna try right away :) [02:59] but, fwhat I suspected for a long time, now happened, namely the ILI flag is used by some distro for the lilo files ... [03:00] and guess what, lilo isn't able to update that file ... [03:00] lilo files? I thought that the "notail" option one took that bit [03:00] oh, nasty [03:00] app-103:~# uname -ar [03:00] Linux app-103 2.4.24-vs1.3.4 #2 Thu Jan 8 00:51:46 CET 2004 i686 GNU/Linux [03:00] yeah, so we probably have to move to another bit ... [03:00] but we have to do it without breaking existing server installations ... [03:01] This is silly. This whole ILI thing is a good feature that would be useful to many users, but unless we start it as its own little project it'll never get in. [03:01] Meanwhile the FreeBSD guy in the corner is laughing at us [03:01] Action: kungfuftr whistles [03:01] New security context is 49158 [03:01] Can't exec /usr/lib/vserver/save_s_context (Permission denied) [03:01] hm [03:02] well, the ili stuff is pretty separated in my splits, so there is no problem in 'submitting' it ... [03:02] ensc (~ircensc@ultra.csn.tu-chemnitz.de) joined #vserver. [03:02] OK, now we've really hit on a harder problem then. Migrating the bits on existing filesystems. [03:02] enrico? is this a real join? [03:03] yes, I swapped my harddrives and thought it would be safer to turn of the machine... ;) [03:03] okay, I just wasn't sure, because we had another netsplit a few minutes ago ... [03:03] since this was an NFS server, I had to reboot some clients too... [03:03] (inclusive the router) [03:04] okay, short info for you, some distro uses the notail flag for lilo .. this causes trouble with the ili stuff ... [03:04] netsplit was due to kernel upgrade... apparently [03:05] which distribution is using lilo today? [03:05] mugwump, CCOPT didn't work ... any other clue? [03:06] -ILIB /some/path ? [03:06] hrm looks like i can only start one vserver [03:06] rmoriz: hold on! [03:07] I hope you didn't mount the rootfs with tagctx option? [03:07] no. [03:07] stubbsd (~stubbsd@public2-birk1-6-cust176.manc.broadband.ntl.com) left irc: Remote host closed the connection [03:07] medivh: no, unless it's COPT, COPTS, or CCOPTS. It might be up to the contents of the Spec file... [03:09] bertl: would requiring users to run a quick `chattr -R' analogue after rebooting into the new vserver kernel be OK ? [03:09] Sam, I guess we should move to 0x08000000 for now ... [03:09] yeah something which scans the vserver, and if IMMUTABLE and IUNLINK(old) is set then set the new bit, and clear IU(old) [03:10] yep, that's what I was thinking. [03:10] nathan_ (~nathan@209-6-130-26.c3-0.sbo-ubr1.sbo-ubr.ma.cable.rcn.com) joined #vserver. [03:10] hello everyone [03:10] hi nathan_, have a stabilized 1.2.2.2 for testing here, wanna try? [03:11] thats quite the number of twos [03:11] sure ill give it a spin [03:11] how was the back rubbing yesterday? [03:11] tiresome [03:11] damn women [03:12] :) [03:12] I reckon, backrubs seem to be a one way street [03:12] http://vserver.13thfloor.at/Experimental/delta-2.4.24-vs1.22-vs1.2.2.2.diff [03:13] okay, the other thing is, that we should discuss some tools for the scheduler tuning .... [03:13] mugwump, nod [03:13] Bertl, hows the proc issue coming along? [03:13] mugwump, CPPFLAGS did the trick ;-) [03:13] well, the 1.2.2.2 version is a fix of the 'old' proc interface ... [03:14] the new interface is in development ... [03:14] Bertl, old being race condition or being security issue? [03:14] or both :) [03:14] apparently redhat got $400 million USD in more investment yesterday... argh [03:14] the race issues, the security stuff is solved in my opinion ... [03:14] Bertl, how was that solved? mount bind point or something else? [03:15] well, actually we came to the conclusion, that we simply will disable some proc entries not required for vservers on vservers [03:15] ah [03:15] so the entire directory tree will be masked ... [03:16] doesn't help for such special issues like sysrq-trigger, but they can be solved separately ... [03:16] and we'll probably include the ro --bind mount stuff too ... [03:16] Bertl: looks like the vserver tools don't do with 1.3.4 [03:16] So, is there a new type of procfs for vservers? Or a mount option? [03:17] well, mount options don't work SINGLE fs [03:17] I always thought that controlling visibility of proc via capabilities was the right way [03:17] rmoriz: what tools are you using [03:17] 0.29 [03:17] mugwump: yes, basically it will be something like that ... [03:17] mugwump, kernel maintainers dont seem to be following that though [03:18] rmoriz: do I mention them on the download page? [03:18] no ;) [03:18] what conclusion do you draw? [03:19] i should migrate my debian system to redhat so that i can use util-vserver ;) [03:19] enrico! help! [03:19] migration to redhat/fedora is really easy... ;) [03:19] hrm ;) [03:19] okay sam, any great ideas regarding procfs, by the way? [03:20] in short the issue is the write-ability within vservers ;) [03:20] no, just some old ideas regurgitated :) [03:20] well lets hear ... [03:21] one idea was a special type of procfs for vservers that only let you use specific nodes [03:21] but otherwise used the procfs code [03:21] something like a mask? [03:21] another idea was filtering just /proc with a userland-pokable regex [03:21] inside the kernel? [03:21] sure, why not. regex libraries are stable ... :) [03:22] Action: mugwump issues modprobe pcre [03:22] Action: Bertl bertl just lost his mind ... now searching ... [03:23] is there really a pcre module? [03:23] seriously though, you could have a "white list" of nodes that are allowed through [03:23] nathan_: sure. just pipe it out of /dev/crack [03:23] :) [03:24] ie, all the PID dirs, and simple things like `uptime', ... `stat', `version' [03:24] okay, that is pretty much what I had in mind, although I think we can replace the configurable whitelist by some hard coded defaults ... [03:25] s/defaults/behaviour/ ? [03:25] yeah ... [03:25] I suppose it's fair enough to make it a recompile offence if you want to potentially open up a massive security hole [03:26] I'm sure paul will complain in the minute we do that, that he has a software watchdog running in one vserver which needs access to the /proc/junk/reboot entries ... [03:27] So don't mount procfs with the vserver mount options for that server [03:27] not an option, mount options for procfs are for every procfs mount :( [03:27] oh. well, how do we stop them having effect in the root server then ? [03:28] by using a smart logic to figure that out (xid ?= 0) [03:28] for some definition of smart :) [03:28] Maybe the whitelist code could go in the bind mount code [03:30] So, mount --bind -o rootvfsfilter='^([0-9]*|uptime|version|loadavg)$' /proc /vservers/foo/proc [03:30] hmm, I guess you didn't check how the bind mounts work ... [03:31] you're right [03:31] point me at a file, maestro [03:31] # mkdir A [03:31] # mkdir B [03:31] # mount --bind /tmp/A /tmp/B [03:31] bertl: did you get my message about udp6.c? [03:31] touch A/1 [03:31] ls B [03:31] 1 [03:32] My understanding was they were like a directory hardlink. [03:32] maharaja: I got something ... [03:32] But then, what of the guy who managed to hack in RO bind mount support? [03:32] 08:47 @@ -744,6 +748,9 @@ struct sock { [03:32] bertl: did it make sence :) [03:33] well, yes, actually it was a mistake (on my side), but ipv6 doesn't work anyway ... at least not as expected ... [03:33] hm [03:34] util-vserver is nearly unbuildable on debian [03:34] rmoriz: why? [03:34] bertl: i see [03:35] mugwump: that was actually me, that guy with the ro --bind stuff ... [03:35] rmoriz: sometime ago I tested it with Debian 2.0 and it build without problems [03:35] stcace01:~# dpkg -s util-vserver [03:35] Package: util-vserver [03:35] Status: install ok installed [03:35] Priority: optional [03:35] Section: unknown [03:35] Installed-Size: 815 [03:35] Maintainer: Sam Vilain [03:35] Version: 0.23.96-1 [03:35] Depends: libc6 (>= 2.2.4-4), libstdc++2.10-glibc2.2 (>= 1:2.95.4-0.010810) [03:35] Recommends: debootstrap [03:35] etc [03:36] version 0.23.96 is a little bit old... [03:36] works for me ;) [03:37] i run 0.25.90 without any problems on debian [03:38] well, what I don't understand, how is compiling a deb package different from compiling a source tar? [03:40] Well, dpkg --remove works for a start :) [03:41] is there no rpm -tb for debian? [03:41] debootstrap-- [03:41] dh_make is close [03:43] okay, ad scheduler, enrico, sam? can we find some userspace interface and tool to set/configure this easily? [03:43] mugwump: any idea how do make a dependency spider based on 'Packages'? [03:45] The Scheduling options, I presume you mean. [03:45] yeah, those 'magic' values you assign via the tuning syscall command ... [03:46] what are we deciding? syntax? [03:46] Bertl: it should be no problem to set this atomic values... [03:47] hmm, I would like to have something I can explain somebody, who is asking, how do I configure my O(1) sheduler ... [03:47] s/sheduler/scheduler/ [03:47] but to adjust multiple vservers need more work [03:48] some basic concepts like 10% of the CPU in average or something like that ... [03:49] or, even weighting like A,B,C is 5 and D,E is 2 [03:49] "in average" means that I have to know what the other settings are... [03:49] No, 10% of the CPU is constant [03:49] means that on a balanced system total = 3*5+2*2 and each server will get the N/total fraction [03:49] without at statistic interface, this becomes ugly [03:49] you only need to know what the other settings are to make sure that you haven't over or under-allocated it [03:51] Weighting would definitely avoid that problem. You don't even need to do much math - just add up the weightings, that's the divisor. Then each server gets its weighting as their allocation. [03:52] so, with your example, A,B,C get 5/19, D,E get 2/19. [03:52] so basically we should do that in the kernel, right? [03:52] The scheduling patch I wrote works like that. [03:53] Gives you 5 tokens every 19 cycles (or whatever) [03:53] okay, we are talking about that patch, right? [03:54] Unless you're going to design & implement it for the (non-O1) solution in 1.3.2+, yes :) [03:54] + int32_t fill_rate; [03:54] + int32_t period; [03:54] + int32_t fill_level; [03:54] + int32_t bucket_size; [03:54] aye [03:55] those are the values, how to configure them? [03:55] are they _all_ useful in userspace? [03:55] fill_rate and period, absolutely. [03:56] okay, bucket size is an upper limit right? [03:56] and fill_level is the current value? [03:56] yep [03:56] fill rate is how often a token is kicked into the bucket? [03:56] having a smaller bucket_size will give quicker scheduling results [03:57] quicker means shorter scheduling periods ... [03:57] no, period is how often fill_rate tokens are tossed in the bucket [03:57] okay, period 1 means? [03:58] hmm, 2 questions... [03:58] "quicker" actually means that it takes less time for a context which is over- or under-using its tokens to get scheduling *bonuses* [03:59] To get 5/19 of a CPU, you would have a fill_rate of 5, and a period of 19. [03:59] period 1 would only be useful on SMP, eg fill_rate = 1 also, to give one entire CPU [04:00] hmm, so this means, give every 19, interrupt cycles 5 tokens into the bucket, right? [04:00] the correct term is "jiffies" :). Yes. [04:00] okay, jiffies it is ;) [04:01] so having sum(fill_rates) > or < period doesn't make snese, right? [04:01] for a constant period value for all contexts ... [04:02] Well, consider this. You have a system with 32 vservers on it, but you give each 1/16 of the system, because you know that usually most of your customers don't use all their CPU [04:03] default vs. specific [04:03] Or, you have a system capable of having 32 vservers on it, but have only sold 5 so far, so still only give the 5 you have already 1/32 of the CPU [04:04] hmm, would that actually lead to 27/32 idle time? [04:05] no, they would just get very low priorities. [04:05] hmm, so what is the sense in that then? [04:06] maybe it would make more sense if it could be 'hard' scheduling. [04:06] is this possible? [04:06] and what about the 'host' context? [04:07] it doesn't have a s_context structure, does it? [04:07] or whatever that structure's called now :) [04:07] yes, currently hasn't ... [04:08] So, the host context just gets all it can eat, though it won't get the bonuses that being in a token rich context would give it [04:09] Though of course you can override that for individual process groups with `nice -19' :) [04:10] So, having a deficiency only makes "real" sense if you allow for the root server, or if "hard" scheduling is implements. [04:11] okay, what I think is, that this needs some business logic to make it work on the average vserver setup ... [04:11] Having a surplus (of weightings) only makes sense if you explicitly want it. [04:12] I don't think that it's a good idea to tell the vserver users, to update some magic values for every vserver, when they start a new one .. do you? [04:12] and I don't think it's a good idea to use default values for those magic values either ... [04:13] oh come on, they're not all that magic :) [04:13] anyway, I think that this can easily be solved with a couple of switches. [04:14] If anyone wants anything more specific, they can write their own tools. [04:14] I'm all ears ... [04:14] a default --balance switch that makes the usage 100% across all the vservers. views the fill_rate as the weighting. [04:14] but this has to be in the kernel ... [04:15] no, the existing flags are flexible enough [04:15] hmm, so you want to change every context? [04:15] setting --balance would have that effect, yes. [04:16] okay, I'll just listen, try to explain the interface to me ... [04:16] most users would use `ctxcpu --ctx N --weighting FOO' [04:17] This goes through all the contexts running, and adds up the fill_rates of all of them [04:18] then sets the `period' to be that total, divided by the number of CPUs in the system [04:19] Otherwise, if you use `ctxcpu --nobalance', you could conceivably set all of the flags for an individual context unhindered [04:19] Of course, there is the problem that something needs to keep track of whether an individual context was supposed to be balanced or not... [04:19] okay, but I guess it would be _much_ better to do that 'simple' summing in the kernel ... [04:20] could even be based on a flag ... [04:21] yes, something like that. I don't think many users would have such fine grained requirements that the period needs to be able to be set on a per-context basis, come to think of it [04:21] the kernel has a lsit of all contexts ... and quick access to that data ... no need for special math, and no problems in userspace ... [04:22] so we allow to 'set' the fill_rate (amount) for each server and calc/update the period ... [04:22] what about the bucket size? [04:23] A more advanced scheduler would want to be able to set that on a per-vserver basis. [04:23] this should be quite independant, right? [04:23] "Batch" vservers would probably want very large bucket sizes [04:24] okay, so basically filling up their buckets, and bursting CPU later ... [04:25] the fill level is only of interest if you wanted to give some start credits or something like that, right? [04:25] essentially. Also, an "active" scheduler might want to meddle with bucket levels every N seconds or something like that. [04:26] hmm, okay but we could hide that from the user for now, right? [04:26] lp (~lpressl@interner.SerNet.DE) joined #vserver. [04:26] oh yes of course [04:27] good, so the user interface would actually consist of a vsched --xid 100 --weight 5 --size 20 [04:28] and done for every vserver, it would balance similar to vsched --xid 100 --weight 1 --size 10 [04:30] `size' is `period', no? [04:31] or bucket size? [04:31] hmm, actually bucket size ;) [04:31] ok, `period' is automatic. cool. [04:31] but the name doesn't matter ... [04:31] but, if --period or --divisor is given, the auto-balance should be avoided [04:32] most users won't care about --size or --level, but may as well support them... [04:33] the question is, how to balance over individually configured vservers? [04:33]