1138839264 J * ntrs ~ntrs@68-188-50-87.dhcp.stls.mo.charter.com 1138841634 N * Bertl_oO Bertl 1138841638 M * Bertl evening folks! 1138841943 M * Doener evening Bertl 1138842059 Q * bwana Quit: doh 1138842078 M * Bertl hey Doener! 1138842722 J * weasel weasel@weasel.noc.oftc.net 1138842835 M * Bertl welcome weasel! 1138843016 M * Doener hm, learning to use automake the right way seems harder than learning C... 1138843034 M * Bertl which one of the 20 versions out there? 1138843072 M * Doener that's another question ;) I'm pretty happy to finally have it actually working for building some stupid library... 1138843081 M * Doener works here, probably nowhere else :) 1138843088 M * Bertl ooh, you do? 1138843139 M * weasel moin 1138843157 M * Doener the library only has a single function in it, so it might break easily later ;) and i have probably missed a bunch of checks i should've included etc. 1138843179 M * Bertl Doener: btw, the *VZ broken out code is funny ... 1138843263 M * Bertl 836402 vemix-20060120-core.diff 1138843263 M * Bertl 385950 ubc-20060120.diff 1138843263 M * Bertl 157609 vzdq-20051219-2.diff 16285 kmemcache-headers-200051213.diff 1138843265 M * Doener any specific file that's worth laughing^Wlooking at? 1138843276 M * Bertl everything else is below 9k 1138843294 M * Doener *lol* 1138843295 M * Bertl but I like the meaningful names 1138843305 M * Bertl static DECLARE_COMPLETION(license_thread_exited); 1138843325 M * Bertl in static int wdog_loop(void* data) 1138843330 M * Doener license thread? what's that? some kind of advanced nag screen? 1138843358 M * Bertl well, I guess it increases reliability and security :) 1138843381 M * Doener of their bank accounts, eh? ;) 1138843392 M * Bertl lol 1138843610 M * Bertl ah, btw, I implemented inode attributes for jfs :) 1138843684 J * Aiken_ ~james@tooax8-182.dialup.optusnet.com.au 1138843702 M * Doener http://download.openvz.org/kernel/broken-out/2.6.15-025stab014.1/diff-simfs-statfs-20051228 1138843707 M * Doener hu? 1138843730 M * Bertl well, the have a separate filesystem 1138843745 M * Bertl which basically adds a mapping layer (like unionfs) 1138843780 M * Bertl and this is the _new_ virtualization for disk info :) 1138843791 M * anonc Bertl: with the current 2.1 series and COW links enabled, is iunlink-but-not-immutable still the correct flag or is it just the iunlink flag now for files you want to behave as copy on write? 1138843818 M * Doener Bertl: it's more like: why do they split a 9kb patch into a 8kb one + bugfix(?) 1138843826 M * Bertl anonc: iunlink-but-not-immutable is just the iunlink flag (as the name suggests) 1138843845 M * Bertl anonc: --iunlink will do what you want (i.e. both flags) 1138843901 M * weasel so, what do I read when I want to know where and how ip packets go, and how to firewall and route it all in interesting ways? 1138843908 M * Bertl anonc: the flag name is a little confusing, I agree, and enrico managed to bring that confusion into userspace 1138843929 M * Bertl weasel: really depends on your setup, you have a bunch of options there 1138843943 M * anonc Bertl: ok - i thought iunlink-but-not-immutable used to show up as U with lsattr, but now it doesn't appear to do anything - as you say iunlink produces the result I was after. thanks for the explanation 1138843947 M * Bertl weasel: a) use some firewall rules and do the accounting there 1138843963 M * Bertl weasel: b) use some iptable accounting rules to get specific details 1138843982 M * Bertl weasel: c) just use the socket accounting done for the guest (willr eflect payload) 1138843986 M * weasel oh, I'm not talking about accounting at all :) 1138844006 M * Bertl weasel: ah, okay, misinterpreted that then ... 1138844014 M * Bertl weasel: so what are you talking about? 1138844017 M * weasel I care about things like which iptables chain do packets flow when they come out of the vserver going to .) the host, .) remote systems 1138844029 Q * Aiken Ping timeout: 480 seconds 1138844059 M * weasel or, how do I hook a vserver up so that more or less its entire IP traffic goes into a tun device on the host (say, for use with openvpn) 1138844063 M * Bertl anonc: yes, since we (almost) left the legacy stuff behind, the iunlink flag doesn't show up in lsattr, just the immutable one does 1138844075 M * weasel or, how do I get different vhosts on different vlans 1138844087 M * weasel or, can I use dummy devices if I only want host <-> vserver communications. 1138844090 M * weasel those kinds of things :) 1138844096 M * Bertl weasel: the same way you do that with any application _on the host_ i.e. usually routing 1138844121 J * corpse_girl JavaUser@85.98.2.254 1138844140 M * weasel Bertl: so all ip packets between host and vservers come and go via the lo interface? 1138844142 M * Bertl welcome corpse_girl! 1138844160 M * Bertl weasel: between host and guests yes, as they are local 1138844170 M * weasel great. that's one question answered already :) 1138844212 M * weasel is there any nice page discussing those things? I didn't see anything immediately obvious on the documentation page of the wiki 1138844275 M * Bertl well, probably there should be, but now that you mention it, I cannot remeber that I've seen something like that 1138844293 M * weasel too bad 1138844340 M * Bertl but you can take any linux networking page/howto for that 1138844344 M * Doener weasel: basically the answer is: forget the vserver, act as if all your networking stuff were just on the host, and vserver<->host/vserver is like host<->host, i.e local. 1138844373 M * weasel Doener: that's not entirely correct however. 1138844384 M * Bertl hmm? 1138844400 M * weasel accessing 127.0.0.1 from the guest does act differently than accessing 127.0.0.1 from the host itself 1138844420 M * Bertl yes, there are two exceptions to the networking for guests 1138844425 M * Doener ok, yeah, that's the famous exception 1138844434 M * weasel :) 1138844435 M * Bertl 1) the 0.0.0.0 bind is handled special 1138844451 M * Bertl 2) the 'local' ip 127.0.0.1 is rewritten 1138844475 M * weasel only 127.0.0.1, or all of 127.0.0.0/8? 1138844483 M * Doener only 127.0.0.1 1138844488 M * Bertl yep 1138844492 Q * corpse_girl Quit: Radio.Wazee forever! 1138844551 M * weasel no. 1138844595 M * weasel hm 1138844638 M * Bertl http://www.13thfloor.at/vserver/d_rel26/v2.1.0/split-2.6.14.4-vs2.1.0/09_2.6.14.4_net.diff.hl 1138844666 M * Bertl if (fl.fl4_dst == IPI_LOOPBACK && !vx_check(0, VX_ADMIN)) 1138844674 M * weasel 02:44:23.594991 IP 141.201.27.154.51071 > 127.4.0.1.25: S 1718151461:1718151461(0) win 32767 1138844677 M * Bertl fl.fl4_dst = nx_info->ipv4[0]; 1138844686 M * weasel 127.4.0.1 is rewritten too, for instance :) 1138844701 M * Bertl not by the vserver code :) 1138844720 M * weasel I guess it's a case of the ANY bind being treated special 1138844743 M * Bertl could be anything, I'd suspect simple routing decisions 1138844798 M * Bertl but I already thought about having a kernel option to enable this rewriting 1138844812 M * Bertl (or better to disable it if not wanted) 1138844835 M * weasel well, when doing 'telnet 127.0.0.2 25' on the host, you get both, target and destination ip of the connection to be 127.0.0.2. do it from a guest and the source gets rewritten to the guest's assigned ip 1138844876 M * Bertl because the guest binds to 0.0.0.0 leaving the decision to the stack, which chooses among the available ips 1138844897 M * Bertl assign 127.0.0.2 to the guest, preferable as first ip, and it will leave it as is 1138844921 M * weasel hmm. ic. 1138844947 M * weasel binding to 127.0.0.1 is explicitly allowed and rewritten, everything else is not allowed, unless explicitly whitelisted. 1138844968 M * weasel so binding to any other address from 127.0.0.0/8, which usually works on any box doesn't within a guest by default 1138845014 M * Bertl yes 1138845056 M * weasel what's the suggested method to use if I want my guests only be able to talk to the host? 1138845075 M * Bertl just add a simple blocking iptable rule 1138845084 M * weasel ok 1138845109 M * Bertl something like: -s guest-net/mask -d ! host -j DROP 1138845137 M * Bertl and of course, the counterpart for incoming 1138845143 M * weasel obviously 1138845736 M * Bertl glad we sorted that out :) 1138846380 M * Skram Bertl: if I gave each new user a 10.X.X.X address, as like interface 9 (so it wouldnt interfere with extra ip's, etc. they would be able to send files that way, and not have it routed via the outside... right? 1138846394 M * Skram the outside meaning a LAN. 1138846398 M * Skram I mean WAN ;) 1138846410 M * Bertl what's interface 9 ? 1138846414 M * Skram welp 1138846426 M * Skram same as adding an interface for a vps 1138846463 M * Skram so like i give users a /etc/vserver/NAME/interfaces/9/ip "10.X.X.X" this would make a local network so they can send files to eachother, and not have to go out and use external bandwidth. 1138846468 M * Skram would that work? 1138846499 M * Bertl yes, you might consider doing a few things though 1138846510 M * Skram explain more or no? 1138846511 M * Bertl first, assign that ip to the dummy device 1138846533 M * Bertl (which will keep traffic from 'coming in' 1138846540 M * Skram hrmm 1138846561 M * Bertl then, I'd suggest to add a simple rule to avoid sending packets via your real interfaces 1138846574 M * Skram hrmm okay 1138846581 M * Bertl except for that, the guests will be able to reach eachother via lo 1138846591 M * Bertl (by using the 10.x.x.x ips) 1138846602 M * Skram Right 1138846603 M * Bertl so, no outbound traffic for that 1138846623 M * Skram I was thinking about making internal traffic "free" so users can share files if need be, but most users dont know eachother. 1138846626 M * Skram Just curious. 1138846627 M * Skram Right 1138846646 M * Bertl yeah, will work 1138846663 M * Bertl makes sense if you provide a repository mirror or so ... 1138846681 M * Skram Welp, Right 1138846689 M * Skram We have everyone sharing portage, but that is different 1138846690 M * Skram Okay, Thanks 1138846708 M * Bertl np, you're welcome! 1138847421 M * Bertl weasel: btw, how is the irc stuff going @ oftc :) 1138847549 M * weasel same as last year :) 1138847561 M * weasel not much has changed. 1138847585 M * weasel we've hit 3k users sometime during the last few months so 1138849217 M * weasel gute nacht 1138849223 M * Bertl good night! 1138849869 J * D7 ~kevin@blk-222-149-104.eastlink.ca 1138849968 M * Bertl welcome D7! 1138853979 Q * Johnnie Quit: G'bye! 1138854034 J * marl_ ~matt@84.92.193.226 1138854047 J * Johnnie ~jdlewis@dynamic-acs-24-154-53-16.zoominternet.net 1138854479 Q * marl Ping timeout: 480 seconds 1138855811 N * ebiederm_oO ebiederm 1138855870 M * ebiederm Bertl: You were saying something to me yesterday... 1138855894 M * Bertl ebiederm: could be, could be ... 1138855902 M * Bertl ebiederm: any idea what it was? 1138855926 M * ebiederm Something about one of my emails and sarcasm if I remember correctly. 1138855953 M * Bertl ah, yeah ... I was 'amused' by your kinda sarcastic reply regarding kref ... 1138855983 M * Bertl the one which went like this: "we have a blue elephant in the kernel, why don't you use it?" 1138856010 M * Bertl "because I do not need it!" "but the abstraction is much better there!" 1138856042 A * ebiederm *laughs* 1138856089 M * ebiederm On the kref front I need to figure out how to benchmark it. If I can notice a difference I need to just kill that idea. 1138856166 M * ebiederm Did you see the that Linus chimed in on the PID virtualization thread. 1138856169 M * Bertl the thing is, nobody knows how the blue elephant got into the kernel, and why it is currently blue ... 1138856201 M * Bertl ad linus, not yet, just reading up on my 'normal' email 1138856234 M * ebiederm Short summary Linus said do the virtualization in the kernel. 1138856243 M * Bertl excellent! 1138856274 M * Bertl so we now can work on figuring out the interfaces and APIs? 1138856291 M * ebiederm Pretty much. 1138856310 M * Bertl okidokili, you have the most recent version somewhere as tar or so? 1138856323 M * Bertl (patches, not the kernel tree :) 1138856349 M * ebiederm Most recent version of PID virtualization? 1138856355 M * Bertl yep 1138856373 J * marl__ ~matt@84.92.193.226 1138856379 M * Bertl ebiederm: or was that 'virtualization' comment a general one? 1138856425 M * ebiederm Bertl: The slightly longer summary was if you are going to do it do it in the kernel as 1138856443 M * ebiederm He was pretty positive about vserver. 1138856455 M * Bertl good to hear ... 1138856513 M * ebiederm The last two days have been fairly hectic for me. First we had a last minute company meeting, and then I had to help a coworker implement cache as ram. 1138856540 J * marl ~matt@84.92.193.226 1138856547 M * ebiederm So except following a little bit of news I haven't done a lot. 1138856577 M * ebiederm That plus I have been coordinating with my brother as he is going to be in town next week visting me, and some of his frieds. 1138856584 M * ebiederm s/frieds/friends/ 1138856588 M * mugwump ebiederm: got a link to the thread? 1138856614 M * ebiederm Nope. Look for PID virtualization. 1138856614 M * Bertl ebiederm: np, is the tar of patches (against 2.6.16-rc1 I assume) an option? 1138856636 M * Bertl Message-ID: 1138856651 M * Bertl Re: RFC [patch 13/34] PID Virtualization Define new task_pid api 1138856659 M * ebiederm Bertl: I will aim at that tommorrow. 1138856700 M * ebiederm The other big news today for me was hearing about Van Jacobson net channels. 1138856723 M * mugwump yeah, his talk at Linux.conf.au went down well :) 1138856726 M * ebiederm Zero copy to user space using the with existing network cards. 1138856744 Q * marl_ Ping timeout: 480 seconds 1138856777 M * Bertl ebiederm: seems linus favours a syscall for container creation/manipulation? 1138856786 M * ebiederm Now if I can convince the vendors of high bandwidth/low latency interconnect cards that retransmission belongs in the user space. 1138856814 M * mugwump Bertl: he asked for a patch just for that feature ... the first few steps on that patch plan, I guess 1138856821 M * ebiederm Bertl: Perhaps. Linus is just engaging at a technical level. No mandates have come down. 1138856855 Q * marl__ Ping timeout: 480 seconds 1138857015 M * mugwump http://www.uwsg.iu.edu/hypermail/linux/kernel/0601.2/0490.html # guh 1138857195 J * marl_ ~matt@84.92.193.226 1138857207 Q * marl Read error: Connection reset by peer 1138857223 M * mugwump Slides from Van Jacobsen's talk at http://utsl.gen.nz/Van_jaclca06vj.pdf temporarily (will be on the LCA site eventually) 1138857652 M * mugwump Bertl: hmm, what's nid about? 1138857688 M * mugwump ah, net virtualisation 1138857779 Q * Johnnie Quit: G'bye! 1138857847 J * Johnnie ~jdlewis@dynamic-acs-24-154-53-16.zoominternet.net 1138857877 Q * Johnnie Quit: 1138858214 M * Bertl mugwump: isolation 1138858224 M * mugwump er, yes. I meant that ;) 1138858248 J * marl ~matt@84.92.193.226 1138858310 Q * marl_ Read error: Connection reset by peer 1138858711 P * D7 1138859223 M * Bertl k, I'm off to bed now ... back tomorrow ... 1138859241 M * Bertl have a good whatever everyone ... cya 1138859245 M * ebiederm Have a good night. 1138859246 N * Bertl Bertl_zZ 1138859246 A * mugwump waves 1138859256 N * ebiederm ebiedem_zZ 1138863925 Q * phych0 Read error: Connection reset by peer 1138867946 J * Ali ~coony@203-206-124-207.dyn.iinet.net.au 1138868015 P * Ali 1138868016 J * meandtheshell ~markus@85-125-228-199.dynamic.xdsl-line.inode.at 1138869806 Q * shedi Quit: Leaving 1138872663 J * prae ~prae@ezoffice.mandriva.com 1138874331 J * Smutje_ ~Smutje@xdsl-87-78-4-192.netcologne.de 1138874459 Q * Smutje Ping timeout: 480 seconds 1138874459 N * Smutje_ Smutje 1138876543 N * Bertl_zZ Bertl 1138876546 M * Bertl morning folks! 1138876594 M * Doener morning Bertl 1138876609 M * virtuoso morning guys 1138877177 J * tudenbart ~willi@xdsl-81-173-231-20.netcologne.de 1138877584 Q * dothebart Ping timeout: 480 seconds 1138879077 M * anonc 3 hours sleep bertl? 1138879129 M * Bertl well, a little more, but still not much :/ 1138879234 Q * Aiken_ Ping timeout: 480 seconds 1138879292 M * anonc hmm - don't you go burning out on us. Anyway - back to COW :) is the iunlink attribute on a file with a COW enabled kernel actually the same attribute as the normal immutable flag (in ext3 for example) 1138879341 M * Bertl no, it is a combination of two flags, plus the fact that it is a real file 1138879368 M * Bertl ah, and it has to be a hardlinked file with at least two references 1138879403 M * Bertl nevertheless the code is generic enough that you can replace that criterion by any other test 1138879411 J * shedi ~siggi@tolvudeild-196.lhi.is 1138879428 M * anonc right - so it doesn't affect ones ability to create normal immutable hardlinks when running on a COW kernel. nice. 1138879446 M * Bertl +#define IS_COW_LINK(inode) (S_ISREG((inode)->i_mode) && \ 1138879446 M * Bertl + ((inode)->i_nlink > 1) && IS_IUNLINK(inode)) 1138879452 M * Bertl (current check) 1138879456 M * anonc yup 1138880602 J * Dr4g Dr4g@82-40-43-86.cable.ubr06.uddi.blueyonder.co.uk 1138880703 M * Bertl welcome Dr4g! 1138882854 M * Dr4g wELCOME 1138882858 M * Dr4g oops. 1138882862 M * Dr4g Thanks* 1138882864 M * Dr4g you a bot ? 1138882869 M * Bertl sure I am :) 1138882900 M * Dr4g you a bot ? 1138882903 M * Dr4g guess not :) 1138882911 M * Bertl do you have something against bots? 1138882923 M * Dr4g no, i just didnt want to waste my time chatting to AI 1138882950 A * Bertl is trying to pass the turing test! 1138883086 J * lilalinux ~plasma@80.69.35.186 1138883092 M * Bertl welcome lilalinux! 1138883296 M * Bertl Dr4g: so, what did bring you here? 1138883407 M * Dr4g umm a whois for me here :) 1138883614 M * Bertl aha ... 1138883663 M * Dr4g for = got* 1138883669 M * Dr4g whats this channel about 1138883719 M * Bertl it's about linux virtualization, more precisely the Linux-VServer community project 1138883771 M * Bertl you've probably heard about Xen (or at least VMware), consider this, just much more resource efficiant, because specialized on linux and the linux kernel 1138883861 M * Skram Mornin' all. 1138883892 M * Bertl morning Skram! 1138883912 M * Skram School Starts in ~1.5hours :( 1138883965 M * Bertl that's good news, isn't it? 1138883988 M * Bertl Skram: you can never learn enough, trust me! 1138884003 M * Skram Meh, I have a lot of tests today, but yeah, I agree 1138884013 M * Skram Welp, I am out, just dropped by to wave and smile. 1138884014 M * Skram Tootles 1138884135 M * Bertl Skram: k, have fun! 1138884267 M * Skram Thanks 1138884646 M * Dr4g Bertl, i have VMWare installed atm 1138884648 M * Dr4g sounds cool 1138884668 M * Dr4g what are the more specific advantages of vsercer, than vmware 1138884716 M * Bertl when you use an emulator (as vmware) or a virtual machine (like with xen), you have a separate kernel running for each instance 1138884741 M * Bertl any access to filesystems, devices, etc happens indirectly via some mapper, emulation or hypervisor 1138884782 M * Bertl the Linux-VServer approach moves that virtualization right below the kernel, and does isolation wherever possible 1138884799 M * Bertl the advantages are basically: 1138884821 M * Bertl - you can share resources (like caches and such) between guests 1138884835 M * Bertl - you can dynamically change the resource usage any time 1138884854 M * Bertl - you do not have the overhead of an _additional_ kernel 1138884884 M * Bertl which in turn means that you can put a lot more 'virtual' guests on a real machine 1138885371 M * Dr4g sounds kewl 1138885374 M * Dr4g i just may check it out :) 1138885478 M * Bertl Dr4g: make that :) 1138885965 Q * shedi Quit: Leaving 1138885986 M * Dr4g :) 1138886118 Q * lilalinux Remote host closed the connection 1138886298 J * lilalinux ~plasma@80.69.35.186 1138887366 Q * jeeves Quit: Leaving 1138887779 Q * jgommers Remote host closed the connection 1138888324 Q * marl Ping timeout: 480 seconds 1138888626 J * marl ~matt@84.92.193.226 1138888635 Q * Doener Ping timeout: 480 seconds 1138888676 J * Doener doener@i5387E45D.versanet.de 1138889940 J * Viper0482 ~Viper0482@p54974E96.dip.t-dialin.net 1138890004 M * Bertl welcome Viper0482! 1138890034 M * micah morning/afternoon/evening Bertl 1138890049 M * Bertl hey micah! what's up? 1138890074 M * micah Bertl: staying cold in NJ! 1138890107 M * Bertl well, the sun is shining here ... 1138890154 M * micah work has been keeping me too busy, so I'm a little behind 1138890209 M * micah I just was putting together a new package for debian experimental with the 2.1.0.5 patch for 2.6.15, no 2.6.16 ready in debian 1138890303 M * micah Bertl: can I bug you to update http://linux-vserver.org/ChangeLogExperimental before it is too late? ;) 1138890366 A * micah goes to update util-vserver to latest release 1138890424 M * Bertl well, somebody did break that out of devel, and he said he will maintain/document it ... 1138890480 M * Bertl the question is, what version do you want me to put there? 1138890529 M * micah I wish I could help you maintain it, but you saw the last time I tried to guess the meaning of the deltas... ;) 1138890560 M * micah if it would help I can put some of the skeleton there, and you can fill it in 1138890569 M * Bertl well, you are using 2.1.0.5.1 I'd suggest 1138890587 M * Bertl so the changes to 2.1.0.4 should be minimal 1138890589 M * micah well, i am putting up 2.1.0.5 as it is the latest for 2.6.15, but I see that 2.1.0.9 is there for 2.6.16 1138890605 M * micah I'll have a stab at the 2.1.0.5 changes 1138890606 M * Bertl ahem, no please :) 1138890619 M * Bertl the 2.1.0.5 is broken, see ML 1138890659 M * micah ah! I was going to catch up on that after i did this package, thats a bad idea then :) 1138890922 M * micah nevertheless, putting up the changelog is useful 1138891330 M * micah hmm, I only see a delta directory for del-2.6.16-rc1-vs2.1.0.9 1138891364 J * tachauch ~m@dsl48-10.pool.bitel.net 1138891394 M * Bertl welcome tachauch! 1138891404 M * tachauch Hi Bertl 1138891439 M * Bertl micah: http://vserver.13thfloor.at/Experimental/patch-2.6.15.1-vs2.1.0.5.1.diff 1138891597 M * tachauch My vserver starts up with a wrong netmask (255.255.255.128) even with correct netmask (255.255.255.0) in /etc/vservers/zapp/interfaces/0/mask .... how can this happen? 1138891616 M * tachauch what influences the netmask? 1138891623 M * Bertl does it write some 'complaints' when started up? 1138891647 M * Bertl (something like NETLINK blabla ...) 1138891647 M * tachauch nope 1138891666 M * Bertl what version of patches/tools do you use? 1138891669 M * tachauch gets up without problems ... 1138891687 M * tachauch 2.6.14.3-vs2.0.1 1138891718 M * Bertl and the utilities? 1138891728 M * tachauch 0.30.209-r1 1138891740 M * Bertl hmm, distro? 1138891752 M * tachauch ahh ... there is a 0.30.210-r1 available ....in gentoo 1138891773 M * Bertl do you have an entry called 'prefix' in your /etc/vservers/zapp/interfaces/0 ? 1138891819 M * tachauch yes ..... content is "25" .... don't ask me why ... ;) 1138891865 M * Bertl well, that's the 'netmask' :) 1138891881 M * tachauch Ooops .... :) 1138891882 M * Bertl i.e. either put 24 there, or remove it completely 1138891915 M * tachauch ok ..... I'll try 1138891937 M * Bertl okay, have to leave now .. to get some groceries ... back later ... 1138891937 N * Bertl Bertl_oO 1138891951 M * Bertl_oO tachauch: ah, btw, stop the guest first, then change it :) 1138891972 M * tachauch :) 1138891977 J * marl_ ~matt@84.92.193.226 1138891993 M * tachauch okidoki .... that worked .... thanks a lot!!!!!! :) 1138892415 Q * marl Ping timeout: 480 seconds 1138892570 M * micah Bertl_oO: patch-2.6.15.1-vs2.1.0.5.1.diff looks like it is the fix for the page fault array being off by one for the 2.6.15 vs2.1.0.5.1, cool! 1138892584 J * Milf ~Miranda@ipsio300.ipsi.fraunhofer.de 1138894212 J * liquid3649_ ~Viper0482@p54975D4C.dip.t-dialin.net 1138894471 P * tachauch 1138894650 Q * Viper0482 Ping timeout: 480 seconds 1138895333 Q * liquid3649_ Quit: bin raus, 1138895681 M * micah Bertl_oO: I looked at the differences between 2.1.0.4 and 2.1.0.5 and put what i could find at http://linux-vserver.org/ChangeLogExperimental 1138895693 M * micah Bertl_oO: there are some items I did not understand, please have a look when you can 1138895745 M * daniel_hozac i think the page fault stuff is for the soft limits. 1138897242 J * shedi ~siggi@inferno.lhi.is 1138897633 Q * prae Quit: Execute Order 69 ! 1138898154 J * Snow-Man ~sfrost@kenobi.snowman.net 1138898164 M * Snow-Man hey ya 1138898176 M * Snow-Man I have got to ask- what's the scoop with the stuff that's being posted to lkml? 1138898185 M * Snow-Man Is that vserver stuff or some other competeing thing? 1138898604 N * Bertl_oO Bertl 1138898610 M * Bertl back now ... 1138898628 M * Bertl micah: great! will check and if necessary update it 1138898653 M * Bertl Snow-Man: hmm, well, url? 1138898760 M * Snow-Man Bertl: hrmmm, lemme see if I can dig one up. 1138899123 M * Snow-Man http://www.ussg.iu.edu/hypermail/linux/kernel/0602.0/0648.html 1138899144 M * Snow-Man I guess it's the OpenVZ stuff, but I got the impression that OpenVZ sucked compared to VServers... :) 1138899161 M * Snow-Man Anyway, someone seems to be trying to get Linus to accepted the OpenVZ stuff into the mainline kernel. 1138899172 M * Bertl well, of course they are _trying_ 1138899185 M * Snow-Man haha 1138899191 M * Snow-Man Has it been officially shot down or something? 1138899207 M * Bertl after all, they spent a lot of money to save Virtuozzo and outsource kernel development 1138899207 M * Snow-Man I'm just trying to catch up and understand what's going on. :) 1138899260 A * Snow-Man smirks. 1138899319 M * Bertl well, let me put it this way, if the virtuozzo code makes it into the kernel, the vserver patches will get larger :) 1138899323 M * dhansen Bertl: I'm not sure Kirill read the entire discussion 1138899340 M * Bertl dhansen: I'm pretty sure he didn't 1138899378 M * Bertl Snow-Man: IMHO ebiedem is on the right way, something like that will be really useful 1138899390 M * Bertl dhansen: what's your opinion? 1138899469 M * dhansen Bertl: Eric's stuff is interesting, but it still seems a bit over-complex to me. 1138899479 M * dhansen But, I think _everything_ is too complex until I understand it compeltely :) 1138899500 M * Bertl hehe, well, what I think is _very_ important for pid virtualization is to 1138899519 M * Bertl make _all_ kernel intern and extern references independant from the 'context' 1138899544 M * Bertl i.e. make the in-kernel references _absolute_ and the userspace references _relative_ 1138899584 M * dhansen by default, yes. But, userspace obviously needs a few absolute interfaces, at least for control, right? 1138899588 M * Bertl IMHO this is the only way to allow for context migration and snapshoting in a sane way 1138899613 M * Bertl dhansen: well, yes, that's the part which is missing in eric's approach (for now) 1138899630 M * dhansen Bertl: I really like the mm_struct comparision. Memory is the same way. Userspace gets a different view than the kernel does. The kernel has to understand both views. 1138899660 M * Bertl dhansen: but OTOH, even if those interfaces do not get in now, you can add them later, and linux-vserver for example will do so (almost immediately) 1138899708 M * dhansen yeah, the interfaces can come later 1138899726 M * Bertl dhansen: whether the creation runs via proc tricks or clone flags is not really relevant (although I prefer latter), as long as the structures are tied to the tasks 1138899759 M * dhansen Amen. I could care less about interfaces, as long as they work. 1138899760 M * Bertl this and the fact that they are refcounted ensures that you can move between them 1138899795 M * Bertl the vx_info (context structure) in linux-vserver could just make a 'copy' like it does for namespaces now 1138899803 M * dhansen Bertl: the tasks that move between containers are a major pain for checkpointing, but I think they're basically required for nice administration interfaces 1138899820 M * Bertl hold the reference, and whenever you want to 'join' the pidspace, just copy, voila 1138899859 M * Bertl dhansen: well, entering and leaving *-spaces is always a pita for snapshoting and/or migration 1138899879 Q * cehteh Quit: Client exiting 1138899882 M * dhansen I _think_ we can just complain and not snapshot if one of those processes is hanging around 1138899892 M * Bertl dhansen: but, and here is the linux point 'enough rope and so' you do not have to do that 1138899896 M * dhansen say, "if you want to snapshot, make that guy go away." 1138899949 M * Bertl i.e. it's pretty easy to say "snapshot not possible, do something" :) 1138899959 M * dhansen yup, agreed 1138899966 J * stefani ~stefani@superquan.apl.washington.edu 1138899981 N * ebiedem_zZ ebiederm 1138900003 M * Bertl dhansen: after all, snapshoting and task/context migration are not for the 0815 admin who gives linux a try ... 1138900009 M * Bertl good morning ebiederm! 1138900017 M * ebiederm Moring Bertl. 1138900047 M * ebiederm Looks like there is an interesting conversation going on here. 1138900050 M * Bertl anyway, the OVZ pid approach is the poor man's hack to virtual pids ... 1138900062 Q * Milf Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org 1138900082 M * Bertl doesn't solve any issues, doesn't allow sane migration and/or references, well, it 'just' looks nice ... 1138900098 M * ebiederm Interesting tidbid on the netchannel thread. 1138900131 M * ebiederm netchannels based upon make for virtualization/isolation has been suggested and seems to fit the model very well. 1138900157 M * Bertl ebiederm: do have a quick url at hand? 1138900213 M * ebiederm On the netdev list the subject is Van Jacobsen net channels. 1138900224 M * ebiederm So far the discussion is pretty high level. 1138900233 M * ebiederm And it only came up in passing. 1138900305 M * ebiederm Basically the idea with netchannels is you have a smarter classifier than eth_trans_type run in the network driver. 1138900350 M * dhansen http://lwn.net/Articles/169269/ 1138900356 M * dhansen if you have an LWN subscription 1138900376 M * Bertl I found the slides ... 1138900520 M * ebiederm Bertl: Sorry I thought you had picked that part up in the conversation last night. 1138900539 M * Bertl only partially ... 1138900562 M * Bertl ebiederm: and it seems you are still not able to send to the ML? 1138900618 M * ebiederm dhansen: As for my code being over complicated there is a reason I haven't asked for inclusion just yet :) 1138900645 M * ebiederm Bertl: I just haven't gotten back to figuring out what is going on there. 1138900673 M * dhansen ebiederm: Don't get me wrong, I think it's good stuff. As you know, it just needs some more churn. 1138900698 M * ebiederm And I had a high priority task come in the last two days. So I haven't been able to follow up on that. 1138900743 M * ebiederm I can post to the list just not when I CC 10 people, as may seem sane since there are 4 distinct development efforts trying to get vserver type functionality into the kernel. 1138900744 M * Bertl dhansen, ebiederm: so what about working a little on those patches? 1138900754 M * dhansen ebiederm: What are you working on these days? Some people at IBM were curious and I had no idea! :) 1138900788 M * dhansen ebiederm: I give you permission to cc me whenever you want. Don't worry 'bout me :) 1138900823 M * ebiederm dhansen: Getting this stuff into the kernel is my primary project right now. 1138900830 M * dhansen Bertl: I've definitely got some time in the next week or so. 1138900848 M * dhansen ebiederm: can you send me your latest, and I'll make a run over them? 1138900852 M * Bertl dhansen, ebiederm: what about spending a few hours right now? 1138900879 M * ebiederm Sounds good to me. 1138900895 M * Bertl I guess, although the patch/code is more detailed, the involved parties might get a better understand by just talking about it? 1138900895 M * ebiederm dhansen: What was the last thing you saw and what part had you confused. 1138900899 M * dhansen I've got probably an hour or so 1138900914 M * Bertl dhansen: then let's make good use of it 1138900935 M * dhansen ebiederm: I honestly don't remember. I'm feeling more receptive now :) 1138900950 M * Bertl have a short chat right now, and I'll extract eric's patches from lkml and put it somewhere to look at 1138900963 M * ebiederm Bertl: Thanks. 1138901001 M * ebiederm dhansen: Can I ask quickly how IBM is organizing to work on this problem? 1138901031 M * dhansen ebiederm: as in, what kind of resources are on it? 1138901045 M * ebiederm dhansen: Yes 1138901073 M * dhansen the number of overall people hasn't changed, but we probably have more of a reason to focus directly on it now 1138901140 M * ebiederm dhansen: I guess I don't know what the starting point was. Is there a project people are actually working on? Or is this something people are working on as they have time and interestest? 1138901206 M * ebiederm Mostly I am interested so I can understand what I need to do to coordinate. 1138901208 M * dhansen ebiederm: google for "ibm meiosys" and see what you come up with 1138901221 M * dhansen IBM bought a company that was doing checkpoint/restart on Linux 1138901243 M * dhansen The current product has _zero_ chance of getting mainline merged 1138901256 M * dhansen Our goal is to get the same functionality in mainline 1138901366 M * ebiederm Ok. meisys I am vaugley familiar with. 1138901445 M * ebiederm I stopped paying attention when I realized how small a chance of getting into mainline or even of being ported to 2.6 in a timely manner it had. 1138901466 M * ebiederm So on to the practical stuff. 1138901471 M * dhansen ebiederm: you've seen the code before? 1138901534 M * ebiederm dhansen: I have heard the code discussed/marketed and managed to infer a lot. 1138901583 M * dhansen ebiederm: so, you understand why we haven't posted the original code? ;) 1138901596 M * Bertl http://www.13thfloor.at/VPID/ebiederm-20060129/ 1138901634 M * ebiederm dhansen: I understand why you haven't asked for inclusion with it anyway. 1138901661 M * dhansen does the term "community reputation suicide" mean anything? :) 1138901670 M * Bertl has anybody looked at the zap/pod stuff from columbia? 1138901698 M * ebiederm What I have been working just the last little bit are cleaning up the code so pid virtualization could go in cleanly. 1138901730 M * ebiederm I haven't been able to track down the zap/pod stuff but I read about it. Everything was isolated in their module. 1138901744 M * ebiederm dhansen: IB seemed to survive it :) 1138901758 M * Bertl thing is, I had a longer talk with those folks (when I was in princeton) 1138901798 M * Bertl and they are not really fond of the 'module' approach they used, but you know, folks outside the kernel want to do everything in modules :) 1138901842 M * dhansen Bertl: Hubertus and Cedric have looked at it. 1138901908 M * Bertl and? 1138901960 M * dhansen digging in email... 1138902039 M * dhansen Not my words, but basically that zap is a research project, and there isn't much emphasis on getting it productized or merged into mainline 1138902069 M * dhansen but, "they mastered the low end OS issues" 1138902134 M * Bertl yes, well, it seemed to work quite fine ... 1138902160 M * dhansen Bertl: so does Meiosys's Metacluster. However, it is light-years from getting into a mainline kernel :( 1138902195 M * Bertl I think it might be interesting to talk with those folks if 'guest' migration is something which IMB wants to have/do no? 1138902198 M * dhansen Bertl: did you get those patches posted somewhere? 1138902215 M * dhansen Sure. Nothing wrong with talking 1138902219 M * Bertl the zap/pod stuff? 1138902249 M * Bertl ebiederm: do you remember when you started your pid patch series? 1138902270 M * dhansen Using existing projects to define the problems, and a couple possible solutions is "a good thing". However, it is going to be hard to just port them, or use much verbatim code. 1138902321 M * Bertl dhansen: I'm not talking about existing code or projects, I'm talking about the experience with those things and the many gotchas one could avoid ... 1138902364 M * dhansen The experience of those who have travelled a similar road in the past will be invaluable 1138902436 M * Bertl that's what I mean ... I think I could implement context migration in a few months, but I'll probably stumle many times on my way ... 1138902465 M * Bertl this could be avoided if all folks work together and share their experience ... 1138902469 M * ebiederm Bertl: Sometime in October. 1138902501 M * dhansen Bertl: In addition to the Zap people, the ex-Meiosys people know that stuff pretty well, too 1138902509 M * dhansen That's basically anyone with a fr.ibm.com address :) 1138902541 M * Bertl dhansen: excellent, send them here :) well or at least let them talk with folks working on such things :) 1138902596 J * sneage ~naftizin@82.199.96.65 1138902599 M * Bertl now regarding the vpid stuff, let's just for clarification review what issues everybody has/sees with _any_ approach there 1138902604 M * Bertl welcome sneage! 1138902635 M * ebiederm Bertl: Which martin were you telling to ask about list policy? 1138902649 P * sneage 1138902665 M * Bertl ebiederm: Martin List-Petersen 1138902694 M * ebiederm Ok. Where do I find his email addresss? Sorry I seem to be dense today. 1138902705 M * Bertl all virtualization projects (at least for isp and so) will require some admin backdoor to 1138902718 M * Bertl ebiederm: pm 1138902749 M * Bertl at least allow entering a context/guest/namespace 1138902765 M * Bertl dhansen, ebiederm: do we agree upon that? 1138902864 M * Bertl *silence fell upon the land* 1138902933 M * ebiederm Bertl: Yes I agree that is a current common feature and we need to find a way to meet that need. 1138902942 M * ebiederm Bertl: I also agree that it is easy. 1138902945 M * Bertl I have a few more features ... 1138902953 M * ebiederm Bertl: What the interface should look like I don't know. 1138902976 M * Bertl doesn't really matter, IMHO it does not even ahve to be implemented (right now) 1138902998 M * Bertl we just have to make damn sure that we do leave this option open 1138903033 M * ebiederm Bertl: It can't be any worse than the kernel starting /sbin/hotplug. 1138903033 M * Bertl okay, here are a few more nice-to-have features ... 1138903060 M * Bertl - communication across certain namespaces 1138903071 M * ebiederm ? 1138903079 M * Bertl - kind of 'reboot' for init processes 1138903102 M * Bertl - hierarchical namespaces with and without inheritance 1138903134 M * Bertl - 'v'kill within the hierarchy 1138903145 M * virtuoso Good old vserver gets overly bloated with *features*.. 1138903171 M * Bertl virtuoso: ah, good point, and of course, all this without any _noticeable_ overhead 1138903204 M * ebiederm Reboot for init processes is easy, just do the equivalent of respawn. 1138903249 M * ebiederm Communication accross namespaces, I'm not certain what you meant. But there is no reason you can't have unix domain sockets open between then if the init process sets it up. 1138903255 M * Bertl ad reboot: yes, the interesting detail here is getting rid of the container resources somehow 1138903300 M * Bertl ebiederm: what about pipes across contexts? 1138903316 M * ebiederm Bertl: pipes across contexts should be trivial. 1138903372 M * ebiederm Basically I see all of the kernel parts as features you can use to implemenent guests. Not features you can only use to implement guests. 1138903423 M * dhansen Bertl: yep, I agree with the backdoor 1138903431 M * Bertl ebiederm: well, although I couldn't parse your last sentence, I guess I know what you meant 1138903433 M * dhansen sorry, had to step away for a sec 1138903456 M * ebiederm If the namespace isn't shared init when it is setting up the guest has to create the file descriptors but otherwise I don't see a problem. 1138903486 M * Bertl okay, wb dhansen! 1138903528 M * Bertl so, on one hand we strive to make the isolation as good as possible, otoh we want to allow some kind of admin to work on that ... 1138903585 M * Bertl but I think we can apply a bunch of very simple rules to admin access within a namespace hierarchy ... 1138903605 M * Bertl ebiederm: btw, is the hierarchical aspect still valid? 1138903634 M * Bertl (or did you already give up on hierarchies and made it a simple flat model) 1138903657 M * Bertl note: I'm not talking about the implementation here 1138903703 M * ebiederm Bertl: Largely I like a flat model. But we need to be able to do waitpid for the init process of the guest from outside the guests pid namespace. 1138903730 M * ebiederm If we don't disallow guests from creating guests we get a 'hierarchical' model. 1138903746 M * ebiederm But mostly it should be a question of who has what priveleges. 1138903769 M * ebiederm dhansen: Does meiosys virtualize user ids? 1138903776 M * Bertl yeah, well, IMHO the important questions here are: 1138903805 M * Bertl - do we use something like CAPs, which are kind of boolean 1138903827 M * Bertl - how do we view the 'child' context(s) 1138903828 M * dhansen ebiederm: nop 1138903858 M * dhansen ebiederm: you have to share a fs between the checkpoint and restart place. So, you end up sharing /etc/passwd (the common case, of course) 1138903912 M * ebiederm Bertl: This is something we want as a separate clone flag, UID virtualization. vservers need it. Most checkpoint/restart types don't :) 1138903946 M * dhansen Bertl: you could view the child context by making it have an entire fs image in /container/1/ (view from the top container), and make sure that all the mounts get replicated back there. 1138903947 M * ebiederm dhansen: My goals are very similar to yours when it comes to target functionality. 1138903952 M * Bertl ebiederm: well, vservers can live with uid isolation 1138903981 M * ebiederm Bertl: What about without uid isolation? 1138904003 M * Bertl dhansen: you are talking about filesystem namespaces, I'm still with the pid spaces 1138904035 M * Bertl dhansen: the private namespaces already do what we want/need for the filesystem case 1138904074 M * dhansen - how do we view the 'child' context(s) 1138904074 M * Bertl ebiederm: not sure what you mean? 1138904084 M * dhansen we'll need some kind of 'fork_into()', right? 1138904114 M * Bertl dhansen: well, that depends, it is an option (probably a hacky one) 1138904126 A * ebiederm *ahhh* 1138904155 M * Bertl dhansen: I'd prefer to be able to 'observe' a guest from outside, i.e. know about the processes and process details without joining the context 1138904176 M * Bertl dhansen: not only for security reasons, but also for performance reasons 1138904187 M * ebiederm Bertl: I prefer to observe the guest from outside as well. 1138904220 M * Bertl so, basically regarding the pid stuff I see a bunch of options there: 1138904231 M * ebiederm Currently what I have implemented is /proc//pspace/ 1138904248 M * Bertl - allow userspace to see/access child-context pids somehow 1138904270 M * Bertl - have a special 'spectator' mode 1138904285 M * Bertl - have new interfaces/syscall to retrieve the data 1138904286 M * dhansen ebiederm: would it just be better to let the top container mount each container's /proc separately? 1138904303 M * dhansen instead of having to modify /proc to add the pspace stuff? 1138904354 M * Bertl a hierarchical procfs would solve most of those issues, I'd say 1138904380 M * dhansen mount -t proc -o container=99 proc /container-control/99/proc ?? 1138904383 M * Bertl i.e. have a proc root per guest 1138904412 M * Bertl dhansen: no, I was more thinking of something like the rootfs/mnt 1138904418 M * ebiederm dhansen: There are some modifications we need to proc, but I think having separate /proc instances for each guest makes the most sense. 1138904440 M * Bertl basically you start right above your init process 1138904456 M * ebiederm But I still think I want /proc//pspace/ as a default mount point. 1138904482 M * ebiederm Err provided so we have a default place to mount nested procs. 1138904482 M * Bertl ebiederm: separate proc instances really? 1138904500 M * Bertl ebiederm: sounds like unnecessary bloat to me 1138904518 M * ebiederm Bertl: I think with the latest fs namespace stuff I may be able to simply mount a namespace hierarchy. 1138904523 M * Bertl a ton of inodes and structures could be shared across the procs 1138904560 M * Bertl and the hierarchy stuff would come for free 1138904563 M * ebiederm Two piece capture my imagination. 1138904593 M * ebiederm 1) The interesting work on namespaces that has happened lately where you can share a subset of a fs namespace with someone else. 1138904612 M * ebiederm 2) Proc in reality is 2 filesystems /proc/ and the rest. 1138904619 M * Bertl ad 1) the propagation stuff? 1138904636 M * Bertl ad 2) yes I'd prefer to move the 'other' stuff out 1138904668 M * ebiederm So If mounting /proc was actually mounting a shared mount subtree it would work like today but work differently. 1138904686 M * ebiederm I'm not quite certain if that is doable. 1138904686 M * Bertl 'look' like today ... 1138904721 M * Bertl well, I'm not sure if that's worth the efford ... 1138904723 M * ebiederm Yes. 'look' like today. 1138904742 M * dhansen I've got to take off. I'll read the logs later. Thanks Bertl, ebiederm. Good stuff! 1138904743 M * Bertl maybe a slightly more complex, but in the end much simpler approach would be: 1138904751 M * Bertl dhansen: k, cya! 1138904751 P * dhansen 1138904765 M * ebiederm For isolation you need an isolated instance of /proc that only shows you what you need. 1138904770 M * Bertl - move the 'new' proc stuff out of proc 1138904794 M * Bertl - make a clean procfs (just call it differently for now) 1138904812 M * Bertl - make a 'view' in the existing proc 1138904841 M * Bertl i.e. simply hand-through requests to to the 'other' filesystem 1138904861 M * Bertl then officially deprecate the 'other' stuff, and move it somewhere else 1138904926 M * ebiederm Sounds like a plan. 1138904949 M * ebiederm If I can figure out how to make the 'view' work. 1138904960 M * Bertl should be easy .. because: 1138904979 M * Bertl the new proc (nproc for now) only requires a single sb 1138904993 M * Bertl the old proc just has a single sb 1138905037 M * ebiederm Bertl: I still get a different nproc superblock for each pspace. 1138905051 M * Bertl no, that's what I meant 1138905067 M * Bertl there is no need to have a different sb for each space 1138905085 M * Bertl you just add a new (sub)directory 1138905125 M * Bertl /nproc/100/{10,11,12} 1138905133 M * ebiederm Bertl: The case that invokes mount magic is mounting /proc when you are inside the guest. 1138905162 M * ebiederm Because the guest should not be able to see outside. 1138905166 M * Bertl that is trivial, as we 'simply' set the root to /nproc/100 1138905202 M * Bertl i.e doing a mount for nproc inside the guest will do nothing but create a new vfsmount for that 1138905241 M * ebiederm Bertl: I don't remember exactly but there was some reason I stopped doing that. 1138905270 M * ebiederm I think it was because I would have to change the vfs in ugly ways to allow mount to do that. 1138905290 M * ebiederm Anyway /proc is ugly be easy. 1138905298 M * Bertl hmm ... 1138905334 M * Bertl well, I guess we could also just 'virtualize' the root path in the lookup process 1138905364 M * Bertl similar to the currently done proc hiding ... 1138905389 M * ebiederm Bertl: You can't mess with the dcache and be sane, although I don't know what your implemenation looks like. 1138905420 M * ebiederm I would rather have multiple super blocks but a non dupped dcache than then a single super block and dcache issues. 1138905426 J * Viper0482 ~Viper0482@p54975D4C.dip.t-dialin.net 1138905463 M * ebiederm Compartively super blocks are cheap. Also with multiple super blocks I can preserve the legacy inode numbers. 1138905476 M * Bertl ebiederm: I have no problem with multiple superblocks (not at all) but how do you plan to make the 'child' contexts visible in the parent? 1138905496 J * dearaujo ~dan@pixpat.austin.ibm.com 1138905497 M * Bertl (especially across the hierarchy) 1138905506 M * Bertl welcome dearaujo! 1138905507 M * ebiederm Bertl: One of two ways. 1138905563 M * ebiederm - We allow mount -t proc -o context=100 /mnt (i.e. every one mounts a separate instance of /proc) 1138905576 M * ebiederm Of each proc. 1138905592 Q * Viper0482 Remote host closed the connection 1138905597 M * Bertl (doesn't solve the problem, IMHO) 1138905601 J * Viper0482 ~Viper0482@p54975D4C.dip.t-dialin.net 1138905615 M * ebiederm - We figure out how to mount a shared fs subtree and have the kernel do the mounts and the children just get a place in the child. 1138905640 M * Bertl s/child/tree/ 1138905645 M * dearaujo quick question: can I use the patch-2.6.14.3-vs2.01 on any 2.6.14.x kernel or is it specifically for 2.6.14.3? (I assume 2.6.14.x kernel will work) 1138905654 M * ebiederm Bertl: I agree if we have to do all of the /proc mounts manually it sucks. 1138905666 M * Bertl dearaujo: I'd assume so too ... 1138905680 M * dearaujo Bertl: great, thanks 1138905685 M * Bertl ebiederm: as a matter of fact, that would not even work 1138905692 M * Bertl ebiederm: simple scenario: 1138905710 M * Bertl guest '100' is created, you mount it's special subtree 1138905732 M * Bertl guest '100' creates guest '200', and again mounts it's subtree 1138905751 M * Bertl a) how did the main context get informed about that? 1138905764 M * Bertl b) what if the subcontext used id 100 too? 1138905860 M * ebiederm So we want to build the tree: /proc/100/pspace/200/pspace/ 1138905886 M * Bertl well, I'd skip the pspace, but yes, if you have to :) 1138905903 M * ebiederm So if we are using /proc mount options We have a -o context=100 and -o context=100/200. 1138905934 M * Bertl via hotplug, invoked in the proper context? 1138905941 M * ebiederm Bertl: There are other files in there and I need a directory all to my own. 1138905948 M * Bertl sounds a little far fetched 1138905965 M * ebiederm Bertl: I agree getting the kernel to do it in some manner is better the question is how do we do it cleanly. 1138905966 M * Bertl ebiederm: ad directory, hmm, why? 1138905996 M * Bertl IMHO the same rules apply as for proc now, you just have entries 1138906013 M * Bertl and there are no numbered entries in /proc// right now 1138906042 M * ebiederm Bertl: So in /proc/100/ there are files like stat status so that descripbe the whoe pspace. 1138906073 M * ebiederm Instead of describing just a task group. 1138906095 M * Bertl yes, if the 'parent' or space has/provides this info ... 1138906105 M * ebiederm I could call the subdirectory task instead of pspace but and the outside would think they were just threads :) 1138906142 M * ebiederm Bertl: I have currently implemented that, and it seems to work fairly well. 1138906199 M * Bertl so what's the problem then= 1138906202 M * Bertl s/=/? 1138906273 M * ebiederm Multi-threaded conversation appears to have just experienced a race. 1138906301 M * ebiederm I have currently implemented /proc/100/pspace/xxx and /proc/100/stat all of that seems to work. 1138906363 M * Bertl where /proc/100/stat is different from in and outside, yes? 1138906379 M * ebiederm The only reall issue with multiple subdirectories is that you don't preserve the legacy inodes and have to use something fairly random, and you mounts inside a context seem to need a different super block and thus a different dcache entry. 1138906384 M * Bertl (well, it's not inside right now) 1138906399 M * ebiederm Exactly. 1138906423 M * ebiederm The summary is only avaiable on the outside. 1138906428 M * Bertl legacy inodes means? 1138906451 M * ebiederm The current /proc inodes that are set by process id. 1138906492 M * Bertl well, inode numbers are currently 32 bit or more, right? 1138906510 M * ebiederm Inode numbers are currently just 32bit. 1138906527 M * Bertl well, I'd assume they are long no? 1138906545 M * Bertl but let's assume they are just 32bit 1138906564 M * Bertl the current number of bits for tasks is 16, right? 1138906576 M * ebiederm On a 32bit box. 1138906595 M * ebiederm I think it is 24 on a 64bit box. 1138906601 M * Bertl really? 1138906614 M * Bertl well, those should really have 64 bit inode numbers then 1138906620 M * ebiederm Bertl: Yes. 1138906637 M * Bertl so that's not an issue in this case ... 1138906638 M * ebiederm Bert: I think the inode numbers are longs and cope with the 64bit case. 1138906662 M * Bertl so we have at least 16 bits available if we get rid of the 'legacy' stuff 1138906691 M * ebiederm Ok. Be we still need an inode number for each file descriptor we have open. 1138906701 M * derjohn Bertl == Bert ? hehe :) 1138906790 M * ebiederm Getting rid of the legacy mapping though makes inode assignment easier. 1138906798 M * Bertl ebiederm: I'd say 8 or 10 bits should be more than enough on a 32bit system 1138906806 M * Bertl to assign to 'contexts' 1138906832 M * Bertl which would leave us with 64-256 different 'subentries' for each task 1138906858 M * Bertl the filedescriptors are indeed an issue, but 1138906871 M * Bertl I think they could be formed from a common pool 1138906895 M * Bertl i.e. just set aside a bit for filedescriptors 1138906903 M * Bertl and use the rest for identifying them 1138906926 M * ebiederm Bertl: Probably. But if we drop the legacy mapping just going to what is essentially random inode assignment works well. 1138906951 M * Bertl ebiederm: well, does that work good enough? 1138906964 M * ebiederm Bertl: That is a good question. 1138906975 M * Bertl I mean, you cannot check for duplicates in a performant manner 1138907032 M * ebiederm I think checking for duplicates is as easy a probing the inode cache. 1138907033 M * Bertl completely different question: is there anything which would stop us from having 64bit inode numbers on 32bit systems? 1138907077 M * ebiederm Probably only sys_stat() and efficiency concerns. 1138907136 M * ebiederm I wonder if I can get in a patch to /proc to use a more random inode allocator. 1138907150 M * Bertl well, the sys_stat() argument is very week, last guy who tried to 'efficiently' backup his procfs with tar or dump is already dead 1138907184 M * ebiederm Actually it is abou the only argument. 1138907198 M * Bertl so it's the efficiency aspect 1138907204 M * ebiederm I could very easily take my current implementation and always return inode == 1 and it would work. 1138907233 M * ebiederm But people do run find in /proc and that gets confused if you duplicate inode numbers. 1138907262 M * Bertl really? what do they expect to 'find' in proc? 1138907288 M * ebiederm Well at least I do. Just as way of looking through processes. 1138907312 M * ebiederm At lot of times I have used it to figure out which contexts I have. 1138907336 M * Bertl hmm, you should know how to teach find not to worry about that, but that sounds more like "I'l like to rm /proc/kcore, because it's soo big" to me :) 1138907339 M * ebiederm But that is the only real argument for having unique inode numbers and correct link counts in proc. 1138907375 M * Bertl anyway, I'm probably fine with (pseudo) random allocation 1138907380 J * vrwttnmtu ~eryktyktu@82-69-161-137.dsl.in-addr.zen.co.uk 1138907390 A * vrwttnmtu waits for Bertl's greeting... 1138907391 M * Bertl as long as it doesn't add overhead to proc 1138907402 M * Bertl hey vrwttnmtu! 1138907410 M * vrwttnmtu Hey Bertl :) 1138907456 M * Bertl ebiederm: IMHO the inode numbers could make sense though, but that's just me ... 1138907480 M * ebiederm Bertl: In what context could the inode numbers make sense? 1138907502 M * Bertl well, kind of encoding the pid/context 1138907528 M * ebiederm Bertl: Yes. If we were to extend the static allocation like that. 1138907580 M * ebiederm To a certain extent I have a preference for not making it obvious I'm in a guest. 1138907584 M * Bertl btw, would the /proc/pid/fd entries make sense for the guest contexts at all? 1138907627 M * Bertl i.e. what would /proc/100/[pspace/]200/fd/0 point to? 1138907627 Q * Viper0482 Read error: Connection reset by peer 1138907637 M * vrwttnmtu Bertl, Where does VServer stand with Multicasting, and joining the Mbone? One of my users wants to have his vserver "connected" to the mbone. Is it possible, do I do the connection on the host, or in his actual vserver? I've read that mcast reading is working, but writing (which is what he wants to do) is problematic. 1138907640 J * Viper0482 ~Viper0482@p54975D4C.dip.t-dialin.net 1138907695 M * Bertl vrwttnmtu: in theory (read nobody explicitely tested this AFAIK) the proper capabilities and assigning the MC addresses to the guest should allow you to send and receive 1138907707 M * vrwttnmtu If it makes a difference, he's a "trusted" user.... 1138907745 M * vrwttnmtu Wow! :) So I can hopefully just follow the instructions for connecting within his vserver, and it should all work? 1138907808 M * Bertl well, stay in touch, I guess you _will_ encounter issues and/or setup questions 1138907818 M * vrwttnmtu :) Indeed :) 1138907846 M * vrwttnmtu In the IRC logs, you said: "sending multicast requires NET_ADMIN (which you do not want to give atm)" Is that still the case? 1138908631 M * ebiederm Bertl: If 200 is the pid of an entire guess no fd does not make sense. fd only makes sense for guest thread groups and guest threads. 1138908714 M * Bertl vrwttnmtu: probably 1138908748 M * Bertl ebiederm: so, we do not require more than one set of fd's then 1138908923 M * ebiederm There is a set of fd's per process right? (confused) 1138908964 M * Bertl yes, but we do not need more than that and only for the pids of the context 1138908999 M * ebiederm Correct. 1138909052 M * Bertl so pids x fds should be sufficient 1138909088 M * Bertl (which is what we have now) 1138909136 J * stevo ~x@c-24-63-24-247.hsd1.ma.comcast.net 1138909145 M * Bertl welcome stevo! 1138909150 M * stevo hey bert 1138909160 N * stevo nathan- 1138909170 M * nathan- its actually me from a very long time ago with SMP stuff :) 1138909185 M * Bertl ah, hey! LTNS! 1138909203 M * nathan- yea, still tracking the project from afar, working on a new deployment since the last one again 1138909228 M * nathan- so i may have created a monster and i was looking an opinion about it 1138909269 M * nathan- i want to use the plain init style so i can utilize inittab but i also want to see the console boot 1138909304 M * nathan- so my crazy method was composed of a fifo for /dev/console and then a reader which tosses it out to stdout and a log file 1138909314 M * nathan- it appears to work quite well actually 1138909332 M * nathan- the only risk i see is if the reader spontaneously dies and someone is writing to the console and ends up blocking on a FIFO write 1138909361 M * nathan- its all glued together with some pre-start/pre-stop and post-stop scripts which kill old readers and start new ones for the current stdout 1138909400 M * mugwump morning all 1138909411 M * Bertl nathan-: well, post it to the ML ... 1138909436 M * mugwump do you mind links to Experimental/ on the ML, Bertl? 1138909438 M * nathan- Bertl, yea i am hoping to, i am waiting for approval from the people that this is being done for 1138909478 M * nathan- Bertl, any thoughts about the FIFO in general? 1138909507 M * Bertl well, reminds me of the rebootmgr ... somewhat 1138909536 M * nathan- Bertl, the only side effects i have seen are stty failures and the fact that a getty obviously can't spawn against it 1138909632 M * nathan- you guys did a great job with the new style config btw 1138909827 M * Bertl kudos go to enrico for that 1138909858 M * nathan- i implemented a new style copy as well that hopefully i can contribute 1138909902 J * dhansen ~dave@sprucegoose.sr71.net 1138909957 M * Bertl wb dhansen! 1138910405 M * nathan- does it seem like a bad idea to bootstrap the init scripts with a chbind in the main machine? 1138910436 M * vrwttnmtu Just a quick question to any networking gurus here - anyone know where I can get hooked up to the Mbone? There's a surprising lack of sites.... 1138910812 M * Bertl nathan-: well, except for sshd that is probably fine 1138910824 M * nathan- Bertl, ssh wont be happy? 1138910900 M * Bertl sshd will be happy, but the admin probably not (because he will not be able to admin guests via ssh then) 1138910929 M * nathan- Bertl, oh thats not what i mean...l2:2:wait:/usr/sbin/chbind --ip 10.10.3.12/22 /etc/init.d/rc 2 1138910937 M * nathan- (/etc/inittab) 1138910946 M * nathan- i just rebooted the box, appears to work as i expected 1138910954 M * nathan- accept that people that should be bound to the loopback are no longer 1138910955 M * nathan- hmm 1138910981 M * nathan- accept=except, sad mistake 1138911079 M * Bertl well, depending on the kernel you are using, you might not be able to start a guest from within a restricted ssh 1138911143 M * nathan- hmm nested chbinds seem to work correctly which is what would prevent starting the guest on a new bind isnt it? 1138911184 M * Bertl again, what kernel version? 1138911195 M * nathan- 2.6.14.3 1138911202 M * nathan- vs2.0.1 1138911447 M * Bertl it works for now ... 1138911462 M * Bertl (no guarantees there though) 1138911496 M * Bertl okay, I'm pretty tired right now .. so I'm off to bed ... 1138911512 M * Bertl have a jolly good time and cya all later! 1138911521 N * Bertl Bertl_zZ 1138911569 M * nathan- night 1138912069 J * menomc ~amery@200.75.27.2 1138912121 J * nitin ~kvirc@59.176.98.7 1138912147 P * nitin So Long, and Thanks for All the Fish! 1138912173 M * mire hello, does vserver have anything to do with selinux? 1138912175 Q * mnemoc Ping timeout: 480 seconds 1138912176 N * menomc mnemoc 1138912186 M * mire Running test transaction: 1138912186 M * mire /etc/security/selinux/file_contexts: No such file or directory 1138912236 M * mire this is what happens when I use yum to install a package in vserver fedora client 1138912654 M * daniel_hozac shouldn't be a problem. 1138912742 J * virtuoso_ ~s0t0na@shisha.spb.ru 1138912743 Q * virtuoso Read error: Connection reset by peer 1138912783 J * Aiken ~james@tooax6-224.dialup.optusnet.com.au 1138913165 Q * yang Ping timeout: 480 seconds 1138913729 N * ebiederm ebiederm_oO 1138914436 J * NetAsh ~foo_bar@195.12.186.244 1138914441 M * NetAsh hello 1138914700 M * NetAsh have anyone tried cpu freequency scaling with vserver 1138914728 M * NetAsh aka witch daemons work or witch kernel modules work? 1138915401 M * NetAsh ./ 1138915418 M * NetAsh all sleeping - so will do I :) 1138915420 M * NetAsh by 1138915422 Q * NetAsh Quit: 1138917744 M * Skram Hii All. School sucked. 1138917765 M * daniel_hozac as is its purpose. 1138917839 M * Skram ;) 1138918143 Q * nathan- Quit: My damn controlling terminal disappeared! 1138918914 J * Smutje_ ~Smutje@xdsl-84-44-242-141.netcologne.de 1138919039 Q * Smutje Ping timeout: 480 seconds 1138919039 N * Smutje_ Smutje 1138919089 Q * Aiken Ping timeout: 480 seconds 1138919635 P * meandtheshell 1138920070 P * stefani I'm Parting (the water) 1138920826 P * mcp bloss wech hier ... ;-) 1138920973 J * Spudz0r ~matthew@CPE-144-136-203-192.sa.bigpond.net.au 1138921300 M * Spudz0r hey folks, im running vserver 2.0 on ubuntu and was wondering, i have cable internet on eth1, and i cant get anything outside on my vserver's - i look @ ip route, and it points to the outside server, i need the vservers to have internet access behind the firewall (which is currently running on the base system), either that or move the firewall to a new vserver and change the base's ip route to point to the firewall, but in that case 1138921330 Q * Viper0482 Ping timeout: 480 seconds 1138921372 M * daniel_hozac your message got cut off ;) 1138921397 Q * Doener Quit: Leaving 1138921399 M * daniel_hozac but anyway, you just need to SNAT your vservers for them to have internet access. 1138921401 J * Doener doener@i5387E45D.versanet.de 1138921435 M * Spudz0r lol, okay, :S 1138921449 M * Spudz0r i've never used vservers before, so how would i do that? 1138921450 M * Spudz0r :P 1138921492 M * daniel_hozac just as if you didn't have vservers at all. 1138921503 M * daniel_hozac all networking happens on the host (for now). 1138921515 M * daniel_hozac guests are just limited to a subset of the available IP addresses. 1138921538 M * Spudz0r uhuh, so im gathering that in shorewall on the base system is where i'd setup nat? 1138921561 M * daniel_hozac IIRC there was a shorewall thread on the ML not too long ago. 1138921571 J * click_ click@ti511110a080-4706.bb.online.no 1138921590 M * daniel_hozac http://archives.linux-vserver.org/200601/0297.html 1138921628 M * Spudz0r kool, yer, my two options were to either a: run the firewall on the base system, or b: run the firewall on the vserver and get the internet device (eth1) onto that vserver.. :S 1138921632 M * Spudz0r so yer haha 1138921667 Q * click Read error: Connection reset by peer 1138921729 M * daniel_hozac guests have no concept of interfaces. 1138921735 M * daniel_hozac IP addresses only. 1138921765 M * Spudz0r yer, i figured that when i saw that theres no ip listed in ifconfig :D 1138921797 M * daniel_hozac ifconfig is old and broken. 1138921804 M * daniel_hozac use ip from iproute2 instead. 1138921910 M * Spudz0r yer :P 1138921940 M * dearaujo hello - for some reason the guest on fc4 is trying to shutdown lo during vserver stop...how do I fix it to not do this 1138922153 M * daniel_hozac dearaujo: chkconfig network off 1138922220 M * dearaujo also - when I bind the guest address the to host and then shutdown the vserver - the host cannot get on the network 1138922236 M * dearaujo after I do a dhclient on the host it works again 1138922261 M * dearaujo daniel_hozac: thanks 1138922280 M * daniel_hozac you have the host and the guest on the same address? 1138922296 M * dearaujo yes - i only have 1 to spare :( 1138922307 M * dearaujo i realize that's bad practice 1138922319 M * daniel_hozac do you have a nodev file in /etc/vservers/.../interfaces/...? 1138922325 M * dearaujo let me check 1138922356 M * dearaujo no 1138922364 M * daniel_hozac that's the cause then. 1138922369 M * dearaujo only prefix ip and dev 1138922378 M * daniel_hozac without nodev, vserver will be managing the IP address. 1138922403 M * daniel_hozac i.e. (trying to) add it when you start it, and remove it when you stop it. 1138922410 M * dearaujo so just echo "eth0" > nodev 1138922418 M * dearaujo and remove dev 1138922419 M * daniel_hozac just touch nodev. 1138922422 M * dearaujo oh ok 1138922426 M * dearaujo dev can stay? 1138922445 M * daniel_hozac i think so, but that's sort of ambigious so it's better to remove it. 1138922452 M * dearaujo ok 1138922455 M * dearaujo thanks for the help 1138922462 M * daniel_hozac (it wouldn't be used even if it did work) 1138922467 M * dearaujo heh 1138922639 P * dearaujo 1138922726 J * dothebart ~willi@xdsl-213-196-242-216.netcologne.de 1138923174 Q * tudenbart Ping timeout: 480 seconds 1138923219 M * Spudz0r hrm, okay, well, i've been looking at that page you gave me, i dont have an internet static ip address. so how would i go about working this out? 1138923895 M * Spudz0r hrm, can i setup vserver so that i have a firewall vserver and have all the eth1 traffic coming into that? 1138924143 M * Spudz0r ie: can i simply just put an eth1 into a vserver? 1138924191 M * Spudz0r daniel_hozac: ? 1138924344 M * Spudz0r the faq on the website says 'is it possible to use the real device (eth0, eth1) instead of the device alias created by vserver? -> yes, setup the ip aliases yourself on the host server, set IPROOT= to those IPs, unset IPROOTDEV || where do i do this in vserver 2.0?