1299283772 J * BenG ~bengreen@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com
1299283813 Q * BenG 
1299284426 Q * dowdle Remote host closed the connection
1299285487 J * selim ~chatzilla@e181080238.adsl.alicedsl.de
1299285487 Q * selim 
1299286460 Q * ghislain Quit: Leaving.
1299288657 Q * Piet Quit: Piet
1299290272 Q * Hunger Remote host closed the connection
1299290313 J * Hunger ~Hunger@Hunger.hu
1299290475 Q * FireEgl Ping timeout: 480 seconds
1299292444 M * MooingLemur does vserver support having a ::1 address on lo?
1299292627 M * Bertl yes, but not in a network isolated way (yet)
1299292854 M * MooingLemur aha
1299292873 M * Bertl i.e. you won't have lback remapping for ipv6
1299292880 M * MooingLemur In the meantime, I've filed a bug against a perl module that makes that assumption :)
1299292922 M * MooingLemur well, rather, one of its tests makes that assumption and fails
1299293294 J * FireEgl ~FireEgl@173-25-19-139.client.mchsi.com
1299295510 Q * manana Remote host closed the connection
1299295876 Q * Hunger Quit: _._
1299295954 M * Bertl off to bed now ... have a good one everyone!
1299295959 N * Bertl Bertl_zZ
1299296103 J * Hunger ~Hunger@Hunger.hu
1299297965 Q * FireEgl Ping timeout: 480 seconds
1299298589 J * FireEgl ~FireEgl@173-25-19-139.client.mchsi.com
1299300632 J * ktwilight__ ~keliew@91.176.188.163
1299300930 Q * ktwilight_ Ping timeout: 480 seconds
1299303123 J * _reid ~bubblegum@pool-108-10-21-156.chi01.dsl-w.verizon.net
1299306881 J * selim ~chatzilla@e181080238.adsl.alicedsl.de
1299306884 Q * selim 
1299311848 J * nkukard ~nkukard@41-133-249-230.dsl.mweb.co.za
1299314927 N * ensc Guest3616
1299314937 J * ensc ~irc-ensc@p5DF2F210.dip.t-dialin.net
1299315095 Q * Guest3616 Ping timeout: 480 seconds
1299315756 J * petzsch ~markus@p57B648DF.dip.t-dialin.net
1299315925 J * manana ~mayday090@84.17.25.149
1299317229 J * kir ~kir@swsoft-msk-nat.sw.ru
1299318394 Q * wibble_ Server closed connection
1299318395 J * wibble wibble@vortex.ukshells.co.uk
1299318824 J * bonbons ~bonbons@2001:960:7ab:0:11c7:22df:be85:9938
1299319151 P * kir Leaving.
1299319528 J * hetto ~hetto@95.111.5.142
1299319802 M * hetto Hello guys! I'm reading through the wiki and I find the section on namespaces security: http://wiki.linux-vserver.org/Namespaces#Security . It says there that the enhanced security is achieved by combining bind mount with chroot. How exactly is this done? I know what namespaces are but am not sure about how the combination with chroot is done. Can anyone explain? 
1299319869 M * hetto ... in order to avoid chroot break outs.
1299319976 M * hetto is it through unbindable mount plus a chroot() call? Or something more complicated. 
1299320716 Q * petzsch Quit: Leaving.
1299321299 J * ghislain ~AQUEOS@adsl2.aqueos.com
1299321326 Q * Guy- Server closed connection
1299321418 J * Guy- ~korn@elan.rulez.org
1299321678 J * petzsch ~markus@p57B648DF.dip.t-dialin.net
1299321965 Q * Bertl_zZ Server closed connection
1299321965 J * Bertl_zZ herbert@IRC.13thfloor.at
1299324102 J * Piet ~Piet__@04ZAAC48W.tor-irc.dnsbl.oftc.net
1299324263 M * daniel_hozac hetto: pivot_root
1299324309 M * hetto pivot_root() is used instead of chroot()?
1299324311 Q * daniel_hozac Server closed connection
1299324323 J * daniel_hozac ~daniel@c-aa3771d5.08-230-73746f22.cust.bredbandsbolaget.se
1299324339 M * hetto pivot_root() is used instead of chroot()?
1299324633 M * daniel_hozac yes.
1299324937 M * hetto ha. makes sense 
1299325389 Q * s0undt3ch Remote host closed the connection
1299326245 J * Piet_ ~Piet__@04ZAAC5AK.tor-irc.dnsbl.oftc.net
1299326535 Q * niki Quit: Leaving
1299326655 Q * Piet Ping timeout: 480 seconds
1299326877 Q * C14r Server closed connection
1299326878 J * C14r ~C14r@mail.cipworx.de
1299328480 Q * fback Ping timeout: 480 seconds
1299330202 N * Bertl_zZ Bertl
1299330206 M * Bertl morning folks!
1299330346 Q * hoax Server closed connection
1299330347 J * hoax U2FsdGVkX1@dhcp-077-249-151-209.chello.nl
1299330643 M * daniel_hozac morning Bertl
1299331992 M * Bertl off to grab some groceries ... bbl
1299331996 N * Bertl Bertl_oO
1299332866 M * daniel_hozac hmm
1299332869 M * daniel_hozac no Hollow around?
1299332873 Q * Eruquen Server closed connection
1299332887 J * Janno Janno@server3.raumopol.de
1299333328 J * geos_one ~chatzilla@chello084115149052.4.graz.surfer.at
1299333930 Q * geos_one Quit: ChatZilla 0.9.86 [Firefox 4.0b13pre/20110304223152]
1299333980 J * geos_one ~chatzilla@chello084115149052.4.graz.surfer.at
1299334191 Q * _raceme_ Server closed connection
1299334198 J * raceme ~tof@ombos.raceme.org
1299334386 Q * geos_one Quit: ChatZilla 0.9.86-2011011818 [Firefox 4.0b13pre/20110304223152]
1299334856 Q * petzsch Quit: Leaving.
1299335518 J * petzsch ~markus@p57B648DF.dip.t-dialin.net
1299336007 Q * DLange Server closed connection
1299336022 J * DLange ~DLange@dlange.user.oftc.net
1299336059 Q * karasz Server closed connection
1299336070 J * karasz ~karasz@shell.opensde.net
1299336163 Q * BobR_zZ Server closed connection
1299336164 J * BobR_zZ odie@IRC.13thfloor.at
1299336814 Q * manana Remote host closed the connection
1299337051 Q * _reid Ping timeout: 480 seconds
1299337158 N * ensc Guest3654
1299337168 J * ensc ~irc-ensc@p5DF2F210.dip.t-dialin.net
1299337330 Q * Guest3654 Ping timeout: 480 seconds
1299337596 J * manana ~mayday090@84.17.25.149
1299338104 N * ensc Guest3656
1299338112 J * ensc ~irc-ensc@p5DF2E0BB.dip.t-dialin.net
1299338191 N * Piet_ Piet
1299338514 Q * Guest3656 Ping timeout: 480 seconds
1299338883 Q * _are_ Server closed connection
1299338894 J * _are_ ~quassel@vs01.lug-s.org
1299339219 J * fback fback@red.fback.net
1299339848 J * petzsch1 ~markus@p57B66A71.dip.t-dialin.net
1299340230 Q * petzsch Ping timeout: 480 seconds
1299342053 Q * petzsch1 Quit: Leaving.
1299342289 J * petzsch ~markus@p57B66A71.dip.t-dialin.net
1299344398 J * stephankn 55b54a1c@ircip2.mibbit.com
1299346102 M * stephankn hi, are the values for used memory of htop inside a guest accurate? The displayed value is suspicious low
1299346389 M * daniel_hozac what kernel, what configuration, where does htop get its data from?
1299346431 M * stephankn Linux 2.6.33.7-vs2.3.0.36.30.4-netcup #1 SMP Tue Nov 16 08:24:31 UTC 2010 x86_64 GNU/Linux
1299346520 M * stephankn no idea where htop get's its value from. But it tells me 130M used. For a preforked apache and a database as main apps this sounds too low
1299346531 M * daniel_hozac sounds like a lot to me...
1299346538 J * imcsk8 ~ichavero@148.229.9.250
1299346863 M * stephankn hm, ok. So assuming this value is accurate, then I have 800M free physical ram left. The reason I started looking at this is that munin on localhost is getting timeouts from time to time
1299346926 M * stephankn it waits for 10 seconds for a script.  That is running in way below a second. No idea why it should take 10 seconds.
1299347000 N * Bertl_oO Bertl
1299347006 M * stephankn are there known issues with iowait and virtualization? I have a hard time debugging as I'm just on the guest. The provider usually denies problems on the host.
1299347020 M * Bertl there can be a bunch of reasons for that, all of them not related to Linux-VServer :)
1299347037 M * daniel_hozac that kernel is known to have problems in the IO subsystem.
1299347062 M * Bertl upgrading to 2.6.36+ is a good idea to tackle I/O performance
1299347093 M * Bertl 2.6.38-rc is almost perfect I/O wise, i.e. works like a charm here
1299347101 M * stephankn I know other people experiencing delays when calling sync in the vm,
1299347163 M * stephankn Do you have some link to more information regarding io problems with the 2.6.33 kernel? I would like to forward this to the provider to suggest an upgrade
1299347266 M * Bertl not really, it was just by observation ... but ptobably checking the changelogs will reveal some relevant changes
1299347303 M * Bertl starting with 2.6.23, I/O performance went down, not the peak performance but it started to get laggy
1299347355 M * Bertl around 2.6.30 or so, we had high peak performance interrupted with long periods where the kernel just sits there and waits, i.e. it looks like it is doing nothing
1299347372 M * Bertl then, from one moment to the other, you get back full I/O performance
1299347383 M * Bertl (note: this was with unpatched mainline)
1299347518 M * Bertl 2.6.36 was the first where performance over several lvm/raid layers worked fine again (since 2.6.22) and overall I/O performance was quite nice and really responsive
1299347525 M * stephankn Bertl: thank you for the hints. I will try to get the prople to think about an update to 2.6.36
1299347544 M * Bertl 2.6.37 has some other issues, nothing I/O related though, and 2.6.38 seems to be the best so far
1299347579 M * stephankn not sure they would consider 2.6.38 as it's quite new...
1299347601 M * Bertl yeah, no problem 2.6.36 should be already 'good enough'
1299351067 Q * stephankn Quit: http://www.mibbit.com ajax IRC Client
1299354764 Q * Piet Ping timeout: 480 seconds
1299356814 J * BenG ~bengreen@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com
1299356958 J * Piet ~Piet__@04ZAAC5TN.tor-irc.dnsbl.oftc.net
1299358317 Q * BenG Quit: I Leave
1299359158 J * cuba33ci_ ~cuba33ci@111-240-171-231.dynamic.hinet.net
1299359510 Q * cuba33ci Ping timeout: 480 seconds
1299359516 N * cuba33ci_ cuba33ci
1299360133 M * MooingLemur Bertl: what issues with 2.6.37 do you have in mind?
1299361029 M * daniel_hozac Bertl: i'm seeing weird proc behaviour on 2.6.37.
1299361240 M * daniel_hozac Bertl: basically, running ps in a guest with its own init makes ps in the host return that init twice, and not show the host's init.
1299361532 M * daniel_hozac it looks like we lost the vserver code in pid_revalidate?
1299362291 Q * hetto Quit: Leaving
1299363386 Q * petzsch Quit: Leaving.
1299366240 M * Bertl hmm .. and in 2.6.38?
1299366277 M * daniel_hozac code is missing there as well, but i haven't run it to test.
1299366290 M * Bertl okay, will check that shortly
1299366296 M * daniel_hozac fairly simple, vserver <guest> exec ps faux; vps faux
1299366299 M * daniel_hozac vps will be messed up.
1299366313 M * Bertl ah, good to have a quick test :)