1130632758 J * menomc ~amery@200.75.27.71
1130632865 Q * mnemoc Ping timeout: 480 seconds
1130632865 N * menomc mnemoc
1130632964 Q * Doener_ Remote host closed the connection
1130635807 Q * jayeola Quit: leaving
1130639516 J * mep_ mep@p5091B459.dip0.t-ipconnect.de
1130639955 Q * mep Ping timeout: 480 seconds
1130643744 M * Bertl okay, night folks! cya tomorrow!
1130643763 M * Bertl (expect 2.6.14 patches soon)
1130643772 N * Bertl Bertl_zZ
1130647251 J * lilo_ ~lilo@lilo.usercloak.oftc.net
1130647691 Q * lilo Ping timeout: 480 seconds
1130659461 Q * matti Ping timeout: 480 seconds
1130663629 J * oliwel ~mail-at-o@host-62-245-151-178.customer.m-online.net
1130664395 J * cantabile_03 ~cantabile@AOrleans-204-1-4-20.w80-13.abo.wanadoo.fr
1130664447 M * cantabile_03 Hi. I have a message saying "RTNETLINK answers: File exists" while my gentoo vserver is booting. I guess it is related with network settings, but I can't find out what's going wrong. Do you have any idea ?
1130664448 Q * oliwel Quit: Chatzilla 0.9.68.5 [SUSE 1.0.6-4.1/20050715]
1130664514 P * cantabile_03
1130664535 J * cantabile_03 ~cantabile@AOrleans-204-1-4-20.w80-13.abo.wanadoo.fr
1130664566 M * cantabile_03 Hi. I have a message saying "RTNETLINK answers: File exists" while my gentoo vserver is booting. I guess it is related with network settings, but I can't find out what's going wrong. Do you have any idea ?
1130665156 Q * cantabile_03 Quit: Leaving
1130665169 J * cantabile_03 ~cantabile@AOrleans-204-1-4-20.w80-13.abo.wanadoo.fr
1130665261 Q * cantabile_03 Quit:
1130666012 J * cantabile_03 ~cantabile@AOrleans-204-1-4-20.w80-13.abo.wanadoo.fr
1130666060 M * cantabile_03 found it : I was trying to set up a net device already up !
1130666068 P * cantabile_03
1130666555 Q * SiD3WiNDR Ping timeout: 480 seconds
1130666595 J * SiD3WiNDR luser@bastard-operator.from-hell.be
1130670022 J * yarihm ~yarihm@80-218-5-17.dclient.hispeed.ch
1130670530 M * daniel_hozac util-vserver 0.30.209, wee.
1130671225 Q * yungyuc Remote host closed the connection
1130672895 J * prae ~benjamin@sherpadown.net
1130673547 J * sebi ~sebi@Fce30.f.strato-dslnet.de
1130673650 Q * sebi_ Ping timeout: 480 seconds
1130674914 Q * mep_ Ping timeout: 480 seconds
1130674944 Q * shedi Quit: Leaving
1130676250 M * ag- daniel_hozac: i suppose it includes the patches at ?
1130676277 M * daniel_hozac fix03 seems to be included, i haven't checked too thoroughly though.
1130676452 M * daniel_hozac shiny7, 2.1.0-rc4 headers, ctx_create_v0, no ENSC_SYSCALL_TRADITIONAL... so yes, fix03 is included.
1130676501 M * ag- man, 2.6.14 is a pain, they got rid of xattr stuff in devpts/inode.c...
1130676543 M * ag- i'm stuck at that point...
1130676713 J * yungyuc ~yungyuc@220-135-53-220.HINET-IP.hinet.net
1130676726 M * ag- there's no more #ifdef CONFIG_DEVPTS_FS_XATTR in the code, but it's still in the arch/*/configs/*
1130676741 A * ag- is lost
1130677702 Q * Loki|muh_ Remote host closed the connection
1130677716 J * Loki|muh loki@satanix.de
1130677909 M * daniel_hozac doesn't 2.0.1-pre2 support JFS? i can't seem to find any references for barrier or iunlink in fs/jfs.
1130678099 M * daniel_hozac or is that on a higher level?
1130678451 N * Bertl_zZ Bertl
1130678459 M * Bertl morning folks!
1130678465 M * daniel_hozac morning!
1130678479 M * Bertl daniel_hozac: jfs unfortunately does not support attributes like immutable (yet)
1130678502 M * Bertl so there is also no persistent barrier implementation
1130678513 M * daniel_hozac ok, just wondered if i had screwed something up when adapting the patch when testfs failed ;)
1130678525 M * Bertl no, thats quite fine ...
1130678541 M * Bertl the xid tagging should work though
1130678646 M * daniel_hozac yeah, xid tests all pass.
1130678710 J * monrad ~monrad@213083190134.sonofon.dk
1130678841 M * Bertl welcome monrad!
1130678854 M * monrad ho
1130678857 M * monrad hi even
1130678865 M * Bertl daniel_hozac: btw, adapting? maybe to 2.6.14?
1130678875 M * daniel_hozac Bertl: no, sorry, just Fedora ;)
1130678885 M * Bertl ah, good!
1130678921 M * Bertl daniel_hozac: do you plan/do fc* support/ports?
1130678978 M * daniel_hozac well, FC at least.
1130679027 M * daniel_hozac i've been meaning to do FC as well, but haven't gotten around to it yet.
1130679040 M * Bertl okay, so I can/should point folks doing fc* as host in your direction?
1130679081 M * daniel_hozac yeah, sure. i think i have links on most of the Fedora Core howtos already.
1130679144 M * Bertl excellent!
1130679304 M * ag- hi Bertl!
1130679323 M * ag- did you have a look for porting 2.1.0-rc4.1 to 2.6.14? i'm lost at some point :)
1130679505 M * Bertl I already finished the port ... just cleaning up
1130679524 M * Bertl nevertheless could you upload your latest results somewhere?
1130679531 M * Bertl (I'd like to compare the code)
1130679547 M * ag- Bertl: excellent! i'm looking forward to it
1130679644 M * ag- it's not a complete patch: i only got the 7 first rejected files done :/
1130679893 M * Bertl okay, just upload a single patch (after you cleaned the tree up) so I can apply that
1130680227 M * ag- Bertl: the files to look at are: ./arch/ia64/ia32/binfmt_elf32.c.rej, ./arch/ia64/kernel/perfmon.c.rej, ./arch/ia64/mm/fault.c.rej, ./arch/m68k/kernel/ptrace.c.rej, ./arch/mips/kernel/sysirix.c.rej, ./arch/x86_64/ia32/ia32_binfmt.c.rej, ./drivers/acpi/osl.c.rej; and a new patched one: ./mm/mmap.c
1130680244 M * ag- Bertl: the patch is here:
1130680359 M * ag- oops, just forget the .rej at the end :P
1130680527 M * Bertl np
1130680627 M * Bertl 2.0.1-rc4.1 is an interesting number ...
1130680657 M * ag- ah! damnit! another mistake...
1130680663 M * ag- it's 2.1.0 ;)
1130680675 M * Bertl it's 2.1.0 I assume?
1130680685 M * Bertl yup, okay ...
1130681623 J * wally ~homebase@intranet.kapper.net
1130681755 M * AndrewLee hi
1130681771 J * FaUl 0GKLudchhe@verbrennung.org
1130681772 M * FaUl hi
1130681783 M * Bertl welcome wally! FaUl!
1130681789 M * FaUl hey bertl
1130681797 M * Bertl wally: so you want to help ngnet development :)
1130681815 M * wally well, lets see :)
1130681878 M * Bertl okay, I take it, you are at least interested
1130681903 M * FaUl Bertl: I'd like to help too, but I'm to busy at the moment with other projects. But I want you to know if you need someone with help/testing on ipv6-support on ngnet let me know, i'll do my very best finding time to help you
1130681941 M * wally sure, actually not clear to me whether to wait for a working ngnet-version or if we should stay with "conventional" vservers or probably switch to xen-architecture ... so basically I'm pretty curious :)
1130681971 M * Bertl FaUl: okay, I guess we'll come back to that sooner or later ...
1130681976 M * AndrewLee I am trying to use vlan device in a vserver, seems is works but I got 127.0.0.1 even it has configurations in interfaces/0/{ip,dev}.
1130682044 M * Bertl AndrewLee: tool version?
1130682047 M * AndrewLee util-vserver 0.30.208-4 from sid
1130682063 M * Bertl okay, and you interfaces/0 config looks like?
1130682066 M * AndrewLee vlan 1.9-1 from sid as well.
1130682114 M * FaUl Bertl: i'm still very interested in ipv6-support of vserver :-)
1130682128 M * Bertl it will happen, trust me :)
1130682128 M * AndrewLee eth0.121 in interfaces/0/dev, 10.1.2.1/24 in interfaces/0/ip
1130682154 M * Bertl put 10.1.2.1 in ip and 24 in prefix :)
1130682275 M * AndrewLee Bertl: Same result.
1130682306 M * AndrewLee ifconfig eth0.121 got inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0
1130682324 M * Bertl sec
1130682362 M * FaUl strange
1130682908 J * the_hydra ~a_mulyadi@202.147.200.25
1130683225 Q * wally Read error: Connection reset by peer
1130683333 M * Bertl welcome the_hydra!
1130683348 M * the_hydra hello bertl
1130683355 M * the_hydra i am just visiting this channel
1130683366 M * Bertl feel free to hang around ...
1130683371 M * the_hydra anyway, IIRC you use Bertl_sick couple days ago
1130683377 M * the_hydra sick?
1130683383 M * Bertl _ILL but yes ...
1130683393 M * the_hydra ah yes, ill sorry..i forgot
1130683398 M * Bertl caught the flu, nothing serious ... it's already much better
1130683421 M * the_hydra just don't get caught by avian flu
1130683424 M * the_hydra it is so terrible
1130683466 M * Bertl yep, that would be tragic ...
1130683564 M * the_hydra anyway, just popped from my head.....does Vserver provides CPU utilization limit ?
1130683601 M * Bertl yep, we have something called the token bucket scheduler ...
1130683614 J * wally ~homebase@mail.mcmarketing.at
1130683644 M * the_hydra hm
1130683652 M * AndrewLee Bertl: Should I add vlan settings into /etc/network/interfaces?
1130683665 M * FaUl re wally
1130683686 M * the_hydra thanks Bertl
1130683687 A * AndrewLee is trying to add vlan settings into /etc/network/interfaces
1130683697 M * Bertl AndrewLee: I tried to get my test system working but no success atm ...
1130683949 M * AndrewLee Bertl: Same result even I add vlan seetings into /etc/network/interfaces file
1130683985 M * Bertl AndrewLee: you have to wait a little until I adjusted my QEMU test system for vlans
1130684033 M * AndrewLee Bertl: not need to hurry, I will be here everyday. :)
1130684052 M * ag- vlan does not work with current vserver networking, i already tried
1130684072 M * Bertl it did a few weeks ago .. and I don't see why it should not
1130684119 M * ag- Bertl: you mean several guests in separate vlans?
1130684156 M * Bertl yup, or whatever 802.1q setup you prefer
1130684234 J * wally01 ~homebase@sg27-gw.1090.kapper.net
1130684239 M * ag- well, if you said it works, i blindly believe you :) i'll reschedule tests...
1130684253 M * Bertl I said, it 'worked' :)
1130684286 M * the_hydra hail to Bertl :)
1130684377 M * ag- gotcha :)
1130684450 M * Bertl wally01: well, Xen is a pretty nice project ... and it's somewhat complementary to linux-vserver ...
1130684486 M * the_hydra I second that Bertl
1130684695 Q * wally Ping timeout: 480 seconds
1130684720 Q * wally01 Ping timeout: 480 seconds
1130684746 M * Bertl ag-: okay, have you identified some parts (of ngnet) you would like to start with (for testing?)
1130684751 J * wally ~homebase@intranet.kapper.net
1130685047 M * ag- Bertl: i'm studying FIB and the old NGNET patch for now
1130685084 M * ag- Bertl: to my mind, the dual-homed network device would be a good place to start
1130685154 M * ag- Bertl: did you finish the port to 2.6.14? i'm quite eager to see what i couldn't do about it :)
1130685452 M * Bertl yep, you ahve to wait a few more minutes ... doing too many things at once right now (trashing)
1130685527 M * ag- no pb, take your time :)
1130686764 M * Bertl okay, as folks are waiting :)
1130686772 M * Bertl http://vserver.13thfloor.at/Experimental/patch-2.6.14-vs2.0.1-pre3-prelim.diff.bz2
1130686776 M * Bertl http://vserver.13thfloor.at/Experimental/patch-2.6.14-vs2.1.0-rc5-prelim.diff.bz2
1130686918 M * ag- haha! excellent! ;D
1130686961 M * FaUl Bertl: whats new isn 2.1?
1130686969 M * FaUl is there a changelog?
1130687042 M * Bertl not yet ... but I'll add it soon ...
1130687067 M * Bertl basically we have CoW link breaking there
1130687121 M * FaUl CoW?
1130687137 M * Bertl Copy on Write for unified files
1130687152 M * Bertl Aiken already tested it with total unification :)
1130687159 M * mnemoc Bertl: deltas between 2.0.1-pre2 and pre3?
1130687180 M * FaUl Bertl: that means basically?
1130687191 M * Bertl none yet ... the changes in 2.6.14 were impressive ... so some things had to be adjusted
1130687200 M * Bertl (that was for mnemoc)
1130687214 M * Bertl FaUl: you can use hard links for _all_ files inside a guest
1130687218 M * mnemoc Bertl: thanks
1130687235 M * Bertl mnemoc: there will be some changes in the final pre3
1130687268 M * FaUl Bertl: ah, but that will cause problems if someone break into one of my guests as if he installs a rootkit, it will appear in all guests, woudn't it?
1130687285 M * Bertl no, that's what the CoW takes care of :)
1130687292 M * FaUl ah
1130687296 M * FaUl thats quite nice
1130687307 M * Bertl yes, indeed :)
1130687323 M * mnemoc Bertl: what are the benefits of CoW vs. unionfs ?
1130687346 M * Bertl shared caches, smaller footprint, you can reunify at any time
1130687410 M * mnemoc nice
1130687452 M * Bertl AndrewLee: the config here works quite fine with vlan ...
1130687466 M * Bertl AndrewLee: tools: 0.30.208-fix03
1130687477 M * Bertl AndrewLee: vserver WWWW build -m skeleton --interface eth0.10:192.168.0.2/24 --context 100
1130687519 M * AndrewLee Bertl: Hum, I built the guest without give a name based vlan device.
1130687534 M * Bertl the 127.0.0.1 _is_ assigned to the vlan (not sure why) but also the 'real' ip
1130687544 M * AndrewLee Bertl: I change the dev file to vlan after I built the guest.
1130687547 M * Bertl 4: eth0.10: mtu 1500 qdisc noqueue link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff inet 127.0.0.1/8 brd 127.255.255.255 scope global eth0.10 inet 192.168.0.2/24 brd 192.168.0.255 scope global eth0.10
1130687623 M * AndrewLee Bertl: Yes, I got same result if I use ip addr
1130687626 M * AndrewLee 14: eth0.121: mtu 1500 qdisc noqueue
1130687626 M * AndrewLee link/ether 00:a0:c9:c8:93:78 brd ff:ff:ff:ff:ff:ff
1130687626 M * AndrewLee inet 127.0.0.1/8 brd 127.255.255.255 scope host eth0.121
1130687627 M * AndrewLee inet 10.1.2.1/24 brd 10.1.2.255 scope global eth0.121
1130687636 M * Bertl so it should work for you too, no?
1130687654 M * AndrewLee Bertl: but ifconfig reports 127.0.0.1 only.
1130687669 M * Bertl well, ifconfig is several years old :)
1130687691 M * Bertl also, inside the guest, you should see the correct value, no?
1130687703 M * Bertl (because 127.0.0.1 is not assigned to the guests)
1130687711 M * AndrewLee Bertl: Let me try to use ip list inside of a guest
1130687831 M * AndrewLee Bertl: Yes, I got correct ip address inside of a guest
1130687877 M * AndrewLee Bertl: Thank you for you help.
1130687878 M * Bertl AndrewLee: so why the noise :)
1130687903 M * Bertl AndrewLee: don't worry, it was a joke ...
1130687944 M * Bertl AndrewLee: and I consider the 127.0.0.1 a bug, and would ask you to report it to savannah/enrico
1130687974 M * AndrewLee Bertl: Ok, my pleasure. :)
1130688075 Q * prae Quit: Pwet
1130688553 M * Bertl AndrewLee: thanks!
1130688871 M * Bertl okay, dinner time .. back later ...
1130688882 M * the_hydra cu Bertl
1130688952 A * AndrewLee is still trying to get a accout on savannah.
1130690084 J * eyck eyck@81.219.64.71
1130690477 M * Bertl back now ...
1130690588 M * the_hydra wb Bertl
1130690594 M * the_hydra someone ask about routing on #kn
1130690604 M * the_hydra can you share your idea there?
1130690715 M * FaUl #kn?
1130690742 M * the_hydra kernelnewbies
1130690745 M * FaUl ah
1130690769 M * the_hydra or, you can join it ....#kn always welcome newcomer :)
1130690894 M * Bertl ag-: sounds reasonable, any ideas on your side how to do that (multi-homed interface)?
1130690909 M * Bertl ag-: also, do you have a working test setup (maybe with QEMU?)
1130691826 Q * the_hydra Quit:
1130692080 M * Bertl wow 0.30.209 is out!!!!
1130692088 M * Bertl http://www.13thfloor.at/~ensc/util-vserver/files/alpha/util-vserver-0.30.209.tar.bz2
1130692132 M * daniel_hozac [12:08] util-vserver 0.30.209, wee. ;)
1130692154 M * Bertl daniel_hozac: why didn't you tell me :)
1130692201 M * Bertl AndrewLee: plz try again with 0.30.209 :)
1130692207 M * daniel_hozac i thought that qualified as telling everyone ;)
1130692235 M * Bertl you know I'm lazy and ignorant ...
1130692773 M * ag- Bertl: it's a bit early for me to run my mouth, i'm still studying vserver code to get details in mind :)
1130692794 M * ag- Bertl: i test stuff on real hardware, qemu is *so* slow...
1130692876 M * ag- Bertl: well, except for s390 and ia64, i use hercules and ski -sigh- that last is proprietary :(
1130692923 M * Bertl yep, I know
1130692935 Q * brc Ping timeout: 480 seconds
1130692939 M * Bertl ag-: so you have a collection of different archs?
1130692963 M * Bertl ag-: and a serial console for development?
1130692997 M * ag- Bertl: btw, i had a talk with Al Stone which said there was some progress to opensource ski (2 big firms have IP in the code)...
1130693021 M * ag- Bertl: yep, actually, all debian arch, except s390 and ia64
1130693065 M * ag- it's a funny farm :) well they're slow, but less than qemu ;)
1130693074 M * Bertl ag-: great! that should simplify testing a lot ...
1130693620 M * Bertl ag-: okay, so you ahve your testing setup .. let's talk about the code
1130693651 M * ag- ok
1130693689 M * Bertl I'd suggest that we extend _all_ devices to be multihomed
1130693699 M * Bertl (dual homed first)
1130693736 M * Bertl and use the dual context information to encode visibility
1130693762 M * Bertl i.e. xid=0 host, xid=1 anywhere, xid=N context
1130693791 M * Bertl this way, we can control general interface visibility and create guest only interfaces
1130693890 M * FaUl .oO( I wonder what multihomed interfaces means )
1130694001 M * ag- Bertl: when you said, _all_ devices, you mean network interfaces or unix block and char devices?
1130694016 Q * ntrs Ping timeout: 480 seconds
1130694095 M * Bertl ag-: for now network devices (they are called 'dev')
1130694128 M * ag- ok, just a few vocabulary :)
1130694289 M * Bertl okay, so we 'simply' add a pair of xid tags to every (network) device
1130694318 M * Bertl the question now is, do we need a reference to the vx_info or just the xid tag?
1130694457 M * ag- Bertl: hum, to the vx_info struct would be a better idea, because we can access the namespace like that
1130694481 M * Bertl yes, but the vx_info also requires locking and a reference
1130694556 M * Bertl so the question is, do we _need_ one :)
1130694717 M * Bertl ag-: also, the namespace is not related to the device namespace
1130694890 M * ag- true, so we can only put the xid tags on the device
1130694982 M * ag- s/can/may/
1130694986 M * Bertl another issue is, when do we destroy devices and associations?
1130695008 M * Bertl or do we keep them around, even if the context is gone?
1130695028 M * Bertl or alternatively, re-tag them once the context is disposed
1130695032 M * ag- and another is, who has the right to destroy a share device? (the guest or the host?)
1130695048 M * ag- s/share/shared/
1130695052 M * Bertl we can control this by designating one tag as the 'rpimary'
1130695102 M * ag- why not simply destroying them when the context is disposed?
1130695321 M * Bertl how?
1130695330 M * Bertl (except for 'simply' :)
1130695419 M * ag- it's not simple to destroy them, i presume
1130695423 M * ag- well, i don't know :)
1130695444 J * matti matti@linux.gentoo.pl
1130695466 M * Bertl ag-: okay, first, what devices will be created by a guest?
1130695548 M * ag- we need a loopback device only for the guest, people like it
1130695643 M * ag- and then, one or several devices to get out of the guest
1130695689 M * ag- each not loopback device shall appear on the host
1130695815 M * Bertl or on a different guest :)
1130695835 M * Bertl but yes, so basically we have loopback devices inside the guest
1130695845 M * ag- right to the extend
1130695850 M * Bertl kind-of-loopback devices across guest/host
1130695878 M * Bertl and some userspace related devices like tun/tap/ppp devices
1130695913 M * ag- you want to use them in a guest?
1130695921 M * Bertl sure, why not?
1130695948 M * ag- so, the guest must have the right capability
1130695962 M * ag- NET_ADMIN, i think
1130695992 M * Bertl yep, which is what folks want anyway ...
1130696102 M * Bertl okay, let's statr
1130696127 M * Bertl *start with something simple, I'll walk the code and
1130696147 M * Bertl point out the required changes, you take some notes, yes?
1130696151 M * ag- yup
1130696169 M * Bertl please let me know if something is not the way you want it ...
1130696179 M * ag- sure
1130696204 M * Bertl okay, base kernel is (of course) 2.6.14-vs2.1.0-rc5
1130696214 M * ag- right, got it
1130696270 Q * monrad Quit: Leaving
1130696277 M * Bertl I always start at loopback (because it's easy to remember and find :)
1130696335 M * Bertl loopback_init()
1130696338 M * Bertl drivers/net/loopback.c
1130696345 M * ag- ok, i'm here
1130696347 J * stefani ~stefani@c-24-19-46-211.hsd1.wa.comcast.net
1130696353 M * Bertl welcome stefani!
1130696361 M * stefani hola.
1130696373 M * stefani you have recovered from illness?
1130696376 M * Bertl ag-: so this 'registers' a net device
1130696389 M * Bertl stefani: not completely, but mostly
1130696454 M * Bertl ag-: do you have cscope or vim/emacs tags?
1130696470 M * ag- Bertl: i do
1130696516 M * ag- vim tags actually
1130696619 M * Bertl okay, so let's move to net_device
1130696648 J * shedi ~siggi@inferno.lhi.is
1130696756 M * Bertl ag-: we see there, ifindex and iflink
1130696834 M * Bertl also we have the comment about the 'visible' part
1130697187 M * Bertl ag-: okay?
1130697209 M * ag- Bertl: yep, so we can put something vserver-related in the public part
1130697237 M * Bertl well, we probably should put it into the non-visible section, e.g.
1130697259 M * Bertl right after hard_header_len
1130697280 M * Bertl or after the master device reference
1130697338 J * monrad ~monrad@213083190134.sonofon.dk
1130697391 M * ag- in the private part, because it's something developers (we) may change at will :)
1130697395 M * ag- ok, got it
1130697570 M * ag- Bertl: i don't see an unregister_netdev() for loopback...
1130697982 M * Bertl yep, because that never happens :)
1130698016 M * Bertl okay, now let's add an entry like this
1130698035 M * Bertl xid_t dev_xid[2];
1130698167 M * Bertl now, your 'next' task is to add visibility checks for interface devices (based on this marker) and replace the existing checks ...
1130698202 M * Bertl to allow this for both legacy and ngnet, we will not replace the current checks, but generalize them
1130698221 M * Bertl first step: where are the places to modify those checks?
1130698340 M * AndrewLee Bertl: Seems I don't need to report the bug, cause it's gone in 0.30.209. :)
1130698355 M * Bertl excellent!
1130698422 M * AndrewLee Bertl: Even ifconfig can see the ip address inside of a guest.
1130698573 M * AndrewLee Bertl: Does any way to add/remove routing tables for a guest?
1130698584 M * Bertl ip route ?
1130698615 M * AndrewLee Bertl: Can I use iproute to modify routing table inside of a guest?
1130698625 A * AndrewLee is trying
1130698628 M * Bertl not from inside, but for the guest
1130698690 M * ag- Bertl: in net/core/dev.c and net/core/rtnetlink.c, you do something about visibility with the macro VXF_HIDE_NETIF
1130698703 M * ag- Bertl: in several files in net/core/
1130698728 M * ag- Bertl: wouldn't it conflict with what we wanna do?
1130698785 M * Bertl okay, so basically the places were we have VXF_HIDE_NETIF checks, we want to 'modify' the checks slightly
1130698798 M * AndrewLee Bertl: A guest uses same routing table as host by default, doesn't it? How do I remove routing table only for the guest?
1130698822 M * ag- yup, slightly to avoid breaking legacy net support
1130698824 M * Bertl AndrewLee: a guest uses the routing tables of the host. period.
1130698844 M * Bertl AndrewLee: what you probably want is: http://archives.linux-vserver.org/200311/0470.html
1130698856 M * Bertl (Documentation, archived knowledge)
1130698887 M * Bertl ag-: exactly ... now we talked about choosing between ngnet and legacy at compile time ...
1130698923 M * Bertl let's spend a few minutes to think about ngnet vs legacy net at runtime
1130698949 M * Bertl let's assume we have tagged interface (what we are going to do pretty soon)
1130698968 M * Bertl let's further assume that the network stack is completely virtualized
1130698985 M * Bertl (i.e. it is based on the tagging of skbs)
1130699022 M * Bertl what would be required to 'emulate' legacy networking
1130699028 M * Bertl ?
1130699115 M * ag- Bertl: well, a passtrough to the real interface, i.e. a virtual interface which is the real one
1130699161 M * ag- Bertl: we talk about keeping legacy and ng together for performance reasons
1130699183 M * Bertl okay, why a passthrough?
1130699284 M * ag- hum, bad term usage
1130699316 M * ag- the idea to emulate legacy behaviour disturbs me
1130699373 M * Bertl we already control interface visibility, yes?
1130699386 M * ag- we do
1130699387 M * Bertl we will soon have skb tagging
1130699393 M * AndrewLee Bertl: Thanks for your information, I think I know how to make the guest's routing table as what I want. :)
1130699403 M * Bertl AndrewLee: you're welcome!
1130699441 A * ag- has a SIGFOOD now, be back in an hour :)
1130699448 M * Bertl k, cya!
1130700433 J * brc bruce@200141102226.user.veloxzone.com.br
1130700511 J * hwarrier ~harikb@c-24-6-225-159.hsd1.ca.comcast.net
1130700518 Q * brc Quit:
1130700668 M * hwarrier where do I get a vserver patch corresponding to 2.6.14, the latest (as per kernel.org) kernel version? Or should I be using 2.6.12.4 (the latest I can find a patch for at linux-verser.org)?
1130700716 M * daniel_hozac http://vserver.13thfloor.at/Experimental/ has patches for 2.6.13 and 2.6.14.
1130700738 M * hwarrier thanks
1130700823 M * hwarrier daniel_hozac: will the 2.6.12.4 patch work with 2.6.12.6 (latest in .12)? I am trying to stick to something reasonably stable - since I am not very particular about a kernel version.
1130700846 M * NikDaPhreak Bertl: just found a couple of minutes to share some "external" infos on virtuozzo networking virtualizations..
1130700888 M * daniel_hozac hwarrier: it should. 2.6.13-vs2.0.1-pre2 is stable though.
1130700890 M * NikDaPhreak Bertl: one gets a completely virtual interface, which gets routed via the ethX
1130700969 M * Bertl NikDaPhreak: please elaborate ...
1130701044 M * NikDaPhreak Bertl: i do not have access to the sources, but a setup on a virtuozzo vserver looks like this:
1130701066 M * Bertl NikDaPhreak: you have access to OVZ sources :)
1130701110 M * NikDaPhreak Bertl onestly i doubt they publisched everyting... I could ask someone to compare them for me ;-)
1130701174 M * NikDaPhreak Bertl: internally in the vserver you get a venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 for loopback and a venet0:0 for the IP
1130701216 M * Bertl NikDaPhreak: well, they say they did, but a comparison would be appreciated :)
1130701289 Q * hwarrier Quit:
1130701408 M * NikDaPhreak Bertl: well..
1130701469 M * NikDaPhreak Bertl: on the host you have the same venet0 with no IP
1130701496 M * Bertl hmm, okay, no ip? how do you route it?
1130701717 M * NikDaPhreak Bertl: IP dev venet0 scope link src ethIP
1130701748 M * NikDaPhreak Bertl: where IP is the ip of the vserver and ethIP is the IP of the host on a real ethernet
1130701776 M * Bertl pardon?
1130701829 M * NikDaPhreak Bertl: sec.. phone
1130702537 M * NikDaPhreak Bertl: ip r l shows the routing to/from the vservers in that way
1130702574 M * NikDaPhreak Bertl: I also find it kind of funny, but it works
1130703216 M * Bertl okay, so they 'basically' use something like the 'original' ngnet concept
1130703651 M * FaUl Bertl: i'm not quite sure if i understand the new concept
1130703665 M * FaUl Bertl: what does "multihomed interfaces" mean?
1130703690 M * Bertl FaUl: you know how the loopback device works?
1130703707 M * NikDaPhreak Bertl: yes, quite the same
1130703743 J * mrec ~revenger@p54B01D6F.dip0.t-ipconnect.de
1130703755 M * FaUl Bertl: from the userspace, yes. is there something special in kernelspace?
1130703758 M * Bertl welcome mrec!
1130703794 M * FaUl i guess its just like two fifos or something
1130703884 M * Bertl FaUl: well, have a look at drivers/net/loopback.c
1130703923 M * FaUl ok :-)
1130704164 Q * mrec_ Ping timeout: 480 seconds
1130704248 M * Bertl FaUl: let me know when you figured how it works ...
1130704722 M * FaUl ok
1130705155 J * Sonarman_ ~cleetus@adsl-71-141-127-16.dsl.snfc21.pacbell.net
1130705489 Q * Sonarman Ping timeout: 480 seconds
1130705527 J * Sonarman ~cleetus@adsl-71-141-127-16.dsl.snfc21.pacbell.net
1130705669 Q * Sonarman_ Ping timeout: 480 seconds
1130706458 M * FaUl Bertl: If I understand the code right it basically recives the stuff, copys it into a new skb (why?) and injectes it back via netif_rx to the network-stack
1130706490 M * FaUl and it fragmentes the packet if its larger then mtu
1130706642 M * FaUl ah, no
1130706856 M * mrec hey Bertl :)
1130707057 M * FaUl Bertl: what exactly is tso_segs/tso_size in skb?
1130707101 M * Bertl tcp segmentation offload
1130707113 M * FaUl which means?
1130707124 M * Bertl basically hardware support for fragmentation
1130707138 M * FaUl uhm
1130707145 M * Bertl now, you figured how lo works
1130707158 M * FaUl no :-)
1130707171 M * Bertl the essential part yes, now imagine a loopback device
1130707188 M * FaUl i wonder whether hardware-support for fragmentation is a thing in a loopback-device
1130707192 M * FaUl i'm totally confused
1130707216 M * Bertl which receives a packet from context A
1130707228 M * FaUl just go on :-)
1130707269 M * FaUl ah, i guess i understand.
1130707296 M * Bertl an changes the context tagging on the fly
1130707299 M * FaUl the new ngnet is based on loopback-devices which basically are a gateway between guest and host
1130707308 Q * yarihm Quit: Leaving
1130707352 M * FaUl ok, that should be no problem while this is just one thing more before netif_rx, should it?
1130707430 M * FaUl s/while/as/
1130707483 M * FaUl Bertl: have i missed the thing totally? :-)
1130707494 M * Bertl no, ...
1130707517 M * Bertl the ide is, to have 'devices' which are present in more than one context
1130707521 M * Bertl *idea
1130707562 M * FaUl for inter-guest-communication?
1130707568 M * Bertl for example ...
1130707579 M * Bertl but keep in mind, the host has xid=0
1130707589 M * Bertl (which is _also_ some kind of context
1130707851 M * FaUl hmm, i'm not quite sure what the point is
1130707884 M * Bertl the point is, that you now should know _why_ we want dula/multi homed network devices :)
1130707899 M * Bertl (and what they do, of course )
1130708110 M * FaUl hmm, my girlfriend want to go to bed, i'll try to get this tomorrow
1130708123 M * Bertl k, night!
1130708163 M * FaUl and if i'll get it, i'll write a article in the wiki :-)
1130708172 M * Bertl excellent!
1130708181 M * FaUl :-)
1130708182 M * FaUl night
1130708317 M * ag- Bertl: so you were at "what would be required to 'emulate' legacy networking?"...
1130708468 M * ag- having thought about it, i would say nothing indeed, because we can still keep the real interface, can't we?
1130708518 M * ag- maybe i miss something technical in the kernel which would prevent us from doing so
1130708645 M * ag- so when i look at what is done in net/core/* about VXF_HIDE_NETIF test cases, i would say we need to check whether we have a real interface or a virtual interface
1130708671 M * ag- in each case, we do the proper interface hiding:
1130708672 J * prae ~benjamin@sherpadown.net
1130708680 M * ag- * the actual for the real one
1130708703 M * ag- * a new kind of hiding for the virtual interface
1130709241 M * ag- the real interface might belong to any context as it's done in the actual code
1130709831 Q * Bertl Ping timeout: 480 seconds
1130710137 Q * monrad Quit: Leaving
1130710922 J * Bertl herbert@212.16.62.52
1130710958 M * Bertl okay, what did I miss?
1130710998 M * Bertl ag-: ah, yes, actually we can emulate it by doing:
1130711017 M * Bertl - conditional checks regarding visibility
1130711041 M * Bertl - context/skb tagging with xid 0/1
1130711116 M * ag- Bertl: if the last thing you saw was "(22:54:01)< ag-> the real interface might belong to any context as it's done in the actual code", you missed nothing
1130711172 M * Bertl okay, great!
1130711194 M * Bertl so, we do the following:
1130711204 M * Bertl - abstract the visibility clause
1130711216 M * Bertl - allow for conditional' xid tagging
1130711230 M * Bertl does that sound reasonable/doable?
1130711423 M * ag- yep, it sounds to me
1130711466 M * Bertl okay, let's do a 'test' implementation with the visibility stuff first, yes?
1130711492 M * wally uhm - dumb question here :) - why don't you have a look at the openvz patch to see how virtuozzo is doing their networking?
1130711496 J * lilo__ ~lilo@tor-irc.dnsbl.oftc.net
1130711503 M * wally (sorry I've been reading history now)
1130711517 M * ag- Bertl: we need a dummy interface for that :)
1130711570 Q * lilo_ Remote host closed the connection
1130711593 M * ag- wally: it seems they use the same kind as ngnet-testing
1130711597 M * Bertl wally: simple, because we want to have a really good and smart solution .. not just some solution :)
1130712077 M * Bertl ag-: dummy interface?
1130712085 M * Bertl ah, you mean for testing?
1130712116 M * Bertl well, I guess we need a test syscall command to change the tagging for an interface ...
1130712209 M * ag- yup, for testing
1130712282 M * Bertl http://linux-vserver.org/Syscall+Switch+Info
1130712300 M * Bertl we add 61,3 for xid tagging of device interfaces :)
1130712368 J * Aiken ~james@tooax6-130.dialup.optusnet.com.au
1130712379 M * Bertl welcome Aiken!
1130712396 M * Aiken hello
1130712505 M * Aiken noticed on the mailing list there is effort going into a 2.6.14 patch, how is that going?
1130712523 M * Aiken when I tried I had problems, there was too much code I was not sure about :(
1130712536 M * Bertl port is basically done
1130712556 M * Aiken cool
1130712563 M * ag- it works for me (tm)
1130712595 M * Aiken I got side tracked by vmplayer
1130712602 M * Bertl spent some time cleaning up 2.0.1 and providing a broken down version
1130712627 M * Bertl http://vserver.13thfloor.at/Experimental/del-vs2.0.1-pre3/
1130712652 M * ag- Bertl: cool!
1130712665 M * Bertl ag-: this might be also interesting for the next steps (regarding ngnet) as we can easily identify places
1130712666 M * Aiken I don't think I ever tried 2.0.1, I went straight from 2.0 to 2.1.0-preX
1130712682 M * Bertl http://vserver.13thfloor.at/Experimental/patch-2.6.14-vs2.1.0-rc5-prelim.diff.bz2
1130712770 M * Aiken grabbing that, I'll fire up the alpha this morning
1130712792 M * Bertl ag-: okay, so do you want to do the abstraction? or would you prefer to work on the syscall comand for testing?
1130712810 M * Bertl (which might actually be a little easier)
1130712826 M * ag- i'm going for the syscall command :)
1130712844 M * Bertl okay, here are the details:
1130712855 M * Bertl (i.e. your mission:)
1130712888 M * Bertl - figure a way to specify an interface (common namespace for now, separate namespaces later)
1130712926 M * Bertl - design the command arguments, according to the linux-vserver syscall commands ... (check inode/uts stuff)
1130712966 M * Bertl - implement and test the syscall command
1130712974 M * Bertl that's it :)
1130713036 M * ag- ok :)
1130713053 M * Bertl if you have any questions, dont hesitate to ask/discuss them
1130713068 M * Bertl same goes for design decisions ...
1130713079 M * ag- np, sure
1130713111 J * jayeola ~jayeola@host-87-74-35-175.bulldogdsl.com
1130713128 M * Bertl welcome jayeola!
1130713143 M * jayeola :-)
1130713196 M * jayeola um, when you're creating a vserver with a debootstrap, how do i specify the latest "debootstrap" tool?
1130713225 M * Bertl good question, I assume either with a speical option, or by simply installing it?
1130713244 M * Bertl btw, you might check out 0.30.209 :)
1130713267 M * jayeola um, i've been thrown by that a couple of times /me looks at the source code
1130713324 M * jayeola mind if i flood a couple of lines from util-vserver-0.30.208/README ?
1130713332 A * ag- gets SIGSLEEP by now... c'ya ;)
1130713353 M * jayeola Since it is updated very often, it can happen
1130713354 M * jayeola that a '404 Not found' error occurs; in this case look either
1130713355 M * Bertl ag-: night then :)
1130713355 M * jayeola for a newer util-vserver package, or configure the new URI e.g. with
1130713397 M * jayeola does that mean that i d/load the source for debootstrap?
1130713871 M * jayeola just grokked the README
1130714370 M * Greek0 Bertl: ping?
1130714411 M * Bertl Greek0: pong!
1130714445 M * Greek0 what did you want to tell me about my patch earlier today?
1130714519 M * Bertl hmm, if I just could remember ...
1130714537 M * Bertl anyway, it was nice to have it, to figure differences
1130714576 M * Greek0 fine :)
1130714596 M * Bertl you might want to look at the broken down version of 2.0.1 :)
1130714672 M * Greek0 will do, however I'm going to bed for now
1130714674 M * Greek0 good night
1130714683 M * Bertl good night then!
1130715430 Q * prae Quit: Pwet
1130716006 Q * jayeola Quit: leaving
1130716035 J * jayeola ~jayeola@host-87-74-35-175.bulldogdsl.com
1130716623 J * ntrs ~ntrs@68-188-50-87.dhcp.stls.mo.charter.com