1137024420 M * fosco juste to know, is it possible to attach a network interface to a vserver when it is running?
1137024592 M * daniel_hozac fosco: possible, but it's generally easier to stop it, add it, and start it again.
1137024609 M * fosco yes ;)
1137024626 M * fosco it is just for example to create a tun0 interface with tunctl
1137024647 M * fosco and attach it without restarting the vserver
1137024657 M * fosco (for using vtund, openvpn, etc...)
1137024715 M * daniel_hozac if you'll be doing that a lot, it's probably easier to leave it unbound.
1137024770 M * fosco it is for testing ;)
1137024813 M * fosco for general use, I don't see why I would not want to simply add it in the configuration
1137026638 N * Bertl_oO Bertl
1137026643 M * Bertl back now ...
1137026776 M * eric Hi.
1137026788 Q * zobel Ping timeout: 480 seconds
1137026844 M * Bertl hey, so ready for round two?
1137026852 M * eric Yeah.
1137026860 M * eric Or mostly so.
1137026876 M * derjohn Bertl, typespeed? or what round?
1137026893 M * Bertl eric: cool! do you have some PoC code somewhere?
1137026898 M * eric I finally worked out the times, and give or take a couple of hours the hours we are usually up appear to be in sync.
1137026902 M * Bertl derjohn: read up todays IRC logs ...
1137026907 M * derjohn k
1137026934 M * Bertl derjohn: short version is, eric is planning to do mainline virtualization
1137026936 M * eric Yes.   I haven't generated any patches yet.  
1137027007 M * Bertl eric: do you plan to do that for networking too?
1137027033 A * Bertl just realized that this would be _the_ chance for ngnet to take off and fly ...
1137027066 M * eric Do I plan to do virtualization for networking as well?  Yes.
1137027076 M * eric Actually I'm just about finished with it.
1137027090 M * Bertl excellent ... well, hopefully :)
1137027140 J * zobel zobel@zobel.irc.ftbfs.de
1137027145 M * Bertl eric: ad networking, to what degree? I mean, can the 'contexts' have different routing, different network interfaces, different ip tables?
1137027197 M * eric Currently I have everything but different ip tables working, and that only because I haven't gotten that far yet.
1137027228 M * Bertl great! I'm really looking forward to see your code ...
1137027236 M * eric I'm in the final stages of debugging multiple copes of the ipv6 routing tables.
1137027284 M * Bertl because the nget we are working on was basically put on hold because of the changing kernel networking, and the amount of work which would be required to keep that in sync
1137027307 M * Bertl so a mainline network virtualization is _very_ interesting for linux-vserver
1137027472 M * eric So I have just put a snapshot up at http://www.xmission.com/~ebiederm/files/namespaces.diff.gz
1137027527 M * eric Actually I am virtualizing the whole stack to make the maintenance easier.   Anything less and I have to start changing the logic in the code, with everything it just a matter of following some pointers.
1137027555 M * Bertl hmm .. well, how much overhead does that add?
1137027602 M * eric I haven't measured it yet.   I don't think anything will be measureable except possibly the packet receive path.
1137027630 M * eric And that is because it now has to compare an additional value to see if it has the correct socket.
1137027646 M * Bertl some kind of 'xid'
1137027648 M * eric For hash tables I insert an extra entry specifying the host.
1137027673 M * eric Actually a pointer to a structure but yes essentially xid.
1137027714 M * eric The biggest pain with the network stack is that it is so large.
1137027719 M * Bertl against which kernel is that diff?
1137027743 M * derjohn eric, I dont get from reading the logs ... you plan to do 'namespaces stuff' completely or are you focused on networking? In what way will it relate to linux-vserver?
1137027784 M * Bertl derjohn: if this works out, and it looks good so far, then eric's stuff could sooner or later replace the entire vserver isolation
1137027830 M * eric So the kernel thinks it is 2.6.14-rc3 the get sha1 is dd0fc66fb33cd610bc1a5db8a5e232d34879b4d7
1137027837 M * derjohn Bertl, this is what I was afraid of :) 
1137027855 M * Bertl derjohn: hmm, why afraid of?
1137027884 M * derjohn Bertl, would you regard a virtual namespace a "cleaner" solution than the xid?
1137027906 M * derjohn Bertl, I mean do the concepts differ much?
1137027932 M * Bertl no, looking at eric's work it looks very similar to what is currently done in linux-vserver
1137027976 M * Bertl just the perspective is a little different ... i.e. this might give hierarchical contexts too ...
1137027985 M * derjohn Bertl, so it's mayne now the change to get parts of linux-vserver into the mainline?
1137028017 M * derjohn for what else but 'vserver' could the "vnamespace" be used?
1137028021 M * Bertl well, as eric wants to get this into mainline (and he has a good chance, I'd say)
1137028029 J * tudenbart ~willi@xdsl-213-196-242-242.netcologne.de
1137028037 M * eric Bertl: Good observation.   It actuallys does give hierarchial contexts.
1137028046 M * Bertl derjohn: and is willing to put some (read: a lot) work into it ...
1137028086 M * Bertl derjohn: this could be a good way to get a sane virtualization framework in, which would leave us (read: me) more room for the 'details'
1137028101 M * Bertl welcome tudenbart!
1137028131 M * eric There is a key point I need to add here.
1137028139 M * Bertl eric: so your 'host' is our 'vx_info'
1137028157 M * eric Host is the networking version. 
1137028168 M * Bertl I'm reading the utsname stuff
1137028182 M * derjohn Bertl, well, yes it's get's time for linux to get such a features (jails in BSD is standard for a long time). 
1137028198 M * eric The fact that I have utsname and the rest of the networking hooked together quite possibly a bug.
1137028205 M * derjohn eric, thanks a lot for developing that!
1137028217 M * eric Welcome
1137028230 M * eric There is still a long ways to go though.
1137028254 M * Bertl sure .. your diff is reversed, has this any specific reason, btw?
1137028262 M * eric One of my concerns is that there might not be enough clone flags for all of the namespaces I identify.
1137028298 M * eric Bertl:  I think I just fat fingered the command line when I made it.
1137028299 M * Bertl eric: well, we will add some then, no?
1137028312 M * derjohn eric, how long? I mean are you just "exploring the problem" by now or is your decision made to do it? 
1137028335 M * Bertl  301 files changed, 1849 insertions(+), 4670 deletions(-)
1137028343 M * Bertl sounds like a decision to me :)
1137028366 M * eric Yes to both.  The current version is the exploration of the problem to see how it can be done.   But the decsion take it all the way has been made.
1137028377 M * derjohn Bertl, puuuh.... it's obviously a derivate product and not linux anymore ;)
1137028422 M * Bertl eric: do you want to hear random comments while I browse the code?
1137028430 M * eric Go ahead.
1137028456 M * eric I have worked hard to make the changes so that if I miss something it will result in a compile error.
1137028457 Q * dothebart Ping timeout: 480 seconds
1137028482 M * Bertl k, why extending find_task_by_pid() to take the pspace, if you pass the 'current' one in 52 of 63 cases?
1137028512 M * Bertl why not 'just' add a find_task_by_pid_in_pspace() (bad name, but shows the idea)
1137028519 M * derjohn eric, brave decision ... I mean in times when XEN linux-vserver and others already exist. What drives you? I am just curious if there i some commercial background behind it (I.e. are the changes high that it get finished?)
1137028555 M * eric Yes I am being paid to do this.
1137028615 M * derjohn Very cool position :) But I don't want to waste your chat time for now ... listen to Bertl comments :) HF (both) and hope to see you here again! bye!
1137028619 M * eric Bertl.  A lot of the cases that take find_taks_by_pid I might need to change in more subtle ways.  So I might rename it but I would not leave find_task_by_pid with the same calling conventions.
1137028666 M * Bertl derjohn: tx, good night!
1137028713 M * Bertl eric: well, I would see a good point in doing so, if you passed the task struct (current) instead of the pspace, but you decided not to do so ...
1137028760 M * Bertl the additional argument might add some overhead (code optimization and stack wise) which gives no real advantage
1137028783 M * Bertl but as I said, a random comment ...
1137028931 M * eric Well I fully expect the code to be audited to death by the time I am done.
1137029140 M * Bertl did you check how much different 2.6.15 is compared to the tree you used?
1137029163 M * eric I haven't yet.  
1137029195 M * eric My plan is to get to wrap up the networking stuff and then get port to the latest kernel.
1137029236 M * eric I need to break my code into logical sections and once that is done the port should be fairly straight forward.
1137029239 M * Bertl okay, would be great if we could do that in a way that it would be useable for the ngnet stuff ...
1137029267 M * eric What are the requirements there?
1137029279 M * Bertl in this area I could make a lot of time available too
1137029289 M * Bertl basically the ngnet 
1137029305 M * Bertl idea is best shown by the following PoC code ... (sec, searching :)
1137029377 M * Bertl http://vserver.13thfloor.at/Experimental/NGNET/delta-2.6.14-vs2.1.0-ngn0.02.diff
1137029387 M * Bertl (and the http://vserver.13thfloor.at/Experimental/NGNET/delta-ngn0.03.diff)
1137029406 M * Bertl which should be very close to what you do ...
1137029484 M * Bertl the 'important' change/addon is that we do half devices ... i.e. devices which act similar to loopback, but when they 'reflect' a packet, they change the tagging of the skb
1137029525 M * Bertl thus enabling two such devices to communicate inside the kernel, by passing over the skb from one context to the other ...
1137029547 M * eric Got it.  My etun driver is used similarly.
1137029572 M * eric I have code to pass a network device from one context to another so the implemenation is slightly different.
1137029599 M * eric And my etun driver is currently built so it can be used with ethernet bridging, which is arguably the simplest way to configure it.
1137029599 M * Bertl one important thing in linux-vserver is that we want to keep the 'old' behaviour too, which just does isolation, not virtualization
1137029643 M * Bertl mainly because isolation is sufficient for 80% of all applications and does neither add the overhead of virtualization nor the administrative burden
1137029651 Q * monrad Quit: leaving
1137029696 M * Bertl but I think I figured a way to get both working, which might be interesting for you too
1137029726 M * eric Ok.  Have you seen the linuxjail patch?  I think that does a cheap version of your normal isolation approach.
1137029739 M * eric network isolation approach I mean.
1137029743 M * Bertl yes, I know it ... that's the basic idea 
1137029764 M * Bertl I guess it's linux-vserver where serge got that from in the first place
1137029824 M * eric I couldn't use that because I frequently have more than one ip address an it just doesn't scale to 2 devices.
1137029880 M * eric The way my code is implemented you don't actually have to change contexts to leave the box, if you have enough physical network devices.
1137029915 M * Bertl yes, I know, that's the same as with ngnet
1137029921 M * eric Have you don any overhead measurements on your ngnet approach.
1137029922 M * eric Ok.
1137029928 M * Bertl you just put the devices into the context
1137029957 M * Bertl eric: well, not much to measure there yet, but the overhead is minimal
1137029989 M * Bertl i.e. there is no overhead if you have a dedicated device
1137029991 M * eric Ok.  So the real overhead is the administration overhead then?
1137030005 M * Bertl you have the 'normal' overhead of passing the tables twice with a virtual device
1137030025 M * Bertl and, of course, you have a large administrative overhead
1137030076 M * eric It depends on how you run it if you do dhcp and all of the standard auto configuration things it should not be too bad.
1137030084 M * Bertl but, the good news is, the folks interested in ngnet (or virtualized networking in general) are willing to accept some overhead 
1137030124 M * Bertl eric: you still have to create all those virtual networking interfaces and tie them together ...
1137030169 M * Bertl because the number of cases where you have a separate interface for each context is neglectibe
1137030198 M * Bertl typical use-cases include:
1137030211 M * Bertl - one interface reserved for the host (might be a vlan)
1137030234 M * Bertl - one or two interfaces (often using bonding) for the 'guests'
1137030263 M * Bertl - a bunch of guests with 'purely' virtual interfaces (i.e. 'behind' the host which is routing)
1137030276 M * Bertl and of course, all kinds of combinations
1137030288 M * eric Sounds right.
1137030316 M * Bertl the 'currnet' (non ngnet) solution handles the first two quite fine
1137030339 M * Bertl and can be 'abused' for the third one, with SNAT and local IPs
1137030389 M * Bertl (keep in mind, there is currently no overhead to the networking, as it all happens on the host, except for the neglectable socket checks)
1137030417 M * eric True.
1137030462 M * eric The question really is how much overhead does it cause in the bonding.
1137030488 M * Bertl 100% if you do it just by virtualization :)
1137030527 M * Bertl let's make a simple example ... you 'receive' a packet on the host, which is designated for a guest
1137030548 M * Bertl what do you do 'just' with virtualization?
1137030563 M * eric What do I do?
1137030568 M * Bertl you have to 'route' the packet to the vnet device
1137030581 M * Bertl which does the context switch for the skb (at least)
1137030587 M * eric Yes.
1137030592 M * Bertl and then delivers it to the guest's sockets
1137030611 M * Bertl but, this involves passing the network stack twice, no?
1137030625 M * Bertl two separated instances of course, but nevertheless, twice
1137030631 M * eric Yes.
1137030643 M * Bertl which, as I said, adds roughly 100% overhead :)
1137030675 M * eric Except that the time in the network stack is only a fraction of the total process overhead of the packet.
1137030684 M * eric But I see what you mean :)
1137030707 M * Bertl agreed, but OTOH, you will create hashes and caches and stuff twice too
1137030787 M * Bertl so I would not be suprised if the 'fast path' would take as long as the 'normal' path takes now, and the slow one would take more than twice as long ...
1137030806 M * Bertl which, in the age of GB networking is significant ...
1137030855 M * eric Probably.  Of course for me GB ethernet is the slow network on the machine.
1137030921 M * eric I have users that I can't even convince to actually use the kernels network stack :)
1137030952 M * Bertl well, in this case you should be really concerned about the additional overhead :)
1137031002 M * eric I am but the whole kernel network stack is the my slow path....
1137031009 M * eric :)
1137031022 M * Bertl doesn't mean that we want to make it slower, does it?
1137031055 M * eric Nope.  And I don't intend to do anything that I can avoid.
1137031100 M * eric It may be worth playing with a network devices that looks at the incoming ip address and selects the context based on that.
1137031101 M * Bertl one idea I had with ngnet is to allow for omnipresent elements, which is something you cannot easily do with the pointer approach
1137031127 M * Bertl probably not even with the completely virtualized stack ...
1137031158 M * eric Network devices that can be shared by all contexts?
1137031173 M * Bertl network devices, sockets, entries to tables ...
1137031205 M * Bertl it also simplifies a lot of things and reduces the actual elements involved ...
1137031226 M * Bertl maybe we should do a testrun of the ngnet PoC if you have a moment?
1137031244 M * Bertl (just to get the idea what it can do)
1137031254 M * eric Sounds sane.
1137031275 M * Bertl do you have a way to boot/test a kernel? do you work with/know QEMU?
1137031303 M * Bertl or should I just copy/paste the stuff here?
1137031311 M * eric I have a test machine with a serial console and remote power control.
1137031330 M * Bertl okay, sounds sufficient, so you can logon via serial, right?
1137031337 M * eric Corret.
1137031353 M * eric I also network boot the machine and pretend it doesn't have a disk.
1137031372 M * Bertl okay, but you _can_ boot from a disk too?
1137031396 M * eric If I need to.
1137031412 M * Bertl okay, you probably will have to ...
1137031426 M * Bertl (unless you put all the stuff into the initrd)
1137031450 M * eric Which is quite fun.
1137031451 M * Bertl get a 2.6.14 kernel tree, patch it with the following patches:
1137031505 M * Bertl http://www.13thfloor.at/vserver/d_rel26/v2.1.0/patch-2.6.14.4-vs2.1.0.diff.bz2
1137031547 M * Bertl http://vserver.13thfloor.at/Experimental/NGNET/delta-ngn0.03.diff
1137031560 M * Bertl enable VNET and NGNET in the kernel config
1137031581 M * Bertl (CONFIG_VNET and CONFIG_VSERVER_NGNET)
1137031610 M * Bertl make sure that you have eth, lo  and vnet as module or compiled in
1137031667 M * Bertl (rest of the kernel can be minimalistic)
1137031673 M * eric Ok It will take me a minute to setup that kernel build.
1137031690 M * Bertl np, I'll search for my test instructions :)
1137031860 M * Bertl ah, I forgot the following patch
1137031865 M * Bertl http://vserver.13thfloor.at/Experimental/NGNET/delta-ngn0.03-fix01.diff
1137031872 M * Bertl ontop of the ngn0.03
1137031888 M * Bertl eric: and you need to get and compile the http://vserver.13thfloor.at/Experimental/NGNET/vdevtag-0.02.tar.bz2
1137031998 M * eric Ok.  The first patch was against 2.6.14.4   That explains why it did not apply cleanly.
1137032044 M * Bertl Makefile issues are no problem, everything else 'should' work except for offsets, no?
1137032048 J * skycode ~skycode@38.169-136-217.adsl.skynet.be
1137032053 M * Bertl welcome skycode!
1137032059 M * skycode hi
1137032436 Q * Doener Quit: Leaving
1137032513 M * Bertl eric: ah, and vnet.c too, but that is just for userspace ...
1137033228 M * eric Where in the kernel menus are the vserver options?
1137033266 M * Bertl main menu, vserver subment
1137033270 M * Bertl *submenu
1137033281 M * Bertl the VNET is in the networking section near the loop
1137033299 M * Bertl but you know, with make menuconfig there is a search option '/' :)
1137033333 M * eric Cool.  That is a feature I have not seen before.
1137033481 M * eric Ok.  I think I have the right options set.  Legacy deisable.  the new VNET enabled.
1137033526 M * eric If finally occured to me why I don't find immutable objects interesting, and haven't considered then.
1137033530 M * Bertl okay, check the NGNET is enabled
1137033550 M * eric (yes)
1137033569 M * Bertl immutable objects?
1137033618 M * eric Sorry omnipresent elements
1137033626 M * Bertl ah :)
1137033662 M * eric They break the ability to do migration.
1137033691 M * Bertl well, that largely depends on the setup
1137033701 M * eric Because you loose guarnatees about being able to take them with you and restore them.
1137033712 M * eric At the very least you can't count on using them when you restore.
1137033733 M * Bertl not more or less than with other interfaces, as long as they are not completely virtual
1137033760 M * Bertl i.e. an interface for example, which is dedicated to a guest, must be present on the destination too
1137033776 M * eric The problem is that you are sharing the ports between contexts.
1137033800 M * Bertl not necessarily, that's where the isolation comes in, which is purely IP based :)
1137033842 M * Bertl so, as long as you do not share IPs too, it's pretty simple
1137033913 M * eric True it just breaks little things like tcpdump...
1137033926 M * eric DHCP...
1137033944 M * eric But it is doable by tagging the ip address with the context.
1137033983 M * Bertl I'm not convinced (yet) that DHCP is a good choice for guests ...
1137034020 M * eric My biggest problem with that approach is that you have to touch a noticeable amount of the logic in the networking stack.
1137034092 M * eric It is certainly worth exploring but to do it you have to invent a completely new way to manage your ip addresses etc.
1137034106 M * Bertl well, it looks really huge, but, considered that you a) do it properly, and b) it really extends the possibilites without adding (noticeable) overhead could make it a nobrainer if it gets into the kernel, no?
1137034107 M * eric That can lead to all kinds of weird and unanticpated corner case.
1137034160 M * Bertl when you have your kernel ready, I can show you a few advantages
1137034243 M * eric Ok.  It is built give me just a minute to configure how to boot it.
1137034268 M * eric I think I know how to get the benefits with a complete separate network stack as well.
1137034295 M * Bertl ad kernel: yeah, don't trust the networking, it 'should' work quite fine but no guarantees there
1137034331 M * Bertl ad benefit: I'm all ears ...
1137034432 M * eric Ok it should be booting in just a second.
1137034503 M * eric Ok it is booting.
1137034533 M * Bertl you got the vnet and vdevtag tools ready?
1137034575 M * eric First I will refer you to drivers/s390/net and the qeth driver.
1137034639 M * Bertl okay, I'm there, what now?
1137034689 M * eric qeth_main appears to be a hypervisor style implementation of what I am trying to describe.
1137034706 M * eric The idea is that you have a primary devices in the root context.
1137034720 M * eric And it has slave devices in the slave contexts.
1137034749 M * eric If you look at the ip address and switch the device in the skb you have just switched contexts.
1137034769 M * Bertl well, that was my first approach to ngnet, but this actually led to huge issues with non-ip traffic
1137034785 M * Bertl especially things like arp and such :)
1137034829 M * Bertl and in the end it becomes more complicated to work around that than to do it 'differently'
1137034891 M * Bertl afk, brb
1137034907 M * eric Ok.  ngnet does not like my boot configuration.
1137035155 M * Bertl back now
1137035207 M * Bertl hmm, in what way?
1137035233 M * eric ngn_tag_sock_skb(f7965c00[#0],c419dea4[#0]) [#0] @/home/eric/projects/linux/linux-2.6-vserver/net/ipv4/ip_output.c:362
1137035233 M * eric sk_filter(c411e000[#0], c6f37500[#0]) [#0]
1137035233 M * eric netif_receive_skb(c6f37440[#0]) [#0]
1137035233 M * eric netif_receive_skb(c6f37440[#0]) [#0]
1137035233 M * eric sk_filter(c411e000[#0], c42a4c80[#0]) [#0]
1137035235 M * eric sk_filter(c411e000[#0], c42a4c80[#0]) [#0]
1137035237 M * eric netif_receive_skb(c6f37440[#0]) [#0]
1137035239 M * eric netif_receive_skb(c6f37440[#0]) [#0]
1137035241 M * eric sk_filter(c411e000[#0], c42a4c80[#0]) [#0]
1137035243 M * eric sk_filter(f7965c00[#0], c6f37440[#0]) [#0]
1137035245 M * eric ngn_tag_sock_skb(f7965c00[#0],c42a4c80[#0]) [#0] @/home/eric/projects/linux/linu
1137035267 M * Bertl well, it has some debug output :)
1137035289 M * Bertl (actually a lot debug output :)
1137035314 M * eric Is this output from unexpected cases?
1137035328 M * Bertl no, just traces through the kernel
1137035371 Q * mountie Remote host closed the connection
1137035376 M * Bertl i.e. you should not logon/work via network 
1137035432 M * eric Which is fine except there is a glitch in my serial console server.  That if it gets totally overwhelmed it goes comatose.
1137035464 M * Bertl hmm .. strange what stuff folks use for serial consoles :)
1137035484 M * eric It is what I manged to scrounge up several years ago.
1137035505 M * eric Anyway that stops that round of testing for a while.
1137035522 M * eric Now that I know what to look for I will just drop the log level next time I try.
1137035547 M * eric Was it just arp you had problems with?
1137035547 M * Bertl okay, let me give you the almost-live experience ...
1137035559 M * eric Sounds good.
1137035577 M * Bertl just have to compile that kernel myself ... will take a few minutes
1137035607 J * mountie ~mountie@CPEdeaddeaddead-CM000a739acaa4.cpe.net.cable.rogers.com
1137035635 M * Bertl wb mountie!
1137035928 M * Bertl eric: well, not only arp, you have to make the host 'believe' that it carries all the IPs the guests/slave devices have, while still mapping received packets into the guests as if they are just arrived
1137035979 M * Bertl you might even succeed to some point, at which communication 'between' guests becomes a real problem ...
1137036052 M * eric I actually have what may be a very different solution to that problem.
1137036052 M * Bertl eric: but a more general question to me is, why do you need/want a '->host' structure attached to the networking entities at all?
1137036090 M * Bertl do you really need it?
1137036143 M * Bertl okay, here is the 'almost live' presentation :)
1137036144 M * eric It is not strictly required, in the checkpoint sense.
1137036149 M * eric Ok...
1137036168 M * Bertl the machine comes up, no interfaces are configured, logon via serial
1137036170 M * eric err. migration sense.
1137036203 M * Bertl the second device (i.e. with identifier 2) is the lo
1137036219 M * Bertl we do: vdevtag -i 2 -n 1
1137036230 M * Bertl which makes the lo device omnipresent
1137036249 M * Bertl then we do: ifconfig lo 127.0.0.1 to get it working
1137036271 M * eric No ip link lo up ?
1137036288 M * Bertl well, yes, right I forgot that
1137036314 M * Bertl then we start the 'evil' tcpdump
1137036317 M * Bertl vnet -C -n 666 -- tcpdump -vvnei lo &
1137036348 M * Bertl and we do a ping in a different context
1137036353 M * Bertl vnet -C -n 42 -- ping -c 1 127.0.0.1
1137036369 M * Bertl which works fine, and can not be seen/traced by the tcpdump
1137036395 M * Bertl in a similar manner we could do the following:
1137036407 M * Bertl - give a device to a specific context
1137036418 M * Bertl - give a device exclusively to the host context
1137036436 M * Bertl - break up the loopback into two 'communicating' interfaces
1137036475 M * Bertl together with (maybe just a partial) stack virtualization this would give the best of both worlds ...
1137036550 M * eric As I recall communicating via lo is about as evil as I can imagine.
1137036565 M * eric However the basic ideas makes sense.
1137036629 M * Bertl well, in this particular case, the lo is the 'real' lo for the guest
1137036648 M * Bertl in case of a 'shared' eth0 it would be the real eth0
1137036667 M * Bertl and in the virtual network setup, it would be a vnet device which does the transport
1137036724 M * Bertl but, this doesn't work with a completely virtualized stack
1137036755 M * Bertl (not to speak of the overhead which could be avoided)
1137036806 M * eric brb
1137036893 M * Bertl nevertheless, a completely virtualized stack in mainline could be adapted to 'work' with the current setup, which would not give the same benefit I expect from ngnet, but would be more flexible than the current implementation 
1137036933 M * eric back.
1137036958 M * eric I'm going to have to find a little time and look through ngnet.
1137037007 M * eric However I think I have partially implmented something that could be used to almost remove the extra trip through the network stack.
1137037015 M * Bertl k, well keep in mind that the patches currently available are just a small part of the whole picture
1137037024 M * eric Certainly.
1137037053 M * eric Would you be willing to watch my virtual demonstration of a packet walking through the network stack.
1137037068 M * Bertl ad ngnet: if you have specific questions, feel free to ask ...
1137037077 M * Bertl ad walk through: sure ...
1137037136 M * eric So first the part I actually have implemented.  In etun_xmit.
1137037155 M * Bertl give me a second to index your kernel
1137037185 M * eric drivers/net/etun.c sorry. 
1137037204 M * eric Instead of doing a dst_relase I do a dst_pop.
1137037302 M * eric The configuration.  The primary context is setup as a router for the slave contexts and has proxy_arp configured.
1137037365 M * Bertl sidenote: which effectively doubles the arp caches
1137037389 M * Bertl okay, I'm there (etun_xmit)
1137037449 M * Bertl the etun is where? inside the guest, no?
1137037478 M * eric etun is setup as a pair of devices typically one in the guest one in the parent.
1137037494 M * Bertl two devices or one device in both contexts?
1137037509 M * eric Two devices.  One in each context.
1137037523 M * eric What one transmit the other receives.
1137037523 M * Bertl okay, that's identical with the ngnet approach then
1137037569 M * eric Yes.
1137037572 M * Bertl btw, this can be 'easily' extended to a group of devices (just for the record)
1137037609 M * Bertl (i.e. what one receives, will be transmitted to the others)
1137037610 M * eric Agreed.  So far I prefer to have them as unidirectional pairs.
1137037631 M * Bertl well, it's a dumb layer 2 switch basically
1137037644 M * Bertl (formerly known as hub :)
1137037659 M * eric So vnet.c appears to have a bug in that it does not call dst_release, and releast it's destination cache entry.
1137037686 M * eric (tried the hub idea it sucks from an implemenation point of view, and has few real benefits).
1137037687 M * Bertl yes, probably, but vnet is not working anyway, so no problem there :)
1137037702 M * eric Agreed.
1137037729 M * eric It is important to know especially for this walk through. 
1137037740 M * Bertl okay, keep going
1137037760 M * eric etun instead of doing a simple dst_release it does a dst_pop.
1137037796 M * eric Which means that if the routing code is smart it can in one lookup find a route through my etun device (which is the idea).
1137037809 M * eric So now to follow a packet.
1137037836 M * Bertl route yes, but what about the tagging?
1137037886 M * eric A packet comes in an an ethernet device and through the windy ways of netif_rx finds its way to netif_receive_skb in (net/core/dev.c)
1137037897 M * Bertl yup
1137037982 M * Bertl the etun_xmit() is called when a process inside the guest 'sends' a packet from a socket
1137038003 M * Bertl is this packet 'tagged' somehow as belonging to that context?
1137038008 M * eric (etun_xmit is in the middle and I wll get to it in a second)  
1137038031 M * eric We see that the packet time is an ip frame and deliver_skb delivers it to the ip layer.
1137038059 M * eric So we get to ip_rcv.
1137038079 M * Bertl special case, but okay ...
1137038117 M * eric (should just be abbrieviating all of the if statements)
1137038126 M * eric This is ip receive on the mast context.
1137038143 M * eric After passing by netfilter we get to ip_rcv_finish.
1137038160 M * Bertl yep, if the packet was accepted ...
1137038180 M * eric Because the packet has not been routed we call ip_route_input.
1137038197 M * eric Once the routing is done we call dst_input.
1137038221 M * eric Since the packet is routed this takes out etun0.
1137038233 M * Bertl okay
1137038240 M * eric We get to etun_xmit and remove the destination cache entry.
1137038265 M * Bertl okay
1137038283 M * eric And then again go to netif_rx, 
1137038293 M * eric netif_receive_skb.
1137038301 M * Bertl right, now the thing becomes interesting ...
1137038307 M * eric deliver_skb and into ip_rcv.
1137038333 M * Bertl how does netif_receive_skb tell that the packet is inside the guest?
1137038337 M * eric And after passing by the netfilter we get to ip_rcv_finish.
1137038351 M * eric Because I have tagged the device.
1137038371 M * eric Actually it really doesn't care it just worries about the devices and the devices cares about the rest.
1137038386 M * Bertl oho, well tagging the device is nice, but it won't work in many cases
1137038413 M * Bertl there are a lot of cases inside the network stack which do not even look at the device
1137038452 M * Bertl (not sure how this ends up with bonding and trunking either)
1137038464 M * eric Tagging devices, sockets, and processes are enough to get that information through the network stack but back on topic. 
1137038489 M * Bertl eric: you're sure about that?
1137038522 M * eric Bertl: Yes it is working beautifully.
1137038547 M * Bertl just with IP or with other protocols too?
1137038595 M * Bertl I would be curious about icmp and the beforementioned dhcp stuff ...
1137038599 M * eric I'm not quite done but I have IP , IPv6  and all of the virtual  protocols working.
1137038625 M * eric There are a few cases where you have to be careful where you look for your information but it works.
1137038658 M * Bertl okay, keep going ...
1137038660 M * eric Anyway the case that I see as interesting on this packet walk through is at ip_rcv_finish....
1137038690 M * eric As implmented now the will be no destination route so we will call ip_route_input again.
1137038713 M * eric Then we will hit dst_input and finally get to ip_local_rcv
1137038760 M * Bertl ip_local_rcv?
1137038773 M * eric Err ip_local_deliver.
1137038790 M * eric And from ip_local_deliver it walks up finds its packet and goes to user space.
1137038804 M * Bertl it's socket, yes ...
1137038823 M * eric Sorry typing too fast.
1137038826 M * Bertl np
1137038861 M * eric In the case described.  NOARP would be set on the etun interfaces so ARP is not needed.
1137038887 M * eric And it is possible to tweak net/ipv4/route.c to realize it is pointing to an etun interface and look at the routing
1137038903 M * Bertl hmm, where does the arp information come from?
1137038907 M * eric table for the next virtual host and set up a stack of destination cache entries.
1137038926 M * eric (for tunnels arp is not needed).
1137038970 M * Bertl well, okay, you were talking about proxyarp on the host, what am I missing here?
1137038996 M * Bertl let's put some arbitrary IPs to the devices just to get a feeeling
1137038998 M * eric With that I can avoid the second invocation of ip_route_input just like the loopback device does.
1137039023 M * Bertl let's assume the host has eth0 at 10.0.0.1 and etun0? at 192.168.0.1
1137039040 M * Bertl while the guest has it's etun0? on 10.0.0.2, right?
1137039056 M * eric Call it etun1 for in the guest.
1137039102 M * Bertl okay, so the packet coming in from somewhere is going to 10.0.0.2 
1137039103 N * eric ebiederm
1137039120 M * Bertl ah, did some eric show up?
1137039127 M * ebiederm yes.
1137039146 M * Bertl best to figure some nick and to register it
1137039147 Q * locksy Read error: Connection reset by peer
1137039158 M * Bertl (will save you some troubles later)
1137039194 M * Bertl okay, back to the networking stuff (or do you need a pause?)
1137039204 M * Bertl s/pause/break/
1137039276 M * ebiederm Back to networking stuff.
1137039304 M * ebiederm /var/log just filled up on one of my machines... 
1137039351 M * Bertl okay, so to send the packet, and arp request for 10.0.0.2 is issued
1137039374 M * Bertl it arrives at the eth0 of the host, what now?
1137039446 M * ebiederm So the host has /proc/sys/net/ipv4/conf/eth0/proc_arp set to 1 
1137039515 M * Bertl s/proc/proxy/ yes
1137039521 M * ebiederm Because proxy arp is set the host looks in it's routing tables and see it has a neighbor of 10.0.0.2
1137039528 M * ebiederm (thanks)
1137039547 M * ebiederm So it sends an arp reply.
1137039555 M * Bertl wait, how does it see that?
1137039575 M * Bertl there was no arp or discovery/packet yet to the guest
1137039587 M * Bertl so the neigh table will be empty on the host
1137039644 M * Bertl (btw, that is one of the issues I encountered with the first ngnet)
1137039645 M * ebiederm When you have tunnels you can turn off arp and the kernel just assumes neighbours you are routed to are there.
1137039675 M * ebiederm If arp is on for the tunnel I believe the kernel performs the arp on the far side first.
1137039677 M * Bertl hmm ... okay, haven't checked that yet ...
1137039700 M * ebiederm I have tested it works but I have successfully followed the code yet.
1137039718 M * Bertl where does the "n't" go?
1137039775 M * ebiederm A neighbor table is only needed when you need to discover your parters mac addresss.
1137039811 M * ebiederm Since on a tunnel which ever mac address you send to will work you can disable the neighbor table.
1137039823 M * ebiederm I think there may be a silly noop entry in there.
1137039834 M * Bertl okay, I just take it that the tunnel is special in this regard
1137039868 M * Bertl (which at least explains why device groups are 'not' trivial in your setup)
1137039870 M * ebiederm You can get this behaviuor with ppp tunnels the loopback device or any other kind of tunnel.
1137039914 M * Bertl well, the loopback is double special, as it insists on adding the addresses as local ...
1137039915 Q * Johnnie Read error: Connection reset by peer
1137039940 J * Johnnie ~john@acs-24-154-53-16.zoominternet.net
1137039944 M * ebiederm True.  But the for the arp case it matches other devices.
1137039963 M * ebiederm The unshare system call is being resubmitted.
1137040000 M * ebiederm You can turn on arp on a tunnel and it will work as normal. 
1137040050 M * ebiederm As for device groups I didn't implement them because they were unnecessary and removed all of the tunnel optimization opportunities.
1137040096 M * ebiederm For proxy arp the mac address returned is the mac address of the router not the machine behind the router.
1137040250 M * ebiederm The other possible configuration that is easy to setup.  Is to just bond etun0 eth0 into br0 the software ethernet bridge.
1137040265 M * ebiederm Then it looks like your guests are directly connected to the ethernet.
1137040275 M * ebiederm Which is where dhcp ccan be interesting.
1137040454 M * ebiederm Bertl: Are you still there?
1137040513 M * Bertl back now, reading up, had a sjprt network outage
1137040554 M * Bertl *short*
1137040626 M * Bertl ebiederm: yeah, that's also what I planned for ngnet
1137040668 M * Bertl now what about loopack (lo)?
1137040697 M * Bertl you probably want to give a separate instance to each guest, right?
1137040715 M * emp has anyone here installed an Oracle database under a vserve?
1137040742 M * ebiederm Bertl: Yes.  and I implement that.
1137040765 M * Bertl emp: not that I know of, but it should work fine as long as you do not need 'special' support like modules
1137040821 M * Bertl ebiederm: okay, well, let's see how good your approach is :)
1137040837 M * Bertl ebiederm: my suggestion would be:
1137040877 M * Bertl - cut out the networking stuff from your patch, and try to break it up into smaller logical pieces 
1137040889 M * ebiederm Agreed.
1137040904 M * ebiederm brb I need to help linus track down why a patch got mangled.
1137040915 M * Bertl - I'll try to integrate this into 'ngnet' or basically make it 'ngnet'
1137040928 M * Bertl ebiederm: np, take your time
1137041138 M * Bertl emp: do you ahve issues or are you just worried that you'd be the first one?
1137041225 M * ebiederm Ok I'm back.
1137041250 M * emp I'm having issues with the Java GUI installer, for some reason, after the first splash screen, the rest of the windows just draw grey..
1137041261 M * ebiederm Some how one of my patches received both a git diff and a gnu diff header and confused the automatic tools.
1137041287 M * Bertl okay .. third:
1137041289 M * Bertl - there are a bunch of folks interested in testing ngnet stuff, so they will put it on test machines and bang on it (with typical applications)
1137041299 M * ebiederm Cool.
1137041322 M * Bertl and in this process we can refine it further ...
1137041331 M * ebiederm I still need to finish up the ipv6 support and then audit the netfilter path.
1137041353 M * Bertl maybe even get some benchmarking done and see where we lose time to virtualization
1137041359 M * ebiederm Then I will be at a stopping point where I will feel comfortable breack my patch into logical changes.
1137041371 M * ebiederm Yep.
1137041395 M * ebiederm But I do agree, that finding a more directway to get packets out of a virtual node is desireable.
1137041403 M * Bertl well, we can do both at the same time, the current networking does not support ipv6, so testing ipv4 only is probably fine
1137041419 M * ebiederm Mostly my gut feel is that it will be just a small optimization from the basic framework I have right now though.
1137041457 M * Bertl well, if that will turn out to be true, even better ...
1137041500 M * Bertl a general suggestion to make the 'approach' compatible to existing virtualizations and jail/isolation projects
1137041524 M * Bertl would be to use some macros for 'retrieving' the actual structures
1137041547 M * Bertl so, instead of doing
1137041556 M * Bertl current->pspace
1137041577 M * Bertl you might consider using task_pspace(current)
1137041615 M * ebiederm I will but I think that will actuall reduce the likely hood of the code getting merged.
1137041619 M * Bertl this would allow projects like linux-vserver, freevps or openvz to just define that one properly
1137041651 M * Bertl because, for example, I'm not very keen on having a separate pspace struct per task, if there already is a vx_info
1137041663 M * ebiederm So for the record that jumbo patch I sent you consists of 93 small patches in my get repository.
1137041695 M * Bertl okay, any chance to get this as separate patches?
1137041723 M * ebiederm Yes but I'm not promising anything until early next week.
1137041739 M * ebiederm Partly the patches wander all over the place as I figured out how to do this.
1137041749 M * Bertl okay, which brings us to the timeframe and your 'planned' milestones
1137041753 M * emp what is the correct way to create a /dev/kmem for a vserver client?
1137041759 M * ebiederm So it's just a little early to be working with code yet.
1137041773 M * Bertl emp: you should not need that, does oracle need it?
1137041817 M * Bertl emp: if you are sure you need/want it, just 'cp -va' it from the host
1137041830 M * emp well, I saw a post, saying that some java based apps need to use xvfb or a virtual frame buffer to draw... i'm wondering if that is what i am missing in running this app
1137041861 M * Bertl well, in any case, it will allow your guest to screw up the host (to some extend)
1137041892 M * Bertl ebiederm: so what are the next steps in your opinion, and what do you expect from my side?
1137041924 M * emp Bertl, it is just a dev box.. so i'm not worried as much about security in this case
1137041956 M * ebiederm Bertl: The next steps are for me to get to a stopping point with networking,  Then I split the patches.
1137041992 M * ebiederm Bertl:  The the patches get moved to 2.6.latest. 
1137042019 M * ebiederm Bertl:  Then we start looking at how to get the network portion working as ngnet.
1137042047 M * ebiederm Bertl: At the same time I start a discussion on the kernel list about what the proper interfaces are for getting
1137042050 M * ebiederm the code into the kernel.
1137042096 M * ebiederm Once we have a feel about what is acceptable to the rest of the kernel developers we worry about things like task_pspace.
1137042111 M * Bertl okay, np with that ...
1137042135 M * ebiederm With any luck this will all be in the next week or two.
1137042162 M * Bertl okay, sounds good to me ...
1137042288 M * ebiederm Ok.  I am going to sign off then. 
1137042298 M * ebiederm Oh...  
1137042323 M * Bertl okay, nice talking to you, I hope we can continue this in the following days/weeks ...
1137042328 M * ebiederm It just occured to me there is one way right now to very quickly transmit data from a guest.
1137042354 M * Bertl hmm?
1137042368 M * ebiederm It's evil but each gust could be given a vlan device off the ethernet interface.
1137042394 M * ebiederm s/gust/guest/
1137042413 M * Bertl hmm, you meant the vlan device is inside the guest, but the main device on the host
1137042420 M * ebiederm Yes.
1137042459 M * Bertl well, could work but might give major headaches to find a switch which can recombine 200 vlans :)
1137042486 M * ebiederm On that same vein....
1137042540 M * Bertl anyway, things like this should be possible ... i.e. to put devices into arbitrary contexts 
1137042540 M * ebiederm What if we used the same principle but used local mac addresses and had the low bits of the mac be the index into which (vlan like device) we are using.
1137042562 M * ebiederm Yes.  I already implemented.
1137042600 M * Bertl yeah, local macs was what I considered for the previous ngnet version
1137042607 M * ebiederm  /sys/class/net/device/new_host_pid
1137042639 M * Bertl eeek, well that's something we probably won't get around on mainline :)
1137042678 M * ebiederm s/device/eth0/
1137042699 M * ebiederm Well whatevers it's call it is just a file to write the an identifier for the context into.
1137042713 M * ebiederm I'm looking up the context by pid at the moment.
1137042729 M * Bertl yes, but it 'pollutes' sysfs (and/or) sysctl/procfs
1137042742 M * emp would capability do you think I have to enable?  _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
1137042773 M * Bertl emp: won't work, ipv6 is disabled inside guests
1137042779 M * ebiederm Bertl:  catch things that ordinarily would be ioctls is part of what sysfs is for.  
1137042838 M * Bertl ebiederm: well, I'm not using ioctls either, but I know that there is a strong tendency away from ioctl toward filesystem interfaces
1137042917 M * Bertl unfortunately, in the typical scenarios (as linux-vserver is used for), this just adds complications ...
1137042923 M * ebiederm Anyway if nothing else it is a starting point for making those things happen.
1137042957 M * ebiederm   Of the pending work sysfs is one of the pieces that is going to be nasty to work with.  
1137042966 M * Bertl yeah, sounds good ... so my part (for now) is just sitting around and waiting ... right?
1137042973 M * ebiederm How do you safely mount sysfs in a guest!
1137042980 M * Bertl ebiederm: not at all :)
1137043027 M * Bertl ebiederm: there was no good reason yet to have sysfs inside a guest
1137043052 M * ebiederm Bertl:  I believe I'm going to need it to support infiniband devices.
1137043066 M * ebiederm But that work is independent.
1137043079 M * Bertl well, it will require virtualization and isolation (similar to proc then)
1137043087 M * ebiederm Yep.
1137043122 M * ebiederm I'm just thinking ahead because I don't want to get 95% of the way there and then find there is some common idiom that won't work.
1137043126 M * Bertl but somebody told me (recently) that he was planning to make proc have different superblocks ...
1137043155 M * Bertl which might actually help a lot (not only for proc but also sysfs)
1137043163 M * ebiederm Right.
1137043197 M * ebiederm I'm thinking mouting /proc /sysfs might actually mount a shared mount subtree.
1137043213 M * ebiederm And you can pick of interesting pieces.
1137043236 M * ebiederm A fun case with my proc implementation is if you start up nested gessts you can do things like.
1137043259 M * ebiederm cd /proc/<pid>/pspace/<pid>/pspace/<pid>/pspace/<pid>/pspace ......
1137043289 M * ebiederm When a guest mounts proc he starts at the subdirectory that is his pspace.
1137043337 M * Bertl btw, how do you handle the 'special' pid inodes used for proc?
1137043354 M * Bertl (inode numbers that is)
1137043408 M * ebiederm Currently I gave up and started using 
1137043425 M * ebiederm The inode numbers generated by new_inode.
1137043441 M * Bertl ah, okay, explains a lot ...
1137043445 M * ebiederm Then I just have a little code to synchronize the two.
1137043466 M * ebiederm syncrhoize lookup and readdir so the agree on the inode number.
1137043472 M * Bertl that will probably need major changes too, as you can easily run out of inodes there
1137043493 M * ebiederm Well when your 32bit counter loops.  
1137043505 M * Bertl hmm, you replaced the fixed entries too?
1137043518 M * Bertl (if not, then it's 16bit)
1137043554 M * ebiederm I replaced the ones that had the pid embedded in them.
1137043604 M * ebiederm Which actually leaves me free util
1137043657 M * ebiederm PROC_DYNAMIC_FIRST is something like 0xf0000000
1137043679 M * ebiederm But it really doesn't matter because it will work correctly even if everything returns the same inode.
1137043690 M * Bertl really?
1137043695 M * ebiederm Just find and it's friends will get annoyed.
1137043732 M * Bertl wouldn't access to those inodes yield 'wrong' results from the dentry cache?
1137043772 M * ebiederm Everything is a pointer to a pointer to a pointer internally.  The inode number is ignored.
1137043802 M * ebiederm This was needed infrastructurally to cope with things like fat that really don't have inodes.
1137043835 M * Bertl ah, okay .. great, one less issue 
1137043939 J * killall killall@82.79.10.19
1137043941 P * killall 
1137043951 M * Bertl ebiederm: k, so let me know when you have something to 'integrate' and/or you want to discuss something ...
1137043955 M * ebiederm Bertl:  Do you have syslog logging all of your verbose log messages anywhere?
1137043963 M * ebiederm Bertl: Will do.
1137043973 M * ebiederm Feel free to pick through my code and ask questions.
1137043990 M * Bertl will do so when I see that you're around ... okay?
1137044017 M * ebiederm okay.  Darn.  Now I have to remember to come up on irc....
1137044028 M * Bertl (gives you a good instrument to control the time :)
1137044069 M * ebiederm Back to my earlier question. have syslog logging all of your verbose log messages anywhere?
1137044085 M * ebiederm That is what filled up /var/log for me.
1137044102 M * ebiederm syslog logged them over the network.  It was an evil loop.
1137044111 M * Bertl well, I don't get the question ...
1137044127 M * Bertl it is basically your syslog configuration, no?
1137044143 M * ebiederm It is.
1137044165 M * ebiederm So you are generating lots of debugging.
1137044172 M * ebiederm It is going to syslog.
1137044181 M * ebiederm And my syslog config logs it over the network to another machine.
1137044187 M * ebiederm Which generates more debugging.
1137044201 M * ebiederm This explains why there was so very very much debugging output.
1137044201 M * Bertl well, not for me, as I do not have a syslogd (or klogd in this case) running
1137044233 M * Bertl but yes, it is not unexpected, as I said, you should not do too much networking stuff :)
1137044249 M * Bertl (at least not with the debug messages enabled :)
1137044296 M * ebiederm Well the debugging option was turned off.  At least that is what I think .config says.
1137044320 M * Bertl ebiederm: comment regarding utsname stuff: this basically looks identical to what we do in linux-vserver ... so we might synchronize that easily ...
1137044336 M * ebiederm Ok.
1137044352 M * ebiederm Do you reset it to the default values when you initialize a guest?
1137044363 M * Bertl yes, they are copied from the host
1137044388 M * Bertl (or in the hierarchical case, they would be copied from the parent)
1137044396 Q * fosco Ping timeout: 480 seconds
1137044436 M * ebiederm So you need to copy everything that isn't nodename and domainname.
1137044447 M * ebiederm For nodename and domainname there are two possible semantics.
1137044451 M * ebiederm copy from the parent.
1137044464 M * ebiederm Set to the boot up values the kernel sets.
1137044472 J * balbir ~balbir@59.145.136.1
1137044486 M * Bertl ebiederm: btw, regarding the 'funny' alpha implementation for pids, I chose to remove the logic from the assembler code and call a C function instead :)
1137044503 M * Bertl welcome balbir!
1137044519 M * ebiederm I think actually using the bootup values fro nodename and domainname is probably preferable.
1137044522 M * Bertl ebiederm: nodename is easy, it is the nodename assigned to the guest
1137044541 M * Bertl domainname is not really used, who uses yellow pages anyway?
1137044595 M * ebiederm *gets really quite, looks around the room* ....
1137044654 M * ebiederm We have some customers who have some really old fashioned setups...
1137044676 M * Bertl but hey, those are details we can 'just' decide as long as the user can modify them easily
1137044686 M * ebiederm Yes.
1137044706 M * ebiederm I've found picking the boot time defaults has all sort of interesting benefits.
1137044726 M * ebiederm My pid 1 isn't even in a session :)
1137044739 M * Bertl which one?
1137044790 M * ebiederm uno.
1137044810 M * ebiederm The one right after CLONE_NPSPACE of course...
1137044848 M * Bertl ah, how do you reparent processes from inside a 'new' namespace which are not reaped by init'
1137044876 M * Bertl (init' being the new init inside the namespace)
1137044922 M * ebiederm So if a processes parent exits and it needs to be reparented it's parent becomes the init inside my process namespace.
1137044926 M * Bertl test case: ... bash -c "sleep 100 &"
1137044984 M * ebiederm Basically the init inside a pspace will have to work really hard to tell it isn't the real init.
1137044999 M * Bertl consider the bash the init
1137045012 M * Bertl what will happen after 100s to the sleep?
1137045054 M * ebiederm A couple of pieces if init exits the entire pspace is destroyed.
1137045065 M * Bertl ah, interesting ...
1137045089 M * ebiederm I have worked hard to keep all of the same rules we have now.
1137045090 M * Bertl so what happens immediately after bash exits to the sleep?
1137045091 J * Smutje ~Smutje@xdsl-87-78-7-76.netcologne.de
1137045104 M * Bertl will it be killed?
1137045120 M * ebiederm From inside the pspace you can't send init a signal either unless it accepts the signal.
1137045153 M * Bertl ebiederm: the problem IMHO is that the 'same rules we have now' do not apply to those cases, because a kernel panic is not an option :)
1137045191 M * ebiederm It depends on how you interpret it.
1137045195 M * Bertl let's assume you have a command to create the new space, and execute a binary ...
1137045203 M * ebiederm I interpret it if init dies the world goes away.
1137045214 M * ebiederm I do.
1137045226 M * Bertl how shall we call that command?
1137045236 Q * Smutje_ Ping timeout: 480 seconds
1137045262 M * ebiederm chpid works for me.
1137045272 M * ebiederm A variant of chroot.
1137045281 M * Bertl okay, so I further assume it has the following syntax
1137045296 M * Bertl chpid <init>
1137045316 M * Bertl and of course
1137045325 M * Bertl chpid <init> <init-args>
1137045333 M * Bertl now we do:
1137045345 M * Bertl chpid bash -c "sleep 100 &"
1137045360 M * Bertl which creates a 'new' init process (the bash) 
1137045371 M * Bertl which in turn spawns the sleep, and exits ...
1137045393 M * Bertl which will be the end of this new world ...
1137045394 M * ebiederm And since init has exited.
1137045405 M * ebiederm All of it's children will be killed.
1137045410 M * ebiederm And the world is gone.
1137045422 M * ebiederm It was a brave new world....
1137045426 M * Bertl so you send a SIGKILL to all of them and wait for compeltion?
1137045433 M * ebiederm Yes.
1137045448 M * Bertl and you reap them in the kernel? or reparent them to the real init?
1137045477 M * Bertl (or is it a hack to avoid that at all)
1137045484 M * ebiederm Actually I don't wait for them I make them self reap.
1137045507 M * Bertl hmm .. interesting ...
1137045509 M * ebiederm But the init process doesn't fully exit until all of the children are goine.
1137045515 M * ebiederm At least I don't think so.
1137045534 M * Bertl well, you have a simple testcase here :)
1137045540 M * ebiederm I know I handled and tested that one but I will have to look to see exactly what I have done.
1137045550 M * Bertl ok, np
1137045558 M * Bertl I guess it's really enough for today ...
1137045578 M * Bertl I had a great time, hope you enjoyed it too ...
1137045593 M * Bertl and I really hope we can continue this ...
1137045594 M * ebiederm Yes.
1137045602 M * ebiederm Will do.
1137045623 M * ebiederm At the very worst this conversation has to be had when arguing for kernel inclusion.
1137045628 M * ebiederm Good night.
1137045639 Q * ebiederm Quit: Leaving
1137045654 M * Bertl I'm off to bed now too .. so have fun everyone, cya tomorrow ...
1137045707 N * Bertl Bertl_zZ
1137046808 J * undefined ~undefined@adsl-68-93-109-94.dsl.rcsntx.swbell.net
1137046862 P * undefined 
1137047523 Q * Johnnie Read error: Connection reset by peer
1137047730 J * Johnnie ~john@acs-24-154-53-16.zoominternet.net
1137048956 P * mcp bloss wech hier ... ;-)
1137050567 J * coocoon ~coocoon@p54A07136.dip.t-dialin.net
1137050570 Q * coocoon Quit: 
1137050614 J * coocoon ~coocoon@p54A07136.dip.t-dialin.net
1137050646 M * coocoon good morning
1137051249 Q * NikDaPhreak Quit: Hybernating my brain....
1137053166 Q * click Ping timeout: 480 seconds
1137053887 J * kongsted ~ak@0x5551697e.adsl.cybercity.dk
1137053901 M * kongsted hi
1137053907 M * coocoon kongsted: hi
1137053920 M * coocoon kongsted : does it work
1137053922 M * kongsted Still having problem...
1137053948 M * kongsted Now it seems like it's installed, but I can't start or test the vserver...
1137053969 M * kongsted if I try testme.sh I got the following error:
1137053977 M * kongsted Linux-VServer Test [V0.14] Copyright (C) 2003-2005 H.Poetzl
1137053977 M * kongsted Can't set the new security context
1137053977 M * kongsted : Invalid argument
1137053977 M * kongsted chcontext failed!
1137053977 M * kongsted Can't set the ipv4 root (Invalid argument)
1137053978 M * kongsted chbind failed!
1137053978 M * kongsted Linux 2.6.14.6 x86_64/0.30/0.30 [E] (0)
1137053980 M * kongsted VCI:  0002:0001 236 03000016
1137054008 M * kongsted util. ver.: util-vserver-0.30.209
1137054117 M * kongsted coocoon any good idears?
1137054140 M * coocoon kongstedt: it seem that it is the same error 
1137054151 M * coocoon kongstedt: u have had yesterday
1137054174 M * kongsted coocoon correct...
1137054192 M * kongsted coocoon but now I had the util correct installed... :-/
1137054220 M * daniel_hozac kongsted: what does vserver-info say? (pastebin)
1137054297 M * daniel_hozac kongsted: oh, i missed that version line. you're running 0.30, not 0.30.209.
1137054344 M * kongsted daniel_hozac why? I had compiled a new util, and installed it... any good resolutions on that?
1137054370 M * daniel_hozac kongsted: did you run make uninstall in the old source tree before installing the new ones?
1137054380 M * daniel_hozac kongsted: did you use the same configure options as before?
1137054396 Q * id23 Ping timeout: 480 seconds
1137054403 M * kongsted daniel_hozac Im not 100% sure about make uninstall ...
1137054428 M * kongsted daniel_hozac but I used the same configure options as you told me yesterday...
1137054450 J * ntrs__ ~ntrs@68-188-50-87.dhcp.stls.mo.charter.com
1137054537 M * coocoon kongstedt: I ever do it in this way #  ./configure --prefix=/usr --sysconfdir=/etc --with-vrootdir=/srv/vservers --localstatedir=/var --mandir=/usr/share/man && make && sudo make install && sudo make install-distribution
1137054697 J * NikDaPhreak ~NikDaPhre@217.75.141.95
1137054703 M * NikDaPhreak hi all
1137054726 M * coocoon hi
1137054852 Q * ntrs_ Ping timeout: 480 seconds
1137054929 J * id23 ~id@p54A0102A.dip0.t-ipconnect.de
1137055677 Q * shedi Quit: Leaving
1137056120 J * mcp ~hightower@wolk-project.de
1137056320 Q * coocoon Ping timeout: 480 seconds
1137056985 J * coocoon ~coocoon@p54A07F37.dip.t-dialin.net
1137057166 J * meandtheshell ~markus@85-125-226-47.dynamic.xdsl-line.inode.at
1137059207 J * shedi ~siggi@tolvudeild-201.lhi.is
1137061367 J * Doener doener@i5387D409.versanet.de
1137061436 M * sizo moin
1137061464 M * schellh hi
1137061816 J * _nokoya young@hi-230-82.tm.net.org.my
1137061969 J * _Medivh ck@paradise.by.the.dashboardlight.de
1137061977 J * Greek0_ ~greek0@85.255.145.201
1137062059 Q * nokoya Ping timeout: 480 seconds
1137062063 N * _nokoya nokoya
1137062079 Q * Medivh Ping timeout: 480 seconds
1137062084 Q * Greek0 Ping timeout: 480 seconds
1137062099 Q * FaUl Ping timeout: 480 seconds
1137062114 Q * waldi Ping timeout: 480 seconds
1137062277 J * FaUl cTsojkzRlu@verbrennung.org
1137062584 Q * daniel_hozac Ping timeout: 480 seconds
1137062609 J * daniel_hozac ~daniel@c-6f1472d5.010-230-73746f22.cust.bredbandsbolaget.se
1137062611 J * waldi ~waldi@bblank.thinkmo.de
1137062707 Q * NikDaPhreak Quit: Hybernating my brain....
1137062712 J * infowolfe ~infowolfe@209-193-52-31-cdsl-rb1.nwc.acsalaska.net
1137064032 J * oliwel ~oliwel@ldvpc07.ldv.e-technik.tu-muenchen.de
1137064049 A * oliwel waves hello to the crowd
1137065703 J * klap ~mikmak@iflap2.ujf-grenoble.fr
1137065723 M * klap hi everybody
1137065777 M * klap i have just started using vserver on a debian amd64, and for some reason, it does not want to configure the network in the guest (altough guest/interfaces/{dev,ip,prefix} are all set)
1137065796 M * klap any idea what I could be missing ?
1137065817 M * klap I can see eth0 in the guest, but it has no ip ...
1137065825 M * Doener klap: how did you check that it isn't configured?
1137065829 M * klap ifconfig
1137065844 M * Doener ifconfig won't tell you unless you use specify an address name
1137065852 M * Doener "ip a" will do without
1137065866 M * klap oh right
1137065867 M * Doener debian package is iproute IIRC
1137065870 M * klap it actually pings :o)
1137065918 M * klap thanks :)
1137065924 M * Doener no problem ;)
1137065973 M * klap hmm, last question, there is no loopback interface apparently, I found the dummy interface tip to set up one, I was wondering if it's still the way to do it ? :) 
1137066023 M * Doener as long as the traffic is local to the box, it'll go through the loopback interface anyway
1137066051 M * Doener if any program tries to access 127.0.0.1 the address is rewritten to the first ip address assigned to the vserver
1137066061 M * Doener so there shouldn't be any problems
1137066065 M * klap ha nice
1137066075 M * klap so no more need for this dummy :)
1137066079 M * klap thanks again :)
1137066091 M * Doener what you should take care of though is that if you want something to be private, make sure it does not listen on a public address
1137066122 M * klap yes of course :)
1137066125 M * Doener say you got postfix that would listen on 127.0.0.1, now your vserver's first ip address is public -> postfix listens on _that_ address
1137066155 M * klap ok, makes sense
1137066161 M * klap I am gonna use real IP anyway
1137066162 M * Doener at least it was like that when i checked the last time... been too busy lately :(
1137066173 M * Doener just wanted you to know ;)
1137066182 M * klap he he thanks :)
1137066193 M * Doener yw
1137067459 Q * zobel arion.oftc.net venus.oftc.net
1137067459 Q * FireEgl arion.oftc.net venus.oftc.net
1137067459 Q * aba arion.oftc.net venus.oftc.net
1137067558 J * zobel zobel@zobel.irc.ftbfs.de
1137067558 J * FireEgl ~FireEgl@Atlantica.US
1137067558 J * aba ~aba@eos.turmzimmer.net
1137068196 Q * Aiken Quit: Leaving
1137070266 Q * Johnnie Read error: Connection reset by peer
1137070381 J * Johnnie ~john@acs-24-154-53-16.zoominternet.net
1137070522 Q * BWare Ping timeout: 480 seconds
1137070552 J * lilalinux ~plasma@h1-gw.of.net-lab.net
1137071062 J * BWare ~bware@office.intouch.net
1137071372 M * lchvdlch morning
1137071511 Q * kongsted Excess Flood
1137071691 J * kongsted ~ak@0x5551697e.adsl.cybercity.dk
1137071821 Q * FireEgl Quit: Bye...
1137072534 Q * brc Ping timeout: 480 seconds
1137072580 P * Johan So Long, and Thanks for All the Fish!
1137072755 Q * flock Ping timeout: 480 seconds
1137073060 Q * Johnnie Read error: Connection reset by peer
1137073511 J * undefined ~undefined@adsl-68-93-109-94.dsl.rcsntx.swbell.net
1137074242 J * dothebart ~willi@xdsl-84-44-231-250.netcologne.de
1137074279 Q * balbir Quit: Leaving
1137074623 Q * tudenbart Read error: No route to host
1137074922 Q * coocoon Quit: KVIrc 3.2.0 'Realia'
1137075000 J * coocoon ~coocoon@p54A07F37.dip.t-dialin.net
1137075506 J * prae ~benjamin@sherpadown.net
1137075866 Q * jsaw Ping timeout: 480 seconds
1137076908 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il
1137078338 N * Bertl_zZ Bertl
1137078342 M * Bertl morning folks!
1137078482 M * BWare morning
1137078705 J * kas_3 tor@tor-irc.dnsbl.oftc.net
1137078714 M * skycode mornin
1137078839 M * Bertl welcome kas_3! morning skycode! morning BWare!
1137078960 M * skycode This might have been asked thousands of time, but does vserver need some help on french translation ? (I guess so so, next q would be how ?)
1137079046 M * Bertl well, IIRC there is some kind of translation (french) of the wiki pages going on, but honestly I'm not convinced that this is something we want ...
1137079061 Q * kongsted Quit: 
1137079072 M * lchvdlch Bertl: spanish?
1137079086 M * Bertl skycode: of course, that is nothing against you or your kind offer ... 
1137079097 M * Bertl (which I really appreciate)
1137079108 M * kilian moint Bertl 
1137079133 M * Bertl skycode: but maybe you can answer the following question for me:
1137079137 M * skycode No worries, I rather use english versions anyway
1137079188 M * skycode english doc are often more extensive
1137079201 M * Bertl except for the (maybe annoying) fact that a french man has to read english descriptions, is there any problem with it? are french administrators or computer users not able to read english?
1137079209 M * Hollow also translkated terminology sounds horrible most of the time ;)
1137079212 M * skycode and vserver is in the deep admin side of the world so english is fine there
1137079242 M * skycode I guess that answers your question ;)
1137079287 M * Bertl okay, I'm happy to hear that, because in this case I would _really_ prefer to enhance the _main_ (english) documentation) than making another copy of (possibly broken/outdated) stuff in language XY ...
1137079315 M * skycode Any directions about that ?
1137079365 M * skycode Personnaly i run a small hosting company, and I wouldn't hire a sysadmin that can't read an english doc ... but I never camme accross the case
1137079407 M * skycode Hos can we contrbute to the main doc improvment ? (IS my English good enough ?)
1137079422 M * skycode appart from typo errors :-s
1137079475 M * Bertl well, one very _interesting_ point would be the FAQs
1137079501 M * Bertl we have a bunch of different pages which contain hints and answer faqs in different ways ...
1137079530 M * Bertl also there are many FAQs answered on the channel (IRC) only, but they are not transcribed to the wiki
1137079568 M * skycode but there are public IRC logs I guess ?
1137079570 M * Bertl collecting this information, structuring _and_ verifying it would be invaluable help ...
1137079622 M * Bertl skycode: yep, there are public logs ... see http://irc.13thfloor.at/LOG/2006-01/LOG_2006-01-12.txt
1137079660 M * skycode ok, I'll try to give it a go on spare time (mostly nightly :-))
1137079667 M * skycode nothing to do with doc
1137079690 M * skycode but is the project in need of miroring, and if so, what are the requirements
1137079726 M * skycode (I'd like to contribute, because we are startingto use vserver extensivly and will be releasing the prod servers in about a month)
1137079767 M * Bertl atm no, mainly because we haven't spent the time to switch to something like mediawiki and make it distributed, but the time will come, I'm sure about that, and if you leave me some way to contact you, I will keep that in mind ...
1137079848 Q * kas_3 Quit: Leaving
1137079890 M * oliwel Hollow: ping
1137079895 M * Hollow pong
1137079911 M * oliwel Hollow: I have problems with vserver-new and a gentoo stage install....
1137079928 M * oliwel very recent (emerge yesterday ~x86)
1137079945 M * Hollow error message?
1137079968 M * oliwel I do vserver-new .... stage3 stage3...tgz
1137079980 M * oliwel and get "unsupported arch or no such profile"
1137080001 M * Hollow you have to add x86 or amd64 at the end
1137080006 M * oliwel ?
1137080012 M * oliwel what means "at the ned"
1137080016 M * oliwel as paramter ?
1137080020 M * Hollow yup
1137080048 M * oliwel ahhh - than ypou should fix this http://www.gentoo.org/doc/en/vserver-howto.xml
1137080072 M * oliwel beside: whats the difference between stage and template ?
1137080079 M * Bertl skycode: btw, did you already add yourself/company to the Provider Page?
1137080113 M * skycode not yet
1137080121 M * Bertl I usually point folks there when they are looking for guests ...
1137080138 M * skycode is it worth before actually having it in production ?
1137080142 M * Hollow oliwel: yeah, will be added with the next update..
1137080169 M * Hollow stage target uses ateg3 and installs syslog-ng and updates some configs, templates just unpacks a tarbal
1137080175 Q * flock Ping timeout: 480 seconds
1137080177 M * Bertl skycode: you decide, but IMHO it can't hurt, just modify it lateron with some info about the type of service
1137080206 M * Bertl Hollow: does the persistance for network contexts work as expected?
1137080210 M * Hollow .oO(i should add myself to the provider page too)
1137080215 M * Hollow Bertl: yep, thanks
1137080221 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il
1137080244 M * Bertl Hollow: good, because I didn't test it ... :)
1137080539 M * oliwel Hollow: you are playing ISP ;)
1137080573 M * oliwel Hollow: what are "some configs" - just for interest...I installed the one here for testing now from the stage-arhciv buit with template...
1137080588 M * Hollow oliwel: i don't play ISP, i am ISP ;)
1137080600 M * Hollow syslogöng.conf and make.profile
1137080678 M * oliwel Hollow: *gg*
1137080819 M * Hollow oliwel: btw.. do you study info at the TU?
1137080900 Q * flock Ping timeout: 480 seconds
1137081005 M * oliwel Hollow: Twice wrong - I finished study at TUM, but in electrical engeneering, I am currently working on my Dr.
1137081014 M * oliwel www.ldv.ei.tum.de/page42
1137081024 M * oliwel think that we discussed this some time ago..
1137081050 M * oliwel wrong link: http://www.ldv.ei.tum.de/page47
1137081065 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il
1137081560 M * Hollow ah, ic
1137081593 M * Hollow hm.. remembers me.. i have taken a current photo yesterday..
1137081608 M * Hollow but i guess you prefer not to be shocked :P
1137081671 M * oliwel I am hard....can take it :)
1137081677 P * undefined 
1137081682 M * oliwel Think we shpuld meet up....
1137081687 M * oliwel ...should..
1137081687 M * Hollow http://home.xnull.de/misc/me060111.jpg
1137081695 Q * flock Ping timeout: 480 seconds
1137081698 M * oliwel even if you are that much younger :P
1137081722 A * oliwel dropping on the floor...
1137081729 M * Hollow well.. ;)
1137081743 M * Hollow age doesn't matter
1137081758 M * oliwel So - if you want to - feel free to come over here - I am at Königsplatz
1137081766 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il
1137081773 M * oliwel no not really  my students ever tell me taht i am not adult...
1137081792 M * Hollow oh, i could come by feet i guess ;)
1137081814 M * oliwel You are at the Luisen Gymnasium ?
1137081827 M * Hollow no, rupprecht
1137081841 M * oliwel So - I have to leave...its past five, too late for employees here ;)
1137081844 M * oliwel hmm, ok...
1137081857 M * oliwel so perhaps if you want to, I will be here tommorow till at least 15.00
1137081862 M * oliwel gotta go...
1137081864 M * oliwel bye
1137081865 M * Hollow cu
1137081871 M * oliwel drop me a mail - or ICQ me...
1137081884 M * Hollow nr?
1137081907 M * Hollow do you hva jabber?
1137081909 M * oliwel 5407677
1137081911 M * oliwel no jabber
1137081914 M * Hollow ok
1137081921 M * Hollow you're online at home too?
1137081930 M * oliwel yepp
1137081934 M * aba well, we could just do some vserver-meeting here some day ...
1137081937 M * Hollow fine, cu later then, i guess ;)
1137081958 M * oliwel partially - have training tonight
1137081959 M * Hollow aba: you're from..?
1137081973 N * oliwel oliwel[away]
1137082001 J * Cru ~mindwarp@bastardrouterfromhell.e.de.wahlich.com
1137082015 M * Cru morning
1137082068 M * aba Hollow: munich
1137082093 M * Hollow hm, yeah, guessed that since you suggested a meeting.. ;)
1137082100 M * aba ok :)
1137082102 M * Bertl welcome Cru!
1137082112 M * Hollow i mean where in muc?
1137082122 M * aba I live on one side, and work on the other.
1137082172 M * aba so, if some meeting is done at a not too bad location, I'd join
1137082253 M * Hollow Bertl wouldn't have too far too.. ;)
1137082266 M * aba Bertl: ok, when and where do we meet? :)
1137082271 M * Hollow heh
1137082273 M * phreak`` Hollow: well Vienna is a bit far :P
1137082287 M * Hollow phreak``: wrt the whole world, not really
1137082291 M * Hollow ;)
1137082300 M * Bertl yeah, let's meet in vienna :)
1137082305 M * Hollow haha
1137082308 M * aba no, Vienna is too far :)
1137082326 M * mnemoc 21h in plane from here :)
1137082349 M * Bertl regarding too far .. is anybody interested to watch a presentation on upcoming LinuxTag?
1137082364 M * Bertl (this time in Wiesbaden, May 2006)
1137082400 M * Hollow sure ;)
1137082400 M * phreak`` Hollow: yah I know, I've I would try to join, I would be a bit farer (no idea if that's spelled right :P)
1137082401 M * mnemoc english?
1137082403 M * aba Bertl: at that time, I'll be on Debconf in Mexiko
1137082404 M * mnemoc subtitles?
1137082430 M * mnemoc .oO( since when mexico is written with k? )o
1137082447 M * phreak`` mnemoc: it is (in german)
1137082450 M * Hollow since it was translated to german
1137082453 M * Hollow :P
1137082455 J * NikDaPhreak ~NikDaPhre@217.75.141.95
1137082455 M * mnemoc german freaks :)
1137082459 M * phreak`` yah :P
1137082461 M * NikDaPhreak hi all
1137082462 M * Bertl mnemoc: if you come, I'll do the presentation in english (of course :) 
1137082502 M * mnemoc .oO( vienna, may 2006? ..... interesting proposal )o
1137082503 M * phreak`` 03-06. May ... hrm ..
1137082517 M * Hollow vienna?
1137082522 M * Hollow wiesbaden
1137082540 Q * flock Ping timeout: 480 seconds
1137082577 M * Hollow Bertl: if you're going to linuxtag, is there a free seat in your car? :)
1137082587 M * Hollow not sure if i get a car
1137082606 M * phreak`` lol :P that sucks, changing trains at 04:00
1137082666 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il
1137082717 M * Bertl Hollow: not sure I should come by car, IIRC they still didn't manage to pay for my expenses, because I came by car (with a train ticket, that would have been much easier)
1137082742 M * Hollow ah, ic
1137082748 M * Hollow i hate traveling by train ;)
1137082934 M * meandtheshell Bertl: tell me where you will do a recitation - I'll be there - preferably at the vienna Linux days 2006 - just takes me 20 minutes to get to the "musems quatier" :-)
1137082964 M * meandtheshell have watched you performing in 2005 - since then I loooooove linux-Vserver
1137082977 M * meandtheshell lol
1137082991 M * Bertl well, I will definitely be at the next Linux Days (in vienna)
1137083004 M * meandtheshell me too 
1137083014 M * aba Bertl: would you come to a talk to Munich if we organize it? :)
1137083054 M * Bertl probably ... what do you have in mind?
1137083136 M * Hollow hm, we could do a workshop e.g.
1137083164 M * Bertl I'm aiming for a tutorial on LinuxTag
1137083175 M * Hollow wiesbaden or vienna?
1137083186 M * Bertl Hollow: if you are interested in doing something like that (wiesbaden)
1137083215 M * Hollow yeah, i'm not the one for speeches and talks, but workshops or tuts are fine for me
1137083260 Q * flock Ping timeout: 480 seconds
1137083308 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il
1137083392 J * monrad ~mikkel@213083190131.sonofon.dk
1137083433 J * mnmr ~mnmr@217.116.235.96
1137083442 M * mnemoc Bertl: where are you from?
1137083459 M * Bertl welcome mnmr!
1137083471 M * mnmr thanks! :) .. hi all!
1137083483 M * Bertl mnemoc: Vienna, Austria, Europe, Earth, Milkyway 
1137083495 M * mnemoc Bertl: before vienna i mean
1137083538 M * Bertl hmm, you mean the district? 
1137083564 M * Bertl I was born in vienna, I do not live there anymore ...
1137083575 M * mnemoc oh
1137083583 M * mnemoc i thought it was in the other way
1137083599 M * mnemoc you born and grow somewhere, and then move to vienna
1137083625 M * Bertl ah, no, we fled from the big-ugly-city ...
1137083640 M * michal_ is viena big'n'ugly ?
1137083658 M * aba Bertl: where do you live now?
1137083666 M * Bertl well, according to the traveling agencies it's beatiful :)
1137083678 M * aba Bertl: just a regular talk or so. If you're in Munich for some other reasons, I mean :)
1137083685 M * Bertl aba: in the vicinity, roughly 80km away ...
1137083695 M * aba Bertl: ah, ok
1137083708 M * aba still Vienna for ignorant people :P
1137083976 J * stefani ~stefani@superquan.apl.washington.edu
1137084015 M * Bertl welcome stefani!
1137084116 M * meandtheshell Is anybody running "djbdns" http://cr.yp.to/djbdns.html inside a guest? or on the host maybe? as BIND is working "djbdns" sould work too (i guess so) - I'll try to run djbdns inside a guest (but I think it will take 2-3 months from now on; other things on my "TO DO List" before)
1137084154 M * stefani hola 
1137084159 M * Hollow Bertl: btw.. the syscall for the new scheduler is still missing... by intention?
1137084195 M * stefani meandtheshell:   i know that maradns works in a vserver.
1137084200 M * Bertl Hollow: hmm?
1137084206 M * Hollow set_sched_v4?
1137084224 M * Bertl it is there, (i.e. it is the default interface now)
1137084251 M * Hollow hm, in switch.c yep.. but it's missing in sched.h no?
1137084274 M * Bertl you mean sched_cmd.h?
1137084287 M * meandtheshell stefani: ok - dont know maradns - but should work as good/bad than BIND, djbdns etc. 
1137084307 M * Bertl Hollow: struct  vcmd_set_sched_v4 {
1137084316 A * Hollow goes looking
1137084318 Q * mkhl Quit: 
1137084349 M * Hollow hm, no.. missing here
1137084358 M * Bertl really?
1137084368 M * Bertl let me check that, just a second ...
1137084389 M * Hollow but it's in the patch
1137084391 A * Hollow wonders
1137084543 M * Hollow it's even in the gentoo patch tarball.. wtf
1137084565 M * Bertl okay, verification of the patches looks like everything is there ...
1137084645 Q * cryo Read error: Connection reset by peer
1137084683 M * Hollow Bertl: anyway... will implement the changes in vserver-utils now
1137084742 J * cryo ~say@212.86.233.146
1137084766 M * Bertl excellent, you might look at the vsched tool, and get a feeling how the new interface works first .
1137084786 M * Bertl wb cryo (say)!
1137084787 M * Hollow yup, already scaned the source
1137084815 M * Bertl the idle flag is a little special (regarding how it is set)
1137084864 M * Bertl and the bucket id is not used yet ...
1137084874 M * Hollow ok
1137084896 M * Bertl so setting the RATE2/INTERVAL2 separately requires two syscalls
1137084923 J * tachauch ~m@dsl47-217.pool.bitel.net
1137084932 M * Bertl Hollow: well, the set itself requires only one
1137084938 M * Bertl welcome tachauch!
1137084985 M * Hollow Bertl: what's the idle setting for? isn't it configured in the kernel?
1137085015 Q * flock Ping timeout: 480 seconds
1137085031 M * Bertl the kernel config option is a requirement, but the flag decides if the context will be able to use idle time or not
1137085044 M * Hollow ok, and what does it do?
1137085100 M * Bertl it's actually quite simple, and we figured that in princeton when we (Andy and myself) had a longer discussion about the scheduler ...
1137085109 M * tachauch hello Bertl ... :)
1137085115 M * Bertl Hollow: consider hard limits for all guests ...
1137085141 M * Bertl further assume that allguests are running a cpuhog
1137085150 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il
1137085173 M * Bertl when the token buckets are empty, the idle process will be scheduled
1137085218 M * Bertl the new scheduler now artificially advances time to that point where enough tokens would be available (for those guests which have the idle time flag set)
1137085219 M * Hollow the idle process means the process is idle, or there is a special idle task?
1137085228 M * Bertl a special idle task
1137085231 M * Hollow ok
1137085258 M * Bertl to make this a little more configurable, we added the separate interval and rate values
1137085287 M * Bertl so, the artificially advanced time will be accounted as rate2/interval2 not rate/interval
1137085341 M * Hollow ok, and what's the benefit?
1137085343 M * Bertl this allows all kinds of configurations, from 'strict' hard scheduling over guarantees to fair scheduling
1137085352 M * Hollow hm
1137085439 M * Bertl for example, if you 'just' want to distribute the cpu evenly to all guests, then you would only use the idle time, and do not give away tokens when the cpu is busy ...
1137085480 M * Bertl a probably saner way is to give away a certain share by default and distribute the idle time evenly
1137085499 M * tachauch is there any better information about /etc/vservers/... than on the flower-page?
1137085519 M * phreak`` tachauch: nope, the flower-page are the best location for that ..
1137085520 M * Bertl tachauch: probably not, what issues do you have with the flower page?
1137085535 M * phreak`` Bertl: probably the flower's ;)
1137085541 M * Hollow Bertl: i.e. i set both RATE and RATE2 for fair scheduling?
1137085543 M * tachauch hehehehe 
1137085579 M * tachauch where can I modify how the init process ist started ... parameters ...
1137085607 M * tachauch I have a Gentoo-Guest and Gentoo-Host .... vs2 starts some processes but not the normal init process with runlevel default
1137085617 M * Bertl Hollow: you could get away setting just the /2 values, but this would mean that if the host is running a cpu-hog, no guest will be scheduled at all :)
1137085624 M * tachauch (I guess runlevel "default" ist a Gentoo thing)
1137085683 M * Hollow Bertl: so the difference is that the "old" configuration adds tokens back to the bucket even if the cpu is busy, the "new" settings prevent this?
1137085737 M * Bertl yes and no, the new scheduler has a few changes (compared to the old one)
1137085753 M * Bertl let me list them and comment on them one by one
1137085769 M * Hollow ok :)
1137085773 M * Bertl - the token buckets are now per cpu
1137085803 M * Bertl - tokens according to rate/interval are added when time passes by
1137085825 Q * flock Ping timeout: 480 seconds
1137085835 M * Bertl - tokens according to rate2/interval2 are added when the cpu would be idle and idle time is selected
1137085870 M * Bertl - tasks are put on hold queues and/or are rescheduled on different cpus
1137085930 M * Bertl so, given that hard scheduling is enabled, and the parameters are set, it will behave very similar to before (identical on UP)
1137085958 M * Bertl the difference is when it comes to scheduling the idle task
1137085994 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il
1137086030 Q * NikDaPhreak Quit: Hybernating my brain....
1137086042 M * Bertl in this case, before idle is scheduled , the idle time is advanced by the smallest amount of time required to unhold a task
1137086085 M * Bertl (in the future, it might show beneficial to make that interval larger)
1137086121 M * Bertl and the idle tokens are distributed for all affected guests
1137086158 M * Bertl after that, a task/context should be ready for scheduling, which will happen if that is so
1137086189 M * Bertl effectively avoiding idle cpu's if there is still work to do
1137086274 M * Hollow hm.. guess have to reread your explanation some times during implementation.. 
1137086297 M * Bertl for userspace, it basically means that you want to be able to do the following:
1137086340 M * Bertl set fill_rate/interval/(tokens)/tokens_min/tokens_max/prio_bias
1137086356 M * Bertl set the additional fill_rate2/interval2 (requires a separate syscall)
1137086373 M * Bertl (unless they are identical to the fill_rate/interval)
1137086401 M * Bertl set or clear the idle_time flag
1137086486 M * Bertl the small complication here is that setting/clearing the idle_time flag is non trivial, and what I forgot to tell is
1137086494 M * Hollow yeah, guess the implementation itself is quite easy, but i'd like to understand it too ;)
1137086504 M * Hollow and i still have probs to understand the old scheduler some times ;)
1137086510 M * Bertl the values will not be set when the syscall is executed
1137086543 M * Bertl they will be copied over to a hold buffer, and when the context is scheduled on the 'updated' cpu, the values will be updated too
1137086594 M * Bertl so, in special cases it might happen that certain cpus are not updated at all, because they do not execute tasks from that context
1137086618 M * Bertl (exception again is UP which directly updates the values)
1137086642 M * Hollow guess you have to talk at linuxtag about it ;)
1137086656 M * Bertl probably :)
1137086664 M * meandtheshell guess so too - hm ...
1137086786 M * Hollow an interesting question would be if we can ease the scheduler settings in userspace.. because i - as user - don't want to understand the whole kernel schulder for just setting 20% cpu for guest xy ;)
1137086815 M * Bertl yes, that's something we should do, but probably with some scheduler daemon
1137086839 M * Bertl which is able to recalculate the slice settings when a guest is started/stopped
1137087201 Q * shedi Quit: Leaving
1137087319 M * Bertl Hollow: the userspace logic (currently used in vsched) is that you can put the -i before and after the settings ...which will change what is actually set in the flags, but it doesn't do a separate syscall
1137087583 M * Bertl (i.e. you would have to call it twice to set all arguments)
1137087593 M * Hollow oki
1137088189 J * argh ~bsd@adsl-ull-115-233.50-151.net24.it
1137088336 M * Bertl welcome argh!
1137088368 M * Roey argh:  hehehhee
1137088370 M * Roey hey Bertl
1137088403 M * argh hi
1137088454 J * undefined ~undefined@adsl-68-93-109-94.dsl.rcsntx.swbell.net
1137088464 M * Bertl wb undefined! hey Roey!
1137088465 Q * argh Quit: 
1137088487 M * undefined hello Bertl
1137088823 N * Roey HesDeadJim
1137088846 N * HesDeadJim Roey
1137089462 Q * tachauch Remote host closed the connection
1137090396 J * Smutje_ ~Smutje@87.78.99.56
1137090417 M * micah Bertl: I'm trying to find changes between 2.1.0 and 2.1.0.3/2.1.0.4 is there a Changelog somewhere?
1137090459 M * Bertl not yet, but the changes are:
1137090486 M * Bertl http://vserver.13thfloor.at/Devel/PAT-2.1.1/
1137090500 M * Bertl (plus the required modifications for 2.6.15)
1137090506 Q * Smutje Ping timeout: 480 seconds
1137090515 M * micah (i'm putting the development packages in experimental packages, and am trying to keep a record of changes so that when it comes time for 2.1 to be released it will be easy to put together
1137090519 M * Bertl http://vserver.13thfloor.at/Devel/PAT-2.6.15/
1137090619 M * micah does "feat" mean "feature"? such as delta-slab-feat01
1137090641 M * Bertl yep
1137090685 M * Hollow Bertl: btw.. is prio_bias still unused?
1137090705 M * Bertl no, it should be used for the vavavoom calculations now :)
1137090714 M * Hollow vavavoom?
1137090743 M * Bertl don't look at me, that's how Sam called it :)
1137090791 M * Hollow and what does it do?
1137090897 M * Bertl check out the comments in vx_effective_vavavoom() include/linux/vs_sched.h
1137090960 M * Bertl btw, the prio_bias is even honored with VXF_SCHED_PRIO set off (see vx_adjust_prio())
1137091074 M * Hollow hm.. this scheduler stuff confuses me like hell tbh.. do you know some paper on the vanilla scheduler?
1137091134 M * Bertl there are a bunch of them out there, let me see if I can find one (but the source is nicely documented there)
1137091237 M * Hollow ok, thanks.. taking a shower now, biab
1137091296 J * bonbons ~bonbons@83.222.39.249
1137091297 M * micah Bertl: ok, I tried to extrapolate descriptory changes from those patches, this is what I have so far:
1137091304 M * micah     . Modifications to work with upstream 2.6.15
1137091305 M * micah     . sendfile fix
1137091305 M * micah     . percpu fix
1137091305 M * micah     . scheduler effective_prio percpu token feature added
1137091305 M * micah     . any ip? feature added
1137091307 M * micah     . proc CAP_CONTEXT admin override fix
1137091310 M * micah     . 64bit fixes
1137091312 M * micah     . reiserfs inode attribute fix
1137091315 M * micah     . indev fix
1137091317 M * micah     . fix for undefined RLIM_INFINITY, and redefine VX_VLIM and VX_RLIM
1137091320 M * micah     . slab? feature added
1137091400 M * micah does it help to tease out these changelog items, so that when things are released they can be easily put together?
1137091473 M * Bertl okay, okay, I'll write a changelog entry for that :)
1137091610 M * micah :) I will collect all the changelogs for you so when the next release happens they dont have to be reconstructed by looking at each patch
1137091880 M * Cru bbl
1137091891 Q * Cru Quit: use Unices; $live->free() || die;
1137092466 M * micah Bertl: i forgot to mention that util-vserver 0.30.209 with the shiny mips fix was uploaded. Kilian/waldi haven't been able to get a mips machine to boot due to a broken initramfs so we haven't been able to test it yet
1137092489 M * Bertl ah, okay, great anyway!
1137092510 M * kilian micah: it's booting now, but only until init SCSI..
1137092522 M * kilian micah: for some reason it hangs there with no further message..
1137092536 M * kilian micah: if you got any idea what's wrong there, i'm all ears..
1137092550 M * kilian micah: apart from this, hppa has a broken dietlibc build..
1137092555 M * lonewolff evening all
1137092557 M * micah kilian: try building scsi in th kernel to see if that works?
1137092573 Q * coocoon Quit: KVIrc 3.2.0 'Realia'
1137092574 M * micah kilian: dietlibc hrm, any ideas why?
1137092580 M * kilian micah: bertl does reckon he's just getting his hppa ready to run, so we should know r.s.n. ;)
1137092585 M * Bertl kilian: controller issues? the famous soft lockup?
1137092586 M * kilian micah: nope, not yet..
1137092594 M * kilian Bertl: looks like:
1137092595 M * kilian CPU 1 clock is 270MHz.
1137092595 M * kilian Brought up 2 CPUs
1137092595 M * kilian NET: Registered protocol family 16
1137092595 M * kilian SCSI subsystem initialized
1137092598 M * kilian -(snip)-
1137092601 M * kilian nothing past this
1137092620 M * kilian but it's doing a tftp-booting.. maybe it's not using initrd properly..
1137092634 M * kilian i'll try to talk to ths as soon as he'll be on IRC
1137092661 M * kilian probably this is something he can talk me through within minutes, tricky part is having him on IRC :-D
1137092831 Q * michal_ Ping timeout: 480 seconds
1137092889 J * michal_ ~michal@mprivacy-update.de
1137093094 M * Bertl kilian: hmm, maybe it initializes serial console or whatever, which switches the output to some different terminal?
1137093139 M * kilian Bertl: i'll try with the softlockup being disabled first..
1137093515 M * kilian mmmmmmh
1137093527 M * kilian there is no SOFTLOCKUP in the .config?!
1137093606 M * kilian micah: SCSI itself is compiled into the kernel
1137093668 M * kilian micah: and so is the SCSI controller
1137093849 M * Bertl micah: http://linux-vserver.org/ChangeLogDevel26
1137094020 M * cryo wb, Bertl.
1137094058 M * mnmr bertl: very nice with a changelog update!
1137094152 M * cryo Bertl, Now temporary I don't work on FreeVPS so don't ask me about news :) However, look at our new project http://nocmonkey.psoft.net, it's very cool.
1137094375 M * Bertl cryo: sounds interesting! will it be GPL?
1137094451 M * phreak`` Bertl: doesn't seems so. Have a look at http://nocmonkey.psoft.net/order.html
1137094578 M * Bertl phreak``: well, it could be that they are testing it on paying customers, but plan to release it under GPL later, no? :)
1137094590 M * phreak`` Bertl: yeah, that could be ;)
1137094632 M * Bertl okay, off for a little, back later (when the parisc is done)
1137094644 N * Bertl Bertl_oO
1137094656 M * phreak`` have fun Bertl_oO :)
1137094873 J * coocoon ~coocoon@p54A07F37.dip.t-dialin.net
1137094884 M * coocoon howdi
1137094932 M * mnmr hello there
1137094961 Q * prae Quit: Pwet
1137096446 M * micah Bertl_oO: ohh, nice!
1137097391 Q * emp Ping timeout: 480 seconds
1137100800 P * meandtheshell 
1137100937 Q * bonbons Quit: Leaving
1137100950 J * emp ~emp@70.57.239.35
1137101831 Q * samuel_ Ping timeout: 480 seconds
1137102228 M * coocoon hello is tagxid possible with reiserfs
1137102526 Q * coocoon Quit: KVIrc 3.2.0 'Realia'
1137102618 M * sizo n8
1137103286 P * undefined 
1137103827 P * mnmr 
1137104240 Q * flock Ping timeout: 480 seconds
1137104850 J * mef ~mef@12.105.241.26
1137104880 M * mef dumb kernel args question: what is the difference between pci=noacpi and acpi=off?
1137105368 M * michal_ acpi=off completely turns off acpi subsystem
1137105391 M * michal_ while pci=noacpi is using old plain plug'n'pray'n'bios to find out devices on pci bus
1137105396 M * michal_ instead of using acpi for it
1137105406 M * michal_ but the rest of the acpi stays active
1137105572 J * undefined ~undefined@adsl-68-93-109-94.dsl.rcsntx.swbell.net
1137106409 J * menomc ~amery@200.75.27.59
1137106516 Q * mnemoc Ping timeout: 480 seconds
1137106516 N * menomc mnemoc
1137106781 P * stefani I'm Parting (the water)
1137108985 M * mef michal_: thanks