From bzeeb-lists at lists.zabbadoz.net Mon Dec 1 01:45:09 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Dec 1 01:45:21 2008 Subject: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD Message-ID: <20081201085229.D80401@maildrop.int.zabbadoz.net> Hi, as you may have already noticed multi-IPv4/v6/no-IP jails have hit HEAD. See commit message attached. The bad news first: expect an update on the rc script to make the more obscure rc features like configuring IPs on interfaces when starting jails and giving a possible netmask work with multiple IPs and IPv6. The good news: In case you do not use those features or still only use one IP per jail everything should just work fine and there are no changes needed. More news: In case you want to use multiple IPs or a mix of v4 and v6 addresses you just give them as a comma separated list on both the command line or in rc.conf like: jail / example 192.0.2.250,2001:db8::75,2001:db8::99,2001:db8::55,2001:db8::14,192.0.2.254 /bin/sh or: jail_example_ip="192.0.2.2,2001:db8::2,2001:db8::1,2001:db8::4,2001:db8::13,192.0.2.3" In case you do want to start a jail without any IP, give an empty argument on command line: jail / noip.example.net "" /bin/sh Additionally you can give a jail a name now using the -n option: jail -n "bz's private noip jail" / noip.example.net "" /bin/sh You may not want to use special characters or whitespace but it is just a string, so you can. There are no restrictions and even 10 jails could have the same name. The jail (inside) cannot change the name. It's set upon jail creation and unchangeable from then on. What else is new: the -h option to jail makes it resolve the hostname to IP addresses and will merge those to the jail IPs. Note: that this can give you unexpected results on the primary jail IP. See jail(8) for more information. jls tries to be as backward compatible as possible. That means it will only show one IPv4 if called as `jls`; obviously this won't work well for no-IP or IPv6-only jails. This was done to try to not confuse scripts people have in their classic setups. jls -v will give you the full information, including: - state: usually ACTIVE. - in case you also give '-a' you will also see jails in other states, for example jails hanging around waiting for a socket to timeout but with no processes left after it was stopped; it will say DYING. - Every jail gets its own cpuset inherited from the process that started the jail. You can list, etc the mask by jail id: cpuset -g -j 8 or by set id: cpuset -g -s 5 Or even change it if you want. Threads within jails should be able to further restrict themselves even within the jail but nothing outside their scope. See the cpuset manpages for further information. The IPs will be listed in the following order: the primary IP per AF which is the first IP of that AF given to the jail command and then they should be sorted in ascending order. jexec now takes the optional jail name to attach to a jail but will refuse to do anything if the jail cannot be uniquely identifed. In case you use the jail name you have to give an empty argument for the jail id like: jexec -n "bz's private noip jail" "" /bin/sh You can also give both jail name and jail ID and both will have to match, else it will complain. Obviously only giving the jail id still works. The -h hostname option is gone again. You should use the jail name for management purposes now. A sample full jls output (admittedly a bit ugly this way): sun$ jls -av JID Hostname Path Name State CPUSetID IP Address(es) 21 sun / hangtest DYING 6 192.0.2.99 8 noip.example.net / bz's private noip jail ALIVE 5 3 j3.sunny.example.net /local/jails/j1 ALIVE 4 2001:db8::5 2 j2.sunny.example.net /local/jails/j1 ALIVE 3 192.0.2.1 1 j1.sunny.example.net /local/jails/j1 ALIVE 2 192.0.2.2 192.0.2.3 2001:db8::2 2001:db8::1 2001:db8::4 2001:db8::13 In case you have more questions the man pages do not address, or problem, etc. please follow-up to freebsd-jail@ . Regards, Bjoern PS: the MFC question was answered in the commit message so do not ask. -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ---------- Forwarded message ---------- Date: Sat, 29 Nov 2008 14:32:14 +0000 (UTC) Subject: svn commit: r185435 - in head: lib/libc/sys lib/libkvm share/man/man4 sys/compat/freebsd32 sys/kern sys/net sys/netinet sys/netinet6 sys/security/mac_bsdextended sys/sys usr.bin/cpuset usr.sbin/jai... Author: bz Date: Sat Nov 29 14:32:14 2008 New Revision: 185435 URL: http://svn.freebsd.org/changeset/base/185435 Log: MFp4: Bring in updated jail support from bz_jail branch. This enhances the current jail implementation to permit multiple addresses per jail. In addtion to IPv4, IPv6 is supported as well. Due to updated checks it is even possible to have jails without an IP address at all, which basically gives one a chroot with restricted process view, no networking,.. SCTP support was updated and supports IPv6 in jails as well. Cpuset support permits jails to be bound to specific processor sets after creation. Jails can have an unrestricted (no duplicate protection, etc.) name in addition to the hostname. The jail name cannot be changed from within a jail and is considered to be used for management purposes or as audit-token in the future. DDB 'show jails' command was added to aid debugging. Proper compat support permits 32bit jail binaries to be used on 64bit systems to manage jails. Also backward compatibility was preserved where possible: for jail v1 syscalls, as well as with user space management utilities. Both jail as well as prison version were updated for the new features. A gap was intentionally left as the intermediate versions had been used by various patches floating around the last years. Bump __FreeBSD_version for the afore mentioned and in kernel changes. Special thanks to: - Pawel Jakub Dawidek (pjd) for his multi-IPv4 patches and Olivier Houchard (cognet) for initial single-IPv6 patches. - Jeff Roberson (jeff) and Randall Stewart (rrs) for their help, ideas and review on cpuset and SCTP support. - Robert Watson (rwatson) for lots and lots of help, discussions, suggestions and review of most of the patch at various stages. - John Baldwin (jhb) for his help. - Simon L. Nielsen (simon) as early adopter testing changes on cluster machines as well as all the testers and people who provided feedback the last months on freebsd-jail and other channels. - My employer, CK Software GmbH, for the support so I could work on this. Reviewed by: (see above) MFC after: 3 months (this is just so that I get the mail) X-MFC Before: 7.2-RELEASE if possible From Alexander at Leidinger.net Mon Dec 1 03:46:49 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Mon Dec 1 03:53:43 2008 Subject: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD In-Reply-To: <20081201085229.D80401@maildrop.int.zabbadoz.net> References: <20081201085229.D80401@maildrop.int.zabbadoz.net> Message-ID: <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> Quoting "Bjoern A. Zeeb" (from Mon, 1 Dec 2008 09:41:46 +0000 (UTC)): > Hi, > > as you may have already noticed multi-IPv4/v6/no-IP jails have hit > HEAD. See commit message attached. Will this introduce changes how multicast is handled in jails, or is it the same behavior as before (whatever the previous behavior was). > Additionally you can give a jail a name now using the -n option: > jail -n "bz's private noip jail" / noip.example.net "" /bin/sh > You may not want to use special characters or whitespace but it is > just a string, so you can. There are no restrictions and even 10 jails > could have the same name. The jail (inside) cannot change the name. > It's set upon jail creation and unchangeable from then on. Is this private name visible inside the jail (I don't need this feature, so I don't care, but people should know so that they don't put offensive stuff there in case it is visible inside)? Bye, Alexander. -- Since we cannot hope for order, let us withdraw with style from the chaos. -- Tom Stoppard http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From alexus at gmail.com Tue Dec 2 18:30:08 2008 From: alexus at gmail.com (alexus) Date: Wed Dec 3 00:14:05 2008 Subject: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD In-Reply-To: <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> Message-ID: <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> as far as I understood HEAD is 8.0-CURRENT is there a way for us to start using it before 8.0 hits -RELEASE which according to freebsd.org will be in june 2009, which we all know how accured their schedule is, so, my guess is very well Q4 of 2009 (if we lucky), I somehow was under impression (and i guess i was wrong) that it will come out in 7.1, I have a server that needs to be migrated and really doing so without multi ip patch will be a really big ......... -- http://alexus.org/ From bseklecki at collaborativefusion.com Fri Dec 5 05:52:58 2008 From: bseklecki at collaborativefusion.com (Brian A. Seklecki) Date: Fri Dec 5 06:12:15 2008 Subject: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD In-Reply-To: <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> Message-ID: <1228483574.2805.499.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> On Tue, 2008-12-02 at 21:00 -0500, alexus wrote: > as far as I understood HEAD is 8.0-CURRENT The trick is to bribe the right people to get it RFP'd into 7.2R. :) ~BAS -- Brian A. Seklecki Collaborative Fusion, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-virtualization/attachments/20081205/a9c314bf/attachment.pgp From des at des.no Fri Dec 5 12:04:56 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri Dec 5 12:05:02 2008 Subject: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD In-Reply-To: <1228483574.2805.499.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> (Brian A. Seklecki's message of "Fri, 05 Dec 2008 13:26:14 +0000") References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> <1228483574.2805.499.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> Message-ID: <86skp2l804.fsf@ds4.des.no> "Brian A. Seklecki" writes: > alexus writes: > > as far as I understood HEAD is 8.0-CURRENT > The trick is to bribe the right people to get it RFP'd into 7.2R. :) The question is, does it change existing behavior, or just add new functionality? If the former, it should not be MFCed. DES -- Dag-Erling Sm?rgrav - des@des.no From bseklecki at collaborativefusion.com Fri Dec 5 12:05:31 2008 From: bseklecki at collaborativefusion.com (Brian A. Seklecki) Date: Fri Dec 5 15:12:00 2008 Subject: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD In-Reply-To: <86skp2l804.fsf@ds4.des.no> References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> <1228483574.2805.499.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <86skp2l804.fsf@ds4.des.no> Message-ID: <1228507529.2805.539.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> On Fri, 2008-12-05 at 20:47 +0100, Dag-Erling Sm?rgrav wrote: > The question is, does it change existing behavior, or just add new > functionality? The syntax semantics should be backward compatible, so likely the latter. -- Brian A. Seklecki Collaborative Fusion, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-virtualization/attachments/20081205/b837c09e/attachment.pgp From ivoras at freebsd.org Mon Dec 8 12:13:16 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Dec 8 12:13:27 2008 Subject: Exposing VM detection as sysctl Message-ID: Moving discussion from src-committers (<9bbcef730812081122r2b1fb938s6201aeee7756b884@mail.gmail.com>): Any objections to the patch: http://people.freebsd.org/~ivoras/diffs/subr_param.c.diff.txt ? (Of course, for symmetry, if we ever support any hosting for full virtualization or even for our monsters like vimage, another sysctl might be introduced as a bitmap that describes VM hosting abilities). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-virtualization/attachments/20081208/4b273364/signature.pgp From duerrm at gmail.com Tue Dec 9 06:07:43 2008 From: duerrm at gmail.com (=?ISO-8859-1?Q?michael_d=FCrr?=) Date: Tue Dec 9 06:07:50 2008 Subject: Howto setup virtualisation Message-ID: Hallo list, I recently discovered the IMUNES toolkit and found me more than fascinated by its functionallity. Now I'd love to deploy the most recent version of vimage. I already came accross Marko's website (http://imunes.tel.fer.hr/virtnet/). As I don't want to use the VMware images, but install everything native, I set up a FreeBSD 7.0 system and tried to compile against the provided snapshots. As you can imagine, my build failed :-( . Although I'm not that familiar with FreeBSD, I tried hard to compile the snapshots (as well as the provided patch) against different tags... Without success. My question: Can you tell me a release/tag which I can download from the src tree which comliles and for which I can use the GUI tools? Or is there any other simple solution to get all this running? Thank you! Michael From zec at icir.org Tue Dec 9 08:06:19 2008 From: zec at icir.org (Marko Zec) Date: Tue Dec 9 08:06:26 2008 Subject: Howto setup virtualisation In-Reply-To: References: Message-ID: <200812091644.53757.zec@icir.org> On Tuesday 09 December 2008 14:47:00 michael d?rr wrote: > Hallo list, > > I recently discovered the IMUNES toolkit and found me more than > fascinated by its functionallity. > > Now I'd love to deploy the most recent version of vimage. I already > came accross Marko's website (http://imunes.tel.fer.hr/virtnet/). As > I don't want to use the VMware images, but install everything native, > I set up a FreeBSD 7.0 system and tried to compile against the > provided snapshots. > > As you can imagine, my build failed :-( . Although I'm not that > familiar with FreeBSD, I tried hard to compile the snapshots (as well > as the provided patch) against different tags... Without success. > > My question: > > Can you tell me a release/tag which I can download from the src tree > which comliles and for which I can use the GUI tools? Or is there any > other simple solution to get all this running? Hi, builing and running http://imunes.net/virtnet/vimage_7-20081015.tgz on a 7.0-RELEASE or 7.1-PRERELEASE should be pretty straightforward: just unpack the vimage_7 src tree; cd src/sys/i386/conf; config VIMAGE; cd ../compile/VIMAGE; make depend; make; make install and you're done. You'll also need to compile the vimage(8) utility -> cd src/usr.sbin/vimage; make; make install -> done. You'll most probably want to upgrade your userland from 7.0-RELEASE to RELENG_7 or RELENG_7_1 in order for the utilities like sockstat and netstat to work properly - the simpler alternative would be doing the installation from a recent 7.x snapshot ISO... For the GUI, the latest version can be fetched from anoncvs: cvs -d :pserver:anonymous@cvs.imunes.net:/usr/local/src/cvsroot co imunes cd imunes; ./install.sh -> done Note that you need to have tk-8.4 installed for the GUI to work, and most probably you'll want quagga and or xorp as well (from ports). Good luck, Marko From julian at elischer.org Tue Dec 9 12:17:33 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Dec 9 12:17:40 2008 Subject: PERFORCE change 154309 for review (etc.) In-Reply-To: <200812080223.mB82N6iZ019068@repoman.freebsd.org> References: <200812080223.mB82N6iZ019068@repoman.freebsd.org> Message-ID: <493ECBAA.9030400@elischer.org> Marko, I'm following along using p4 and the diff script. It looks good.. If it all seems to be working we should commit what you have and then we should get Kris and Robert to try some of their benchmarks.. to confirm the numbers you saw earlier. Kris, the change that is upcoming for the next vimage commit gathers the various networking globals in the system and aggregates them together into several functional structures. e.g. one for inet related vars and another for interface and basic networking infrastructure related vars. The thing we would like "independent" corroboration of is that the change to having these gathered together, and initialized by an explicit initialization routing does not give any significant performance difference for a representative set of networking tests. Kris and Robert, what tests would you suggest and is there a chance that we can get some "independent" testing done on this? From zec at freebsd.org Tue Dec 9 16:13:49 2008 From: zec at freebsd.org (Marko Zec) Date: Tue Dec 9 16:13:55 2008 Subject: PERFORCE change 154309 for review (etc.) In-Reply-To: <493ECBAA.9030400@elischer.org> References: <200812080223.mB82N6iZ019068@repoman.freebsd.org> <493ECBAA.9030400@elischer.org> Message-ID: <200812100049.57456.zec@freebsd.org> On Tuesday 09 December 2008 20:48:58 Julian Elischer wrote: > Marko, > > I'm following along using p4 and the diff script. It looks good.. The code in vimage-commit2 passed through a make universe run, though a new panic just emerged in head related to kmacy's changes to routing tbale locking. I feel somewhat reluctant to dump commit2 to svn while there's an unrelated but known panic that doesn't allow the system to boot, and furthermore bz and I wanted to double-check that all sysctls would still work exactly the same way before and after the change - a few days ago I noticed something strange but want to check it with the most recent head... > If it all seems to be working we should commit what you have > and then we should get Kris and Robert to try some of their > benchmarks.. to confirm the numbers you saw earlier. Yes it would be extremely usefull to have people doing unbiased tests of all kinds, though I think that the right time to commence testing would be in a week or two from now when we'll have all three different variable layout and referencing models in place in head, selectable as compile time option, as outlined at the bottom of bz's wiki page: http://wiki.freebsd.org/Image/KernelOptions Marko > Kris, the change that is upcoming for the next vimage commit > gathers the various networking globals in the system and > aggregates them together into several functional structures. > > e.g. one for inet related vars and another for interface and basic > networking infrastructure related vars. > > The thing we would like "independent" corroboration of is that > the change to having these gathered together, and initialized by > an explicit initialization routing does not give any significant > performance difference for a representative set of networking > tests. > > Kris and Robert, what tests would you suggest and is there a chance > that we can get some "independent" testing done on this? From des at des.no Thu Dec 11 14:32:54 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Dec 11 14:33:05 2008 Subject: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD In-Reply-To: <49418BD9.8080105@h3q.com> (Philipp Wuensche's message of "Thu, 11 Dec 2008 22:53:29 +0100") References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> <1228483574.2805.499.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <86skp2l804.fsf@ds4.des.no> <1228507529.2805.539.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <49418BD9.8080105@h3q.com> Message-ID: <867i66s5pn.fsf@ds4.des.no> Philipp Wuensche writes: > Not entirely true, the jls output is totaly different than before and > breaks third-party applications like jailaudit and ezjail. > > It is uneasy to parse too. jls | tail +3 | while read line ; do set $line if [ $# = 3 ] ; then echo "jail $1 (name $2 root $3) IPs:" elif [ $# = 1 ] ; then echo " $1" else echo "huh?" fi done DES -- Dag-Erling Sm?rgrav - des@des.no From cryx-freebsd at h3q.com Thu Dec 11 14:20:12 2008 From: cryx-freebsd at h3q.com (Philipp Wuensche) Date: Thu Dec 11 14:49:49 2008 Subject: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD In-Reply-To: <1228507529.2805.539.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> <1228483574.2805.499.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <86skp2l804.fsf@ds4.des.no> <1228507529.2805.539.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> Message-ID: <49418BD9.8080105@h3q.com> Brian A. Seklecki wrote: > On Fri, 2008-12-05 at 20:47 +0100, Dag-Erling Sm?rgrav wrote: >> The question is, does it change existing behavior, or just add new >> functionality? > > The syntax semantics should be backward compatible, so likely the > latter. Not entirely true, the jls output is totaly different than before and breaks third-party applications like jailaudit and ezjail. It is uneasy to parse too. greetings, Philipp From antipsychic at gmail.com Thu Dec 11 19:23:00 2008 From: antipsychic at gmail.com (Jake Thalacker) Date: Thu Dec 11 19:23:06 2008 Subject: SMP refcount_release panic Message-ID: Sorry, this is overdue on being reported. I've encountered a panic with VIMAGE from a patched build of current from around mid September. I tracked the problem to the second call to refcount_release in kern_vimage.c:vi_td_ioctl(). Just for clarity I determined this by making 3 refcount_release functions to replace the calls including the one in kern_prot.c:crfree(). I noted that throughout the kernel code prior to all kern_prot.c:crcopy() calls there is a PROC_LOCK and proceeded by a PROC_UNLOCK afterward. I found that there was one occurrence where this was missing in netncp/ ncp_comm.c:ncp_conn_alloc(). I added it and that did not resolve the panic but figured it's still probably needed. It's probably poor form but I ended up commenting out the second call and have had no panics since, had to move on at that point. The panic is very reproducible with the following script on an SMP system. I have not observed any panics on non-SMP systems. _vimage="rc-panic-$$" vimage -c ${_vimage} _cnt=0 _fw=1 _loopcount=64 while [ ${_cnt} -lt ${_loopcount} ]; do vimage ${_vimage} sysctl net.inet.ip.forwarding=${_fw} if [ ${_fw} -eq 1 ]; then _fw=0 else _fw=1 fi _cnt=$(expr ${_cnt} '+' 1) done If there's any further information I can provide just let me know, or any testing of new code I'd gladly help out. Thanks for all your efforts! Jake From bz at FreeBSD.org Sat Dec 13 11:54:12 2008 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Sat Dec 13 11:54:25 2008 Subject: HEADS UP: vimage - virtualized global variables in the network stack In-Reply-To: <200812131913.mBDJD38C037353@svn.freebsd.org> References: <200812131913.mBDJD38C037353@svn.freebsd.org> Message-ID: <20081213191345.M97918@maildrop.int.zabbadoz.net> On Sat, 13 Dec 2008, Bjoern A. Zeeb wrote: Hi, > Author: bz > Date: Sat Dec 13 19:13:03 2008 > New Revision: 186048 > URL: http://svn.freebsd.org/changeset/base/186048 > > Log: > Second round of putting global variables, which were virtualized > but formerly missed under VIMAGE_GLOBAL. > > Put the extern declarations of the virtualized globals > under VIMAGE_GLOBAL as the globals themsevles are already. > This will help by the time when we are going to remove the globals > entirely. As some of you might have noticed that Marko's last commit for the first time in the series of vimage commits was an actual functional change. By default HEAD is no longer using the globals. With my commit the current set of virtualized variables is assumed to be "clean". This basically means three things: 1) The former globals and their externs are all under #ifdef VIMAGE_GLOBALS 2) The same variables are present in a 'container struct' 3) The initialization of those is done from 'constructor ("init") functions' This state of having the variables in parallel, global and in the container struct, will be maintained for another (short) time until the entire virtualization framework is in. This is needed, so that all three possible states can be benchmarked from exactly the same code changeset. For developers comitting new code or changing code it is important to properly add virtualized variables in the way that: 1) the globals and externs (if needed) are added/kept in sync as both a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate container struct + the V_ macro. When used somewhere in code one has to use the V_foobarbaz version. 2) Any new virtualized globals must not be directly initialized. They have to be initialized from a contructor function (which is usually there already). If you are confused about some of the terms etc. follow the links in the "Some documentation" section on the wiki: http://wiki.freebsd.org/Image The "Vimage Coding - beginners guide / FAQ" tries to answer the 101 questions. For the beaf you'll find the link to a document in perforce with the last question (that you may already know). We'll try to enhance this as we get questions or the integration goes on. In case of questions or suggestions ideally follow-up on freebsd-virtualization@ . /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From max at love2party.net Sat Dec 13 11:57:54 2008 From: max at love2party.net (Max Laier) Date: Sat Dec 13 12:08:07 2008 Subject: HEADS UP: vimage - virtualized global variables in the network stack In-Reply-To: <20081213191345.M97918@maildrop.int.zabbadoz.net> References: <200812131913.mBDJD38C037353@svn.freebsd.org> <20081213191345.M97918@maildrop.int.zabbadoz.net> Message-ID: <200812132045.17207.max@love2party.net> On Saturday 13 December 2008 20:33:53 Bjoern A. Zeeb wrote: ... > This state of having the variables in parallel, global and in the > container struct, will be maintained for another (short) time until > the entire virtualization framework is in. This is needed, so that > all three possible states can be benchmarked from exactly the same > code changeset. > > > For developers comitting new code or changing code it is important to > properly add virtualized variables in the way that: > 1) the globals and externs (if needed) are added/kept in sync as both > a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate > container struct + the V_ macro. > When used somewhere in code one has to use the V_foobarbaz version. Is there (an easy) way to have the tinderbox build every other run without VIMAGE_GLOBALS so that the most obvious error (global available, but not in the container struct - or the other way around) can be warned about? -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From bz at FreeBSD.org Sat Dec 13 12:10:07 2008 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Sat Dec 13 12:10:14 2008 Subject: HEADS UP: vimage - virtualized global variables in the network stack In-Reply-To: <200812132045.17207.max@love2party.net> References: <200812131913.mBDJD38C037353@svn.freebsd.org> <20081213191345.M97918@maildrop.int.zabbadoz.net> <200812132045.17207.max@love2party.net> Message-ID: <20081213195343.V97918@maildrop.int.zabbadoz.net> On Sat, 13 Dec 2008, Max Laier wrote: > On Saturday 13 December 2008 20:33:53 Bjoern A. Zeeb wrote: > ... >> This state of having the variables in parallel, global and in the >> container struct, will be maintained for another (short) time until >> the entire virtualization framework is in. This is needed, so that >> all three possible states can be benchmarked from exactly the same >> code changeset. >> >> >> For developers comitting new code or changing code it is important to >> properly add virtualized variables in the way that: >> 1) the globals and externs (if needed) are added/kept in sync as both >> a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate >> container struct + the V_ macro. >> When used somewhere in code one has to use the V_foobarbaz version. > > Is there (an easy) way to have the tinderbox build every other run without > VIMAGE_GLOBALS so that the most obvious error (global available, but not in > the container struct - or the other way around) can be warned about? Without VIMAGE_GLOBALS is the default; we have been building this for a few days already. The flip had been so smoothly that almost noone had really noticed. Marko has done a really great job! Thus my HEADS UP now after I am confident enough that (almost) all places were caught and clean. In case you want to check yourself you can simply put a file into one or multiple archs conf dir that looks like: ------------------------------------------------------------------------ > cat sys/amd64/conf/LINT-VIMAGE_GLOBALS include LINT ident LINT-VIMAGE_GLOBALS options VIMAGE_GLOBALS ------------------------------------------------------------------------ I am doing that build every other day from now to catch the possible error of a virtualized variable in the container struct w/o the global. But as this is the least problematic case I do not want to commit the kernel configuration as it'll make builds longer for everyone, etc. The more problematic cases that builds cannot catch are: - static initialization of a virtualized 'global'. - a newly added virtualized 'global' that is not under #ifdef VIMAGE_GLOBALS I have scripts to identify the latter already. The former will only be caught be either code inspection or "unexpected results" when running. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From imp at bsdimp.com Sat Dec 13 12:27:17 2008 From: imp at bsdimp.com (Warner Losh) Date: Sat Dec 13 12:31:30 2008 Subject: HEADS UP: vimage - virtualized global variables in the network stack In-Reply-To: <200812132045.17207.max@love2party.net> References: <200812131913.mBDJD38C037353@svn.freebsd.org> <20081213191345.M97918@maildrop.int.zabbadoz.net> <200812132045.17207.max@love2party.net> Message-ID: <20081213.132425.41724046.imp@bsdimp.com> From: Max Laier Subject: Re: HEADS UP: vimage - virtualized global variables in the network stack Date: Sat, 13 Dec 2008 20:45:16 +0100 > On Saturday 13 December 2008 20:33:53 Bjoern A. Zeeb wrote: > ... > > This state of having the variables in parallel, global and in the > > container struct, will be maintained for another (short) time until > > the entire virtualization framework is in. This is needed, so that > > all three possible states can be benchmarked from exactly the same > > code changeset. > > > > > > For developers comitting new code or changing code it is important to > > properly add virtualized variables in the way that: > > 1) the globals and externs (if needed) are added/kept in sync as both > > a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate > > container struct + the V_ macro. > > When used somewhere in code one has to use the V_foobarbaz version. > > Is there (an easy) way to have the tinderbox build every other run without > VIMAGE_GLOBALS so that the most obvious error (global available, but not in > the container struct - or the other way around) can be warned about? This actually points out why the 'tinderbox' name is bogus for the universe plus failure: universe builds all the kernels. Tinderbox builds LINT only. Warner From jason.fines at gmail.com Mon Dec 15 07:17:27 2008 From: jason.fines at gmail.com (Jason Fines) Date: Mon Dec 15 07:17:34 2008 Subject: Question About TCP Reassembly Inside VImages In-Reply-To: References: Message-ID: <5e6025b70812150717h500ab3c4tb1319dee1572f711@mail.gmail.com> Hi Jorge, Sorry about the delay in my response. I have also been able to set maxqlen, but have been unsuccessful in setting maxsegments. I just recently tried upgrading to 7_RELENG with the vimage package http://imunes.tel.fer.hr/virtnet/vimage_7-20081015.tgz however I am still experiencing the same problems. I even went so far as to set the variable 'V_tcp_reass_maxseg' explicitly to 4096 on lines 111, and 122 of tcp_reass.c in the kernel source code, however, the maxsegments sysctl variable is still zero in my vimages!!! Have you tried anything else? I am also prohibited from using this amazing technology because of this issue. Does anyone else have any information about this? Marko, would upgrading FreeBSD 8.0 make any difference? Any help would be greatly appreciated. Thanks, Jason On Thu, Nov 27, 2008 at 11:57 AM, Jorge Sanchez wrote: > > > > > Hola Jason, > > I also observed a similar phenomenon on my system's vimages. I have several > thousands dropped packets due to "insufficient memory" (the counter you > mention in netstat -m for me is also incremented in the > net.inet.tcp.reass.overflows read-only sysctl variable) and I routinely have > TCP connections dropped within vimages because of it. I think that the TCP > packet reassembly queue length is essentially zero once options VIMAGE is > enabled... which would explain my problems when trying to contact hosts that > are on flaky links or are situated very far away hop-wise. > > I think there is something very wrong with the TCP reassembly when options > VIMAGE is enabled. Did you try increasing the net.inet.reass.maxqlen or > net.inet.reass.maxsegments sysctls? I was able to increase maxqlen but > maxsegments must be set in loader.conf and this value is not inherited into > any vimages I create after booting! :-( > > If you come up with a fix, I would appreciate it too since this prevents me > from performing realistic TCP testing within the virtualization framework. > > Adios! > Jorge > > > From: jason.fines@gmail.com > To: > freebsd-virtualization@freebsd.org > Subject: Re: Question About TCP Reassembly Inside VImages > Date: Sat, 22 Nov 2008 08:52:16 -0500 > Thanks Julian, > > I suspect you are correct as nmbclusters is a system wide sysctl variable > set at boot time and although V_tcp_reass_maxseg is set per vimage it is > the > result of a constant operation done on nmbclusters (nmbclusters / 16). > > What I've described is what I suspect is the root of my problem. The > manifestation of this problem is that TCP packets passing through my > vimage(s) are not reassembled when they are out of order and I get an > exceptionally high value reported by netstat -m stating that packets were > dropped due to "insufficient memory". Posts I've found on the net point to > the reassembly queue length, which in the vimages is zero for some reason. > > Perhaps this additional information will help clarify my exact problem. > > Thanks, > Jason > > On Sat, Nov 22, 2008 at 5:12 AM, Julian Elischer >wrote: > > > Jason Fines wrote: > > > >> Hello all, > >> > >> I've got a question about setting the sysctl variable > >> net.inet.tcp.reass.maxsegments to a non-zero value inside my vimages. > I'm > >> currently running the FreeBSD 7 with the VIMAGE package available at > >> http://imunes.tel.fer.hr/virtnet/vimage_7-20081015.tgz. > >> > >> My problem is with TCP reassembly support inside of the vimages, namely > >> with > >> the tcp.reass.maxsegments sysctl variable. I've tracked down where in > the > >> code the variable is set to line 122 in tcp_reass_init() of > >> netinet/tcp_reass.c: "V_tcp_reass_maxseg = nmbclusters / 16;". The line > >> clearly reads that maxsegments should be set to "nmbclusters /16", in > the > >> main OS (not in any vimage) the value is correctly set to 1/16 of what > my > >> nmbclusters sysctl variable is set to. However, inside all my vimages > >> nmbclusters is set correctly, while reass.maxsegments is incorrectly set > >> to > >> zero!!! > >> > > > > V_tcp_reass_maxseg is a macro that hides the fact that > > tcp_reass_maxseg is a PER Vimage variable. > > > > Part of the patch > > is to make some sysctls be per-vimage. I do not know exactly > > about that one.. I suspect it is actually a read-only > > whole-system value, and not per vimage. > > > > > > > > > > > >> Is it possible that nmbclusters when read on line 122 of > >> netinet/tcp_reass.c > >> is zero? Has anyone else experienced this problem? Is TCP reassembly > not > >> supported/tested inside vimages? > >> > >> Any help in this area would be greatly appreciated. > >> > >> Thanks, > >> Jason > >> > >> P.S. This technology is phenomenal, and thanks to everyone who is > involved > >> developing it. > >> _______________________________________________ > >> freebsd-virtualization at freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > >> To unsubscribe, send any mail to " > >> freebsd-virtualization-unsubscribe at freebsd.org" > >> > > > _________________________________________________________________ > > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to " > freebsd-virtualization-unsubscribe@freebsd.org" > From bseklecki at collaborativefusion.com Mon Dec 15 09:57:35 2008 From: bseklecki at collaborativefusion.com (Brian A. Seklecki) Date: Mon Dec 15 11:52:11 2008 Subject: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD In-Reply-To: <49418BD9.8080105@h3q.com> References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> <1228483574.2805.499.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <86skp2l804.fsf@ds4.des.no> <1228507529.2805.539.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <49418BD9.8080105@h3q.com> Message-ID: <1229363854.1722.39.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> On Thu, 2008-12-11 at 22:53 +0100, Philipp Wuensche wrote: > Not entirely true, the jls output is totaly different than before and > breaks third-party applications like jailaudit and ezjail. Right, well, whether they check for VERSION > 70200x or 80000, the format will is likely to change. Once everything has been sorted out, they can add support now, push out the updates, and the version in common use will be forward/backward compatible. Whatever we have to do to light a fire there -- I just don't want ezjail-admin compatibility to be a showstopper on this. > > It is uneasy to parse too. -- Brian A. Seklecki Collaborative Fusion, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-virtualization/attachments/20081215/e0b4409d/attachment.pgp From bzeeb-lists at lists.zabbadoz.net Mon Dec 15 11:55:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Dec 15 11:55:13 2008 Subject: HEADS UP: r185435 multi-IPv4/v6/no-IP jails in HEAD In-Reply-To: <1229363854.1722.39.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> References: <20081201085229.D80401@maildrop.int.zabbadoz.net> <20081201122937.81475f0zhfsjya4o@webmail.leidinger.net> <6ae50c2d0812021800x791d2cfeh45d590de120f76df@mail.gmail.com> <1228483574.2805.499.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <86skp2l804.fsf@ds4.des.no> <1228507529.2805.539.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <49418BD9.8080105@h3q.com> <1229363854.1722.39.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> Message-ID: <20081215194716.M97918@maildrop.int.zabbadoz.net> On Mon, 15 Dec 2008, Brian A. Seklecki wrote: > On Thu, 2008-12-11 at 22:53 +0100, Philipp Wuensche wrote: >> Not entirely true, the jls output is totaly different than before and >> breaks third-party applications like jailaudit and ezjail. > > Right, well, whether they check for VERSION > 70200x or 80000, the > format will is likely to change. > > Once everything has been sorted out, they can add support now, push out > the updates, and the version in common use will be forward/backward > compatible. > > Whatever we have to do to light a fire there -- I just don't want > ezjail-admin compatibility to be a showstopper on this. Two comments: the format as is, is most likely to stay for the livetime of the 7.x branch once things are MFCed. For 8 with vimage and we'll get an entirely new management interface for all this. /bz PS: yes, I know rc.d/jail foo still needs integration. Has anyone tested what was posted? -- Bjoern A. Zeeb The greatest risk is not taking one. From alex.wilkinson at dsto.defence.gov.au Mon Dec 15 23:32:45 2008 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Mon Dec 15 23:32:52 2008 Subject: Network Virtualizing Message-ID: <20081216070719.GB1501@stlux503.dsto.defence.gov.au> Some of you may find this an interesting read: Crossbow - Network Virtualization Architecture Comes to Life [http://blogs.sun.com/sunay/entry/crossbow_network_virtualization_architecture_comes] -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From julian at elischer.org Tue Dec 16 00:01:32 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Dec 16 00:01:39 2008 Subject: Network Virtualizing In-Reply-To: <20081216070719.GB1501@stlux503.dsto.defence.gov.au> References: <20081216070719.GB1501@stlux503.dsto.defence.gov.au> Message-ID: <49475DF8.1050608@elischer.org> Wilkinson, Alex wrote: > Some of you may find this an interesting read: > > Crossbow - Network Virtualization Architecture Comes to Life > [http://blogs.sun.com/sunay/entry/crossbow_network_virtualization_architecture_comes] Interesting reading.. This is the equivalent of a combination of a number of bits of work done by Marko, Kip, ALC, jhb, and many others.. we aren't too far behind here.. Marko has virtual images with cpus assigned to them (or, at least he has work in that direction, and Kip has work on NICs with multiple receive/xmit rings etc. ALC has work on virtualised interfaces with hardware support. Jhb and others are doing multiple MSI interrupts and network polling... Interesting times.. > > -aW > > IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. > > > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org" From julian at elischer.org Tue Dec 16 11:37:02 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Dec 16 11:37:08 2008 Subject: Problems with IGMPv3 and VIMAGE In-Reply-To: <4947FB30.8090905@incunabulum.net> References: <4947B5DB.7030502@incunabulum.net> <4947EE59.3090502@elischer.org> <4947F1F4.6020306@incunabulum.net> <4947F935.9070301@elischer.org> <4947FB30.8090905@incunabulum.net> Message-ID: <49480357.2000400@elischer.org> Bruce Simpson wrote: > Julian Elischer wrote: >> virtualisation of netisr at teh moment is still in flux a bit. >> the netisr thread (that's all it really is) becomes associated with >> a particular vimage as required. (but hey... read the code.. :-) >> >> http://perforce.freebsd.org/fileLogView.cgi?FSPC=//depot/projects/vimage/src/sys/net/netisr.c >> >> >> >>> >>> Is there a way of virtualizing mutexes? IGMPv3 currently has a global >>> output queue serviced by the netisr, as that is able to take all the >>> required locks in the right order to get to ip_output(), and this >>> queue is covered by a mutex. >> >> mutexes embedded in structures that are virtualises are virtualised.. >> for example if you have a mutex on teh reassembly queue in one stack >> that owuld b e a differnt mutex than one on another stack so they >> could never collide. >> it's a per instance decision on the part of the porter. > > OK, so I have to move "struct ifqueue igmpoq" into "struct vnet_inet" ? not necessarily. atomicity of virtualization is on kernel module boundaries. By this I mean that if it's separately loadable, it is probably separate enough to have it's own virtualisation structure containing al it's own 'global' variables, including its mutex. When you register your module with the vimage framework a new instance of your structure should be allocated by the constructor method you registered for it. > > Do I have to explicitly mtx_init() this mutex from within my pr_init > routine, i.e. igmp_init() ? > yes, as a new one would be created every time we make a new virtual machine (with its own IGMP3 instance). Don't forget to make a destructor function as well that tears down teh IGMP3 stack when the VM is removed. > Up until now the code has been using the MTX_SYSINIT() macro. I don't THINK that will work but I could be wrong.. Marko has done some pretty remarkable things. > >> >> Have you looked at the Vimage porter guide? >> >> http://perforce.freebsd.org/fileLogView.cgi?FSPC=//depot/projects/vimage/porting_to_vimage.txt >> > > Yes, but it didn't answer all my questions, so I am bugging everyone :-) when you understand something new, please send me an update to the doc that explains it so I can make the doc better. > > thanks again > BMS From bzeeb-lists at lists.zabbadoz.net Wed Dec 17 02:25:08 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Dec 17 02:25:32 2008 Subject: HEADS UP: vimage ABI constraints on container structs [was: Re: svn commit: r186057 - head/sys/netinet] In-Reply-To: References: <200812132159.mBDLxIQv040799@svn.freebsd.org> Message-ID: <20081217084354.T97918@maildrop.int.zabbadoz.net> On Tue, 16 Dec 2008, Peter Wemm wrote: Hi, let me Cc: virtualization and current@ for this reply (to have the explicit HEADS UP) for what Peter pointed out. The first to reply may want to trim the Cc: list again; possibly to only virtualization. > On Sat, Dec 13, 2008 at 1:59 PM, Bjoern A. Zeeb wrote: >> De-virtualize the MD5 context for TCP initial seq number generation >> and make it a function local variable like we do almost everywhere >> inside the kernel. > [..] >> --- head/sys/netinet/vinet.h Sat Dec 13 21:17:46 2008 (r186056) >> +++ head/sys/netinet/vinet.h Sat Dec 13 21:59:18 2008 (r186057) >> @@ -142,7 +142,6 @@ struct vnet_inet { >> int _isn_last_reseed; >> u_int32_t _isn_offset; >> u_int32_t _isn_offset_old; >> - MD5_CTX _isn_ctx; >> >> struct inpcbhead _udb; >> struct inpcbinfo _udbinfo; > > I'm bitterly unhappy with this. Every time these structs are touched, > either directly or indirectly, there is a guaranteed ABI breakage with > kernel modules. > > There needs to be a __FreeBSD_version bump (or something similar) > every time any of these structures change, and any kernel modules > *must* be prevented from loading. It can't be a >= some version, it > has to be an exact match. > > With the global variable method the linker calculates the offsets at > load time. With this abomination, the knowledge of the structure > layout is compiled into the generated code with no chance of a fixup. > There are no sanity checks. If a module that referenced _isn_ctx is > loaded the old way, there would be a link error. The new way will > have it silently trash _udb instead. > > There is a whole world of hurt being unleashed here. I suspect that > we might even be possible to run out of digits in our > __FreeBSD_version numbering scheme. > > I know we've talked about ABI-stable alternatives after the > infrastructure is done, but it needs to be absolutely clear that > touching this structure in the current form is a guaranteed ABI break, > and is currently undetected. If you boot kernel.old, you're hosed. > (Again, with -current, this might be ok for a while, but this scheme > won't wash with ports or other 3rd party modules) ... > In the mean time, I'd like to see some compile-time asserts in there > to make sure there are no accidental size changes of this structure. Ok, there are multiple things here: Size changes: ---------------------------------------- * I think catching pure size changes alone are not enough; any changes to the structs matter. Think of removing an int and adding an int (even at the same place). Something working on this will trash it. * The size changes of course would guard about non-obvious, indirect struct changes like (just an example) a change to struct inpcbinfo that make me worry even more (like they seem to worry you). More on structure changes: ---------------------------------------- * While this is on HEAD (refering to "Again, with -current, this might be ok for a while ..") I expected the following (major) changes coming with the continuing integration and testing: 1) Final passthrough on the set of virtualized variables. That might happen after Step #3 when people can actually test of SVN. 2) During Benchmarking - this would be about the same time - there might be shuffling. 3) Before we turn to a STABLE branch. *fear* * Again it's the indirect changes as said above (which are very worryingly). ABI problem: ---------------------------------------- * I agree that there are unaddressed challenges here. * Ideally we want version checking - at least at load time for modules - per container struct, as people do not want to change and recompile everything if say something in gif or ipsec changes which might not affect them. netgraph has done something like this but my feeling is that that would be the wrong way to go, especially wrt to vinet/vinet6. * I am not sure if padding as we had it before will work for stable branches. We need to think of this problem as well. To my understanding MAC has another really large structure with sufficient padding but it's a subsystem more or less living on its own on the side, not as heavily changes between branches and MFCed as the netstack and it's (function) pointers there and less direct members. * If you have suggestions or solutions, please share them. * .. Misc: ---------------------------------------- * I was aware of the problem and failed on two fronts here: 1) Doing my commit after Marko and forgetting about it going from the p4 branches to SVN. 2) Forgetting to mention this in the HEADs UP:( * The http://wiki.freebsd.org/Image/BeginnersGuideFAQ had a (somewhat hidden) "A single change would require complete recompiliation." I factored it out but will need to be more explicit there or refer to this thread. * Thanks a lot for sending this out to comitters and making them aware of the problem. I Cc:ed current@ and virtualization@ in the reply and change the subject. * I am happy there is another pair of eyes here now:) After losing the initial three other reviewers ... * I think the current mode (is?/)was "getting the infrastructre in" and get more hands (again) for the remaining parts when inevitable confronted with it and the huge pile of changes is gone and one might see more clear again. * We may want to always keep in mind that, not for 8 but maybe for 9, people may want to further virtualize more subsystems so whatever we do should possibly be general enough to work for other parts of the kernel as well. * As a very last resort at the moment (which would be a pitty) we can still do the rollback, keep the globals (as default) and only have virtualization optional. I would expect there to be some "keeping in sync" problems but it would be a lot easier to have both working and have people to adhere to the ``V_rules'' than on the side. It would be kind of hard for 3rd party vendors to supply (binary) modules with that then though. I really hope we won't need to go there. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From duerrm at gmail.com Mon Dec 22 00:54:00 2008 From: duerrm at gmail.com (=?ISO-8859-1?Q?michael_d=FCrr?=) Date: Mon Dec 22 00:54:09 2008 Subject: Problems starting routing software at virtual nodes Message-ID: Hallo, I updated my FreeBSD RELEASE 7.0 to RELENG_7_1 and installed the VIMAGE capable kernel and the vimage(8) tool from the provided sources at http://imunes.net/virtnet/vimage_7-20081015.tgz I also installed tk-8.4, quagga and xorp from the ports repos. In order to deploy more complex networking setups I wanted to switch from static routing ripv2. Now my question: Are there certain settings I have to perform in order to get ripd working? So far, I always tried to start the daemon by executing vimage v1 zebra -d vimage v1 ripd -d but both commands immediately return and nothing else happens (no errors, no daemon processes started). In case I call these commands at the host zebra -d rip -d everything works as expected. I'm sorry for this question, but is it necessary to install a special configured version of the quagga routing software to get things working? Thanks a lot and merry Christmas :-) Cheers, Michael From zec at icir.org Mon Dec 22 05:43:56 2008 From: zec at icir.org (Marko Zec) Date: Mon Dec 22 05:44:02 2008 Subject: Problems starting routing software at virtual nodes In-Reply-To: References: Message-ID: <200812221443.40546.zec@icir.org> On Monday 22 December 2008 09:53:58 michael d?rr wrote: > Hallo, > > I updated my FreeBSD RELEASE 7.0 to RELENG_7_1 and installed the > VIMAGE capable kernel and the vimage(8) tool from the provided > sources at http://imunes.net/virtnet/vimage_7-20081015.tgz > > I also installed tk-8.4, quagga and xorp from the ports repos. > > In order to deploy more complex networking setups I wanted to switch > from static routing ripv2. > > Now my question: Are there certain settings I have to perform in > order to get ripd working? So far, I always tried to start the daemon > by executing > > vimage v1 zebra -d > vimage v1 ripd -d > > but both commands immediately return and nothing else happens (no > errors, no daemon processes started). In case I call these commands > at the host > > zebra -d > rip -d > > everything works as expected. > > I'm sorry for this question, but is it necessary to install a special > configured version of the quagga routing software to get things > working? Hi Michael, my wild guess is that you are attempting to run multiple instances of quagga (i.e. zebra, ripd etc.) and that they are clashing on /var/run/quagga/ PF_UNIX named sockets. My suggestion would be to make a separate directory for each vimage in say /tmp, and then make /var/run/quagga a variant symlink to those dirs. You can do the same for the Quagga.conf file for which the path is hardcoded in quagga as well: ln -s /tmp/$vimage_name/@ /var/run/quagga ln -s /tmp/$vimage_name/@/boot.conf /usr/local/etc/quagga/Quagga.conf The @ sign will be substituted with the current vimage name when resolving the symlink. And don't forget to issue "vtysh -b" after starting your daemons if you are using the unified Quagga.conf file. Hope this helps, Marko From zec at icir.org Mon Dec 22 05:48:16 2008 From: zec at icir.org (Marko Zec) Date: Mon Dec 22 05:48:23 2008 Subject: Problems starting routing software at virtual nodes In-Reply-To: <200812221443.40546.zec@icir.org> References: <200812221443.40546.zec@icir.org> Message-ID: <200812221448.09976.zec@icir.org> On Monday 22 December 2008 14:43:39 Marko Zec wrote: > On Monday 22 December 2008 09:53:58 michael d?rr wrote: > > Hallo, > > > > I updated my FreeBSD RELEASE 7.0 to RELENG_7_1 and installed the > > VIMAGE capable kernel and the vimage(8) tool from the provided > > sources at http://imunes.net/virtnet/vimage_7-20081015.tgz > > > > I also installed tk-8.4, quagga and xorp from the ports repos. > > > > In order to deploy more complex networking setups I wanted to > > switch from static routing ripv2. > > > > Now my question: Are there certain settings I have to perform in > > order to get ripd working? So far, I always tried to start the > > daemon by executing > > > > vimage v1 zebra -d > > vimage v1 ripd -d > > > > but both commands immediately return and nothing else happens (no > > errors, no daemon processes started). In case I call these commands > > at the host > > > > zebra -d > > rip -d > > > > everything works as expected. > > > > I'm sorry for this question, but is it necessary to install a > > special configured version of the quagga routing software to get > > things working? > > Hi Michael, > > my wild guess is that you are attempting to run multiple instances of > quagga (i.e. zebra, ripd etc.) and that they are clashing > on /var/run/quagga/ PF_UNIX named sockets. My suggestion would be to > make a separate directory for each vimage in say /tmp, and then > make /var/run/quagga a variant symlink to those dirs. You can do the > same for the Quagga.conf file for which the path is hardcoded in > quagga as well: > > ln -s /tmp/$vimage_name/@ /var/run/quagga > ln -s /tmp/$vimage_name/@/boot.conf /usr/local/etc/quagga/Quagga.conf Ooops... The above symlink hack wouldn't work, but the one bellow should: ln -s /tmp/@ /var/run/quagga ln -s /tmp/@/boot.conf /usr/local/etc/quagga/Quagga.conf Good luck, Marko > The @ sign will be substituted with the current vimage name when > resolving the symlink. And don't forget to issue "vtysh -b" after > starting your daemons if you are using the unified Quagga.conf file. > > Hope this helps, > > Marko > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscribe@freebsd.org"