--- Day changed

--- Log opened Sun May 22 23:59:02 2005
00:00 -!- enum [~Administr@ip68-7-54-228.sd.sd.cox.net] has quit [Read error: Connection reset by peer]
01:01 -!- soffi [~soffi@proxy.du.vdsl.is] has joined #xen
01:41 -!- monrad [~monrad@213083190130.sonofon.dk] has quit [Quit: Leaving]
01:50 -!- rusty [~rusty@ppp60-148.lns1.cbr1.internode.on.net] has joined #xen
02:23 -!- crisen [~crisen@spank.terdmonk.com] has quit [Quit: BitchX-1.0c20cvs -- just do it.]
02:34 -!- cilkay [~cilkay@CPE00d0b743a22f-CM0011ae01fcbe.cpe.net.cable.rogers.com] has joined #xen
02:34 -!- cilkay [~cilkay@CPE00d0b743a22f-CM0011ae01fcbe.cpe.net.cable.rogers.com] has left #xen []
02:38 < mael> hi
02:39 < mael> Sir_Ahzz: you're exporting twice your iscsi volumes?
02:39 < mael> seems like  a waste, no?
04:41 -!- yarihm [~yarihm@vpn-global-dhcp1-247.ethz.ch] has joined #xen
04:43 -!- soffi_ [~soffi@Tolvudeild-SC-gw.vv.simnet.is] has joined #xen
04:44 -!- soffi_ [~soffi@Tolvudeild-SC-gw.vv.simnet.is] has quit [Quit: ]
04:48 -!- rusty [~rusty@ppp60-148.lns1.cbr1.internode.on.net] has quit [Quit: Client exiting]
04:54 -!- Beaky [~chatzilla@ncg-adsl.demon.co.uk] has joined #xen
04:59 -!- athomas [~athomas@ppp-0-76.lond-b-2.access.uk.tiscali.com] has joined #xen
05:46 -!- Treibholz [heuldoch@i3ED6E149.versanet.de] has joined #xen
05:48 < Treibholz> hi, why can't I choose the hardware in the kernel for my privileged dom0. How can I use my scsi-raid then?
05:52 -!- yarihm [~yarihm@vpn-global-dhcp1-247.ethz.ch] has quit [Read error: Connection reset by peer]
05:52 -!- yarihm [~yarihm@vpn-global-dhcp1-253.ethz.ch] has joined #xen
05:53 -!- yarihm [~yarihm@vpn-global-dhcp1-253.ethz.ch] has quit [Quit: ]
06:28 -!- DEac- [~deac@xdsl-84-44-213-85.netcologne.de] has quit [Ping timeout: 480 seconds]
06:39 -!- DEac- [~deac@xdsl-195-14-216-137.netcologne.de] has joined #xen
06:40 < Treibholz> no, I cannot boot...
06:41 -!- movement [~moz@82.152.177.227] has joined #xen
06:42 -!- soffi_ [~soffi@Tolvudeild-SC-gw.vv.simnet.is] has joined #xen
06:43 -!- soffi_ [~soffi@Tolvudeild-SC-gw.vv.simnet.is] has quit [Quit: ]
07:07 < Treibholz> I can't mount the root-fs...
07:08 < Treibholz> because I can't compile the support for my scsi-controller in the dom0-kernel.
07:22 -!- homebaum_ [~michael@wbar1.sea1-4-5-031-104.sea1.dsl-verizon.net] has joined #xen
07:29 -!- homebaum [~michael@wbar1.sea1-4-5-031-104.sea1.dsl-verizon.net] has quit [Ping timeout: 480 seconds]
08:07 -!- soffi [~soffi@proxy.du.vdsl.is] has quit [Quit: Leaving]
08:53 -!- dwh [~sc@h-67-100-122-88.sttnwaho.dynamic.covad.net] has quit [Read error: Operation timed out]
08:56 -!- wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has quit [Ping timeout: 480 seconds]
09:07 -!- rharper [~rharper@cpe-70-113-90-94.austin.res.rr.com] has joined #xen
09:14 -!- Treibholz [heuldoch@i3ED6E149.versanet.de] has quit [Ping timeout: 480 seconds]
09:15 -!- dwh [~sc@h-67-100-122-88.sttnwaho.dynamic.covad.net] has joined #xen
09:45 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has joined #xen
09:49 -!- wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has joined #xen
09:52 -!- wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has quit [Quit: ]
09:53 -!- jesse_ [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has joined #xen
09:54 -!- jesse_ is now known as wenchien
09:54 -!- soffi [~soffi@Tolvudeild-SC-gw.vv.simnet.is] has joined #xen
09:55 < Sir_Ahzz> mael, no, i'm interested in a: providing true redundancy for some data, and better IO ops/sec on others.
09:55 < Sir_Ahzz> I'm attempting to design a layout and HA setup that will provide maximum uptime and protection of data.
09:57 < mael> Sir_Ahzz:  so your server exporting the devices as nfs/iscsi volumes is doing RAID?
09:57 < Sir_Ahzz> via evms, yes.
09:57 < Sir_Ahzz> right now just raids 0 and 1 depending on the data being stored.
09:57 < mael> ok
09:58 < mael> still, this is a pretty complex design
09:58 < Sir_Ahzz> the 2 disk nodes run BBR on each disk then export that bbr device to the concentrator node.
09:58 < Sir_Ahzz> *nod* that it is. :
09:58 < mael> not very "KISS"
09:58 < Sir_Ahzz> but I'm used to such designs.
09:59 < Sir_Ahzz> well, you can't have too much simplicity when you are trying to do software based reliability provisioning with cheap hardware. :)
09:59 < Sir_Ahzz> it works well for now.
09:59 < mael> are the two 1.4 TB servers full of scsi disk? or is it sata/ata disk drives.
09:59 < mael> ?
09:59 < Sir_Ahzz> no, one has 800GB of ide, the other has 600GB of ide.
09:59 < mael> ok
09:59 < Sir_Ahzz> total of 1.4TB of BBR ide.
10:00 < Sir_Ahzz> the way I've set it up, if a mirror set has one disk die, a script that monitors things detects it and fails one of the mirrors temporarilly.
10:00 < Sir_Ahzz> till the bad mirror is fixed.
10:00 < Sir_Ahzz> same with bbr relocation. it triggers the disk failure and rebuilds so no data is lost.
10:01 < Sir_Ahzz> right now it's all 5400rpm ide ata100
10:01 < mael> I don't know BBR
10:02 < Sir_Ahzz> bad block relocator.
10:02 < mael> it seems to be evms related stuff no?
10:02 < Sir_Ahzz> yes, it's part of the linux DM suite. specificly a patch from evms.
10:03 < Sir_Ahzz> the fun part is this layering has triggered bugs in ietd and evms that I've reported upstream for fixes.
10:03 < mael> well, I'm still waiting for a xfs/dm bug fix
10:03 < Sir_Ahzz> the second reason for managing it all via evms on the concentrator is that it adds a layer of buffering for better IO interleaving, as well as provides a single point of management as I add new disk nodes.
10:04 < mael> dm seems pretty buggy
10:04 < Sir_Ahzz> *nod* I have to figure out how to write a tool for selectively deactivating evms volumes.
10:04 < Sir_Ahzz> right now they only worry about keeping things activated. 8-P
10:04 < mael> BBR seems interesting anyway
10:04 < Sir_Ahzz> it's saved my bacon several times.
10:04 < Sir_Ahzz> with it and raid1 it's a nice double catch for flaws.
10:04 < mael> but you export your ide drives using the iscsi target stuff?
10:04 < Sir_Ahzz> *nod*
10:05 < Sir_Ahzz> also as nfs volumes.
10:05 < mael> do you need to use the sg device?
10:05 < Sir_Ahzz> no.
10:05 < mael> or does it support direct export of hdX devices?
10:05 < Sir_Ahzz> ietd exports any block device.
10:05 < mael> ok
10:05 < Sir_Ahzz> just setup your lun as a fileio type.
10:06 < Sir_Ahzz> doesn't work well on CD or tape devices yet.
10:06 < mael> I assume exporting scsi drive will cost less anyway :)
10:06 < Sir_Ahzz> the newer sata is performance competitive with mid range scsi now.
10:06 < mael> what do you call "mid range"? 
10:06 < mael> We use u320 10k drives here
10:07 < mael> most of them with adaptec 2010s raid controllers
10:07 < mael> 15k is still too expensive
10:07 < Sir_Ahzz> I'm drafting plans for a management tool that will inteligently asist the admin in managing evms by trackign the performance data of ide disks (capacity, raw IO speed, seek latency, node location) and make it simpler to create partitions based on performance criteria.
10:07 < Sir_Ahzz> *nod* there are 10krpm sata with equal throughput and seek latencies to those.
10:08 < Sir_Ahzz> especially once sata300 gets into mainstream production.
10:08 < Sir_Ahzz> I'm goign to experiment with some form of static ram buffering device at the concentrator and/or disk node level when I have the time.
10:09 < mael> well I did performance testing on sata drives (don't remember exactly what their specs where) and wasn't too happy
10:09 < Sir_Ahzz> with iscsi's error recovery, loosing the concentrator right now doesn't cause data loss if your initiator and target support  it.
10:09 < Sir_Ahzz> probably 7.2k and a cheap controller.
10:09 < mael> I've read stuff about the fact drive makers where not supporting all the features
10:10 < Sir_Ahzz> *nod*
10:10 < Sir_Ahzz> same on scsi. not truly enabling full sync 
10:10 < Sir_Ahzz> like I said, it's an experiment, and not meant to be aperfect replacement of a pure scsi setup.
10:11 < mael> yeah right
10:11 < mael> where are you working?
10:11 < Sir_Ahzz> what would be nice is if there was a way to separate data/metadata loging to be done at the concentrator level so it ca n use fast IO disks for that and cheaper IDE for the main storage.
10:11 < Sir_Ahzz> for myself. :)
10:11 < Sir_Ahzz> terrabox.com
10:13  * Sir_Ahzz looks at his dhl shipping tracking and blinks.
10:13 < mael> Sir_Ahzz:  you should put "ServerTokens Prod" in your apache config :)
10:13 < Sir_Ahzz> ok, it was picked up by dhl only 20 miles from my house and hnow it's 1000 miles away in ohio!
10:13 < Sir_Ahzz> mael, hmmm?
10:13  * Sir_Ahzz shakes his head at dhl.
10:14 < Sir_Ahzz> oh wait, i misread.
10:14 < Sir_Ahzz> it started in ohio. my mistake.
10:14 < mael> well it's just you tell everyone that you use apache version debian 1.3.33
10:14 < Sir_Ahzz> ah
10:14 < mael> so obviously the server is a debian box :)
10:14 < Sir_Ahzz> *nod*
10:15 < Sir_Ahzz> and locked down and firewalled to hell and back.
10:15 < mael> with all the bugs a hacker could use :)
10:15 < Sir_Ahzz> if someone wanted to peneatrate my hosting, all they had to do was pickup a cheapo account and use local php code.
10:15 < Sir_Ahzz> they would know what I had at that point anyways.
10:15 < mael> :)
10:16 < Sir_Ahzz> so hiding what serve ryou have is pretty much pointless.
10:16 < mael> yeah that's true when you have user accounts on the machines
10:16  * Sir_Ahzz has plenty of experience in securing servers.
10:16 < Sir_Ahzz> been using linux since 93
10:17 < Sir_Ahzz> I've had only 1 root level crack, and that was due to a 0-day exploit.
10:17 < Sir_Ahzz> had several user level cracks, due to bad user apps or bad choices in user passwords.
10:17 < Sir_Ahzz> which I have to think is a pretty good track record. *grin*
10:17 < mael> *nod*
10:18 < Sir_Ahzz> considering it's 12 years of operation now.
10:18 < Sir_Ahzz> and the root level didn't get past the apache hosting server.
10:18 < mael> we had a box cracked where I worked previously
10:18 < Sir_Ahzz> segregation of system functionality.
10:18 < mael> one on 800 servers..
10:19 < Sir_Ahzz> #1 mistake companies make. they think that behind firewall == no need for security.
10:19 < Sir_Ahzz> ;-P
10:19 < mael> couldn't find how he went in though
10:19 < Sir_Ahzz> *nod* that can be frustrating.
10:19 < mael> we detected a strange memory usage on the server after 2 weeks
10:19 < Sir_Ahzz> which is part of why I log all inbound and outbound new connections.
10:20 < Sir_Ahzz> as well as monitor system usage.
10:20 < mael> rrd graph are sooooo useful
10:20 < Sir_Ahzz> *grin*
10:20 < Sir_Ahzz> nagios is your friend and allie. ;)
10:20 < Sir_Ahzz> erm can't spell this morning.
10:20 < mael> you can detect patterns telling strange stuff is happening where everything else is mute
10:20 < Sir_Ahzz> *nod*
10:21 < mael> don't worry, I won't notice :)
10:21 < mael> I'm not really a native english writer :)
10:21 < Sir_Ahzz> I've allways believed that it's more about the admins and monitoring than any fancy IDS or foolproof firewall.
10:21 < Sir_Ahzz> because no matter how well you set it up, there IS a way through.
10:21 < mael> hehe actually we couldn't find anything in the IDSs logs
10:22 < Sir_Ahzz> not terribly surprising. :)
10:22 < Sir_Ahzz> most IDS rely on knowing how people get in to detect.
10:22 < Sir_Ahzz> best defense is to go with keys instead of passwords for root level work.
10:22 < Sir_Ahzz> disallow any clear text methods.
10:23 < Sir_Ahzz> except where required.
10:23 < Sir_Ahzz> like iscsi.
10:23 < mael> anyway, from what we know, the machine was hacked because of apache
10:23 < Sir_Ahzz> not treribly surprising.
10:23 < mael> yeah
10:23 < mael> but nothing much :)
10:23 < Sir_Ahzz> I've pondered using a reverse-squid just to log requests and watch for odd encoding queries.
10:23 < mael> this is why I got a little paranoid about helping ppl to hack my box :)
10:24 < Sir_Ahzz> there are other ways to figure out what you are running than the server strings.
10:24 < Sir_Ahzz> that'll just foil kiddies.
10:24 < mael> well it was a *high load* web service and we could'nt use a reverse proxy on top of the cache servers
10:24 < mael> was too messy then
10:24 < Sir_Ahzz> have you thought of using a reverse-squid to filter the request strings?
10:24 < Sir_Ahzz> load balance em in front of the httpd.
10:25 < mael> yeah we did but the devs ppl where not happy about it :)
10:25 < Sir_Ahzz> no different than load balancing httpd.
10:25 < Sir_Ahzz> feh. the dev people get thier own sandboxes that aren't publicly available and you provide a secure update method.
10:25 < Sir_Ahzz> if dev doesn't like it, tough. 
10:25 < mael> it was tens of servers in a cluster doing  3-tier
10:26 < Sir_Ahzz> sounds like a better prod deployment method was needed.
10:26 < mael> arch was pretty complicated and we couldn't had one more layer on top of that
10:26 < Sir_Ahzz> not to be arrogant or say you were a bad admin.
10:26 < mael> no offense taken :)
10:26 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
10:26 < Sir_Ahzz> *nod* was a system admin involved in the original design of the system level?
10:26 < mael> of course not :)=
10:27 < Sir_Ahzz> there was your problem them. ;)
10:27 < Sir_Ahzz> err then.
10:27 < mael> yeah but you know, business, management and the like...
10:27 < Sir_Ahzz> *nod*
10:27 < Sir_Ahzz> understandable. and frustrating.
10:27 < mael> this is why I left, you know :)
10:27 < Sir_Ahzz> *nod* same reason why I quit my day job 4.5 years ago.
10:28 < mael> got fed up having the phone at 3 in the morning because the devs did something in a hurry without any testing
10:28 < Sir_Ahzz> major application that managed millions of dollars in inventory and shipping per location yet any user could easilly break out with ctl-c and have global access.
10:28 < Sir_Ahzz> ;-P
10:28 < Sir_Ahzz> and the 3am emergency fixes because an admin violated the WRITTEN procedures 
10:28 < mael> hehe
10:29 < Sir_Ahzz> so now I advise companies on how NOT to do things the wrong way.
10:29 < Sir_Ahzz> security comes from planning, not hot fixes. (in part)
10:29 < mael> yeah I did it also internally, but it seems it talk in the wind :)
10:29 < mael> s/it talk/I talked/
10:29 < Sir_Ahzz> companies have a habbit of not listening to internal people.
10:30 < hollis> amen :)
10:30 < mael> hi hollis :)
10:30 < Sir_Ahzz> it comes from the long standing teachings of segregation of responsibilities and the old habbits of computers are internal things.
10:30 < hollis> hi :)
10:30 < Sir_Ahzz> for security to work, it has to be a collaborative effort across all involved departments.
10:31 < Sir_Ahzz> you can't just assign a security department.
10:31 < mael> well here it is more because IT production teams are considered stupid grunts you don't have to listen to
10:31 < Sir_Ahzz> granted having asecurity officer helps, but they can't know the ins and outs of everything.
10:31 < mael> devs and marketing *are* ppl you listen at
10:32 < mael> and the lack of feedback from the production don't improve things in the end
10:32 < Sir_Ahzz> so you assign a person or three (depending on area of knowlege size/complexity) and they work togeather with a head security person that asists with the negotiations of each areas security.
10:32 < Sir_Ahzz> vs having a security dept that is external to everyone.
10:32 < mael> yeah sure
10:33 < mael> security is everyone's job anyway
10:33 < Sir_Ahzz> exactly the point.
10:33 < Sir_Ahzz> noone thinks about security until it's too late.
10:33 < mael> sure
10:33 < Sir_Ahzz> because it's not defined as thier task.
10:34 < Sir_Ahzz> people have a mistaken belief that security is some third-arty dept's job.
10:34 < mael> do you work alone at terrabox?
10:34 < Sir_Ahzz> yes and no.
10:34 < mael> or are you a team?
10:34 < Sir_Ahzz> I've had employees every now and then based on workload and income.
10:34 < Sir_Ahzz> i've always had other people I can draw on as needed.
10:35 < mael> I hope they manage security also :)
10:35 < Sir_Ahzz> I've never believed that I can solve everything. instead I present it as I know WHO I need to draw on for the correct answers to the client problems.
10:35 < mael> it's hard to have a consistent work when ppl change frequently
10:35 < Sir_Ahzz> *nod* part of how I pick my staff/resources.
10:35 < Sir_Ahzz> it's people that I know I can trust, and they know that security is a part of any task.
10:36 < Sir_Ahzz> makes it tougher to find the right people.
10:36 < Sir_Ahzz> but it's worth it.
10:36 < mael> and heterogeneity is the worst situation when considering security
10:36 < Sir_Ahzz> it can be.
10:37 < Sir_Ahzz> but if each componant is familiar with and communicates their needs for security, it can be more secure than a homogenous env.
10:37 -!- hbaum [~hbaum@bi01p1.co.us.ibm.com] has joined #xen
10:37 < hollis> it's like a disease that affects some crop. if the crop is identical genetically, 100% of it will be affected
10:37 < Sir_Ahzz> which is part of why I leverage a multitude of expertiece vs relying 100% on my own to provide the client with what they need.
10:38 < Sir_Ahzz> that and I don't hold back when I think a client is insisting on an action or course that will result in bad things.
10:38 < Sir_Ahzz> it's cost me potential clients in the pst, but it maintains my record.
10:38 < Sir_Ahzz> pst=past
10:39 < Sir_Ahzz> if a client won't do things the right way, they are doomed to failure anyways and isn't worth picking up as a client.
10:39 < mael> hollis:  yeah that's right
10:39 < Sir_Ahzz> it'll only associate my company name and myself with failures.
10:39 < mael> this is why multiple different layers is interesting
10:39 < Sir_Ahzz> *nod*
10:40 < Sir_Ahzz> one of the dangers of genetic engineering of crops. (family is historicly farmers from kansas)
10:40 < mael> but in the same time having homogeneous apps is interesting because you can update things efficiently
10:40 < Sir_Ahzz> my father is an "ole farmboy" that turned EE doctorate.
10:41 < Sir_Ahzz> mael this is where having a broad spectrum coordinator is benificial.
10:41 < mael> hehe I was postgraduate in biology/ecology before studying IT :)
10:41 < Sir_Ahzz> gives you a different perspective on IT eh? :)
10:41 < Sir_Ahzz> brb coffeee run.
10:41 < mael> well I have to leave anyway
10:42 < mael> got a kid to pick up :)
10:42 < mael> see ya
10:42 < Sir_Ahzz> laters. good chattign with you.
10:43 < Sir_Ahzz> hmm, client is late for 9am meeting.
10:43 < mael> too bad he won't have any coffee left :)
10:45 < Sir_Ahzz> teleconference.
10:45 < Sir_Ahzz> that way I don't have to share my coffee.;)
11:03 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [Quit: Leaving]
11:07 -!- tessier [~treed@222.253.78.14] has quit [Ping timeout: 480 seconds]
11:12 -!- stekloff [~stekloff@bi01p1.co.us.ibm.com] has joined #xen
11:16 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has quit [Quit: leaving]
11:17 -!- jeroney [~jeroney@pixpat.austin.ibm.com] has joined #xen
11:20 -!- Beaky [~chatzilla@ncg-adsl.demon.co.uk] has quit [Remote host closed the connection]
11:25 -!- aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
11:30 -!- matta-lt [~matta@69.93.28.254] has joined #xen
11:42 -!- Tv [~Tv@hq.inoi.fi] has joined #xen
11:52 -!- hollis [~hollis@pixpat.austin.ibm.com] has joined #xen
12:08 -!- Vip- [~weasel@S0106000c41cd470e.cg.shawcable.net] has joined #xen
12:08 < Vip-> Hi
12:08 < Vip-> Has anyone actually got Xen working on x86_64?
12:09 < Vip-> I know it's not completely ready, just wondering.
12:10 < hollis> jeroney has been working with it
12:11 < Vip-> Is it supposed to compile? (using the latest unstable dl'd from cam.ac.uk) I get an error.
12:12 < hollis> it compiles off and on ;)
12:12 < Vip-> arch/xen/x86_64/kernel/mpparse.c: In function `get_smp_config':
12:12 < Vip-> arch/xen/x86_64/kernel/mpparse.c:549: error: `isa_bus_to_virt_needs_PRIVILEGED_BUILD' undeclared (first use in this function)
12:12 < Vip-> arch/xen/x86_64/kernel/mpparse.c:549: error: (Each undeclared identifier is reported only once
12:12 < Vip-> arch/xen/x86_64/kernel/mpparse.c:549: error: for each function it appears in.)
12:13 < Vip-> :-)
12:13 < hollis> you might send a note to the list
12:13 < Vip-> devel list?
12:13 < hollis> yes
12:13 < Vip-> I did manage to get it to compile, but I have a bad feeling about it :-)
12:14 < Vip-> Since the error was in xenU, I vi'd the .config to not require the "privileged_build"
12:14 < Vip-> and then continued forward.
12:18 < jonmason> it was my understanding that dom0 on x86-64 doesn't boot yet
12:19 < jeroney> Vip: x86-64 is still under active development
12:23 < Vip-> jeroney: Yep. REading that all over the place :-) Just seeing what it would do now :-)
12:24 < Tv> Vip-: it _seems_ to me the error says domU's can't do ISA stuff
12:24 < Tv> Vip-: so don't try to configure it like that; most likely you should disable ISA
12:24 < Vip-> Tv: How to disable?
12:24 < Tv> disable all the drivers using it
12:24 < Tv> IIRRC
12:24 < Vip-> Ah, ok.
12:24 < Tv> I'm on powerpc now, can't cheat ;)
12:27 < jonmason> jeroney: can dom0 boot yet?
12:28 < Vip-> jonmason: well, I've built a kernel, I can go try ;-)
12:28 < jonmason> Vip-: go for it (I'm axious to get it working on my ahtlon64 box at home)
12:29 < jeroney> jonmason: yes but very unstable
12:29 < Vip-> Why if I copy my current (/boot/config-2.6.11-FC3) over into .config does it not compile anymore? It seems to want to compile for i386 instead?
12:29 < jeroney> jonmason: major changes last week & this week soon should be stabalizing
12:29 < Vip-> jeroney: so, very not recommended? :-) 
12:30 < jeroney> Vip: yeap not recommended unless you want to develop it
12:30 < Vip-> jeroney: ah, ok :-)
12:30 < jonmason> Vip-: develop it ;-)
12:30 < jonmason> jeroney needs help
12:30 < jeroney> haha
12:30 < Vip-> hahaha...I'm not much of a coder :-)
12:31 < Vip-> I'm willing to test it out though 
12:31 < jeroney> Vip: once it's ready for testing you will know...lot of people looking forward to it
12:31 < Vip-> I've been sysadming much too long now :-) Last coding was in the 80's. :-)
12:33 < Vip-> BTW, speaking of admining, what's the diff between Xen and Solaris Zones?  Does Xen actually allow a variety of kernels (Zones run on top of one kernel).
12:35 < movement> Vip-: yes
12:36 < Vip-> movment: so I'm not really running a zone then, I'm running a completely different kernel?
12:36 < movement> Vip-: essentially zones does things like split the process "table" into per-zone lists, whereas xen paravirtualises privileged operations such as page table updates
12:41 < Vip-> Well, thanks guys. Later.
12:41 -!- Vip- [~weasel@S0106000c41cd470e.cg.shawcable.net] has quit [Quit: Leaving]
12:41 < knewt> are zones like vserver then?
12:41 < movement> knewt: yes
12:44 < demon> "zones" is a solaris feature, right?
12:45 < movement> yes#
13:12 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
13:21 -!- athomas [~athomas@ppp-0-76.lond-b-2.access.uk.tiscali.com] has quit [Quit: Leaving]
13:27 -!- pwagland [~paul@kungfucoder.org] has joined #xen
13:37 -!- rharper [~rharper@cpe-70-113-90-94.austin.res.rr.com] has quit [Ping timeout: 480 seconds]
13:39 -!- stekloff [~stekloff@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
13:40 -!- pwagland [~paul@kungfucoder.org] has quit [Quit: BitchX-1.1-final -- just do it.]
13:49 -!- tim [~tim@cpe-66-67-139-238.rochester.res.rr.com] has quit [Remote host closed the connection]
13:51 -!- paul_ [~paul@kungfucoder.org] has joined #xen
13:51 -!- paul_ is now known as pwagland
13:51 -!- rharper [~rharper@pixpat.austin.ibm.com] has joined #xen
13:59 -!- tim [~tim@cpe-66-67-139-238.rochester.res.rr.com] has joined #xen
14:05 -!- demon [demon@newcastle.devrandom.net] has quit [Ping timeout: 480 seconds]
14:14 < pwagland> Anyone here know the details of the xen networking?
14:18 < knewt> do you mean the "xend" networking config stuff? because xen networking itself just appears as network interfaces that you can do anything you want with
14:19 < pwagland> More wrt to the core internals.
14:19 < pwagland> In particular, wrt to the e-mail I just fired off at the xen-devel
14:19 < pwagland> I can get all of the networking to work, just not to stop ;-)
14:24 < knewt> hmm. can't think of anything immediately. other than tap1 being a rather wierd name for a bridge. oh, and if you can't shut down the domUs properly, you should still be able to reboot dom0. just terminate the domains, and if /that/ doesn't work, just stop that xendomains script from running during reboot
14:27 < jonmason> pwagland: yeah, I know the code fairly well, what's up
14:31 < pwagland> Sorry... new baby girl... also demands some of my attention ;-)
14:32 < pwagland> jonmason : Basically I am getting the error unregister_netdevice: Waiting for vif7.0 to become free
14:32 < pwagland> knewt : tap1 is my internal tap device, the bridge is still xen-br0
14:33 < knewt> what are you using the tap device for?
14:33 < pwagland> I have three domains, one DMZ, one "external" and one "internal"
14:34 < pwagland> external and internal get the ethernet cards, tap1 is assigned to the DMZ.
14:34 < pwagland> All of the domUs are DMZ machines (mail/www/imap)
14:34 < knewt> i still don't understand the reason for a tap device?
14:36 < pwagland> As the xen-br0 appears to autoconfig itself to the device that it is slaving.
14:36 < pwagland> my tap1 has a totally different network/mask than eth0/eth1
14:36 < jonmason> pwagland: didn't you repost thios on xen-dvel a few days ago?
14:36 < knewt> you can just disable the xend networking script of course
14:36 < pwagland> No, I did mention it on IRC, but this is the first that I have posted.
14:37 < pwagland> I only joined xen-devel last night...
14:37 < pwagland> knewt : But wouldn'
14:37 < pwagland> t  that also disable networking?
14:39 < knewt> no, that would just stop xend from doing initial network setup. you'd still have it managing networking of domain startup. and you then do your network setup using your standard distro networking stuff
14:40 < knewt> for instance, i configure my xen-br0 using distro networking config, and don't add eth0 to it. i then route between eth0 and xen-br0. and xend adds new domains to xen-br0 just like normal
14:40 < pwagland> Ah. OK.
14:40 < pwagland> That is basically why I am using tap1, to do the same thing ;-)
14:41 < knewt> you could also replace the standard xend networking script with your own and still use xend network setup
14:41 < knewt> it's entirely up to you how you configure things really
14:41 < knewt> i thought tap devices were always hooked up to a user-mode program?
14:42 < pwagland> They don't have to be, just normally they would be.
14:42 < knewt> ah, ok
14:42 < pwagland> How would I go about setting up xen-br0 without xend then?
14:43 < knewt> most distros will have a standard way of setting up bridges as part of their networking configuration
14:44 < pwagland> But I don't really want a bridge... that is why I shunted it to tap1, so that it would bridge to nothing.
14:44 < pwagland> Also xend appears to be used by xm?
14:45 -!- demon [demon@66.35.250.240] has joined #xen
14:46 < knewt> you don't want all the domains on a virtual switch, like if they were real machines hooked up to a switch that was hooked up to the router?
14:47 < pwagland> Yes I do, but that is not what I think of as a bridge.
14:47 < knewt> a bridge is just a switch. or vice versa. bridge === switch
14:47 < demon> ... well, that is the classical definition of a 'bridge' in networking terms...
14:49 < pwagland> Hmm, I think of a bridge more as a layer 3 switch, in that it can also route between disparate networks
14:49 < demon> that would be a router
14:49 < knewt> if you give the bridge it's own ip address, that's then like having a network interface with that ip address that is connected to the switch
14:49 < demon> a bridge joins multiple layer 2 networks
14:51 < pwagland> Cool.
14:51 < pwagland> how do you start a domU without xm?
14:52 < demon> well, you'd have to write a client to talk to xend, or use xm-tools instead
14:52 < knewt> so what the standard xend networking setup script does, is configure a switch, connect your eth0 network card to the switch, and then create a new network interface with original ip address of your eth0 and connect the new interface to the switch
14:53 < demon> xm talks to xend, which in turn talks to the hypervisor
14:53 < murble> is it possible to make the vif interfaces fixed for a domain, so if i shut it down and restart it is allocated the same interface?
14:53 < demon> don't think so
14:53 < murble> (I need to do some kind of traffic accounting per domain, having them static would make it easier)
14:54 < demon> they're numbered based on the domain ID and how many VIFs the domain has
14:54 < pwagland> murble : I just saw on xen-user that 2.0.6 can supposedly do this
14:55 < murble> demon: then i have the problem because the domainID increases with time as users reboot.
14:55 -!- aliguori [~anthony@pixpat.austin.ibm.com] has quit [Quit: Leaving]
14:55 < murble> is it possible to have xend start a script at domain up/down in dom0?
14:56 -!- aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
14:57 < pwagland> murble : http://lists.xensource.com/archives/html/xen-users/2005-05/msg00372.html
14:57 < pwagland> And others in that thread may be useful
14:58 < murble> pwagland: thanks, btw the interface renaming thing is completely horrible!
14:59 < pwagland> murble : I won't argue ;-)
15:00 < knewt> murble: actually, a reboot doesn't increase the domID. a halt followed by a reboot does though.
15:01 < murble> knewt: when you have a reboot, xen doesn't notice at all?
15:01 < demon> if you just reboot and it's not set to halt on reboot, I think xend just loads the kernel image back in, jumps to the start location and lets it go on
15:02 < knewt> murble: it does notice yes, but the domain itself isn't torn down
15:02 < demon> it doesn't have to totally destroy the domain
15:02 < aliguori> knewt: how can you have a halt followed by a reboot?
15:02 < knewt> aliguori: ok ok. "a halt followed by a boot" then :)
15:02 < aliguori> you can do a halt, then start up the vm again i imagine
15:02 < aliguori> ahh, ok :-)
15:02 < demon> I know there's an option you can specify to make it always reboot even on halt
15:03 < aliguori> well, just specify the domid explicitly in the config file.. there's no reason to let xen do domid allocation
15:03 < murble> I think i'll rename vif to domain
15:03 < demon> aliguori: no, it always increments the new domain ID, I think xen itself picks that
15:03 < murble> as in ip link set dev $vif name vif-${domain}
15:03 < aliguori> demon: can you not specify domid as one of the parameters for xend?
15:04 < aliguori> you can for vm-tools :-)
15:04 < demon> you can specify it as a command line argument, but I don't think that's the one that xend itself uses/knows
15:06 < aliguori> yeah, i just looked through the xend code
15:06 < aliguori> that's odd
15:06 < aliguori> b/c the hypervisor lets you choose whatever domid you want when you create the domain
15:06 < rharper> collision check ?
15:06 < rharper> in the hypercall?
15:06 < aliguori> rharper: the hypercall will return EINVAL if the domid is already used
15:07 < rharper> aliguori: k
15:07 < aliguori> alternatively, you can specify 0 and it will choose one for you
15:07 < knewt> xend just lets the hypervisor always generate a domid itself
15:07 < knewt> like aliguori says, it's not a limitation of the hypervisor though
15:07 < aliguori> which is always the highest id that's never been allocated before
15:07 -!- pwagland [~paul@kungfucoder.org] has quit [Quit: BitchX-1.1-final -- just do it.]
15:09 < knewt> by the way, if you're running -unstable then you can specifiy the mac address of the vif interface, and then use /etc/iftab to set the name of the interface
15:13 -!- yarihm [~yarihm@80-218-6-139.dclient.hispeed.ch] has joined #xen
15:28 -!- aliguori [~anthony@pixpat.austin.ibm.com] has quit [Ping timeout: 480 seconds]
15:33 -!- aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
15:37 -!- plars [~plars@pixpat.austin.ibm.com] has quit [Ping timeout: 480 seconds]
15:45 -!- plars [~plars@pixpat.austin.ibm.com] has joined #xen
15:48 -!- paul_ [~paul@kungfucoder.org] has joined #xen
15:48 -!- paul_ is now known as pwagland
15:49 < pwagland> knewt: Hmm. It appears that tap1 may have been the problem
15:49 < pwagland> I set up a portless xen-br0
15:50 < pwagland> and it has not yet crashed on me
15:51 -!- pwagland [~paul@kungfucoder.org] has quit [Quit: ]
15:52 -!- pwagland [~paul@kungfucoder.org] has joined #xen
15:53 -!- xai [~pasta@cpe-70-112-17-10.austin.res.rr.com] has joined #xen
15:56 -!- jeroney [~jeroney@pixpat.austin.ibm.com] has quit [Quit: Leaving]
16:27 -!- cf0989b8 [~cf0989b8@ns.372broadway.com] has quit [Ping timeout: 480 seconds]
16:41 -!- Arnald [~Arnald@81-86-116-102.dsl.pipex.com] has joined #xen
16:48 -!- deadred [~win95@cpc1-brig4-5-0-cust169.brig.cable.ntl.com] has joined #xen
16:51 < deadred> hi, has anyone got freebsd to sucessfully boot as a guest os under testing or stable? i can't seem to work it out, it seems to hang every time i boot it
16:53 < murble> I've had it boot ok, what cmdline are you giving it in your config?
16:56 < deadred> extra = "vfs.root.mountfrom=ufs:/dev/xbd0,boot_verbose=yes ,boot_single=yes ,boot_gdb=yes"
16:58 -!- xai [~pasta@cpe-70-112-17-10.austin.res.rr.com] has left #xen [Zneet Znatter Zneet]
16:58 < deadred> how does that look?
16:59 -!- plars [~plars@pixpat.austin.ibm.com] has quit [Ping timeout: 480 seconds]
16:59 < deadred> hangs right after this line: GEOM: Configure xbd0c, start 0 length 425984000 end 425983999
17:00 < murble> I think i've seen that behaviour as well.
17:00 < murble> wait just sshing to my test box to see if i still have worky freebsd :-)
17:00 < deadred> okay
17:01 < murble> ok booting
17:01 < murble> I get: 
17:01 < murble> GEOM: new disk xbd0
17:01 < murble> GEOM: new disk xbd1
17:01 < murble> GEOM: Configure xbd0a, start 8192 length 425975808 end 425983999
17:01 < murble> GEOM: Configure xbd0c, start 0 length 425984000 end 425983999
17:01 < deadred> i've been trying to compile it myself since there is a patch on the freebsd xen guys site called "crash.patch" that appears to be newer than this kernel i have but the build scripts confuse me and hace no docs
17:01 < murble> and it carries on.
17:02 < murble> I'm pretty sure i build the kernel i'm running myself as it is identified as root@xen-vm2:/usr/src/build/xen-2.0-testing/freebsd-5.3-xenU/i386-xen/compile/XENCONF
17:02 < deadred> how did you get that compile/XENCONF file - that is what im missing
17:04 < murble> if it helps i'm booting with
17:04 < murble> extra = "boot.netif.ip=81.187.70.28"
17:04 < murble> extra += ",boot.netif.netmask=255.255.255.240"
17:04 < murble> extra += ",boot.netif.gateway=81.187.70.17"
17:04 < murble> extra += ",vfs.root.mountfrom=ufs:/dev/xbd0a"
17:04 < murble> extra += ",boot_verbose=yes"
17:04 < deadred> cant hurt to try im not giving it an IP addres
17:04 < murble> nlooking at your boot parittiong you are not specifiy the first slice
17:04 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
17:04 < murble> e.g. /dev/xbd0a
17:05 < deadred> your right im not - just copied the args from freebsd.example
17:05  * deadred tries that
17:05 -!- plars [~plars@pixpat.austin.ibm.com] has joined #xen
17:08 < deadred> hah
17:08 < deadred> one of the changes made it boot :)
17:08 < murble> :-)
17:09 < deadred> thanks
17:09 < deadred> it was - giving it a nic and an ip number too
17:09 < deadred> i wasnt giving it a nic
17:10 < knewt> sounds like a bug then, as you shouldn't need to give it a nic for it to boot
17:10 < deadred> so long as it works im not complaining :D
17:10 < deadred> no doubt it is just how the kernel is compiled
17:12 < murble> deadred: i had fun building my kernel under freebsd before it crashed.
17:12 < murble> the kernel i had before didn't like any binaries from freebsd 4.X
17:12 < deadred> murble: :/
17:13 < deadred> woo - you've all made my day :) thanks guys - i'll play with this as soon as i get the chance :)
17:13 -!- deadred [~win95@cpc1-brig4-5-0-cust169.brig.cable.ntl.com] has quit [Quit: be back later :)]
17:13 < knewt> deadred: no matter how the kernel is compiled, if it won't boot without a nic when you're using a vbd root, there's a bug
17:24 -!- cilkay [~cilkay@CPE00d0b743a22f-CM0011ae01fcbe.cpe.net.cable.rogers.com] has joined #xen
17:45 -!- aliguori- [~anthony@pixpat.austin.ibm.com] has joined #xen
17:46 -!- aliguori- [~anthony@pixpat.austin.ibm.com] has quit [Quit: ]
17:57 -!- services.oftc.net changed the topic of #xen to: Xen Homepage->  http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html || Xen Wiki -> http://wiki.xensource.com || vm-tools : http://www.cs.utexas.edu/users/aliguori/vm-tools/
17:58 -!- services.oftc.net changed the topic of #xen to: Xen Homepage->  http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html || Xen Wiki -> http://wiki.xensource.com || vm-tools : http://www.cs.utexas.edu/users/aliguori/vm-tools/
18:00 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has left #xen [bug, n: A son of a glitch.]
18:08 -!- DEac- [~deac@xdsl-195-14-216-137.netcologne.de] has quit [Quit: Verlassend]
18:26 -!- matta-lt [~matta@69.93.28.254] has quit [Quit: There are 3 kinds of people: those who can count & those who can't.]
18:45 -!- hollis [~hollis@pixpat.austin.ibm.com] has quit [Quit: leaving]
19:03 -!- rharper [~rharper@pixpat.austin.ibm.com] has quit [Quit: Leaving]
19:24 -!- tessier [~treed@222.253.64.128] has joined #xen
19:32 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has joined #xen
19:42 -!- cilkay [~cilkay@CPE00d0b743a22f-CM0011ae01fcbe.cpe.net.cable.rogers.com] has quit [iridium.oftc.net charm.oftc.net]
19:42 -!- Arnald [~Arnald@81-86-116-102.dsl.pipex.com] has quit [iridium.oftc.net charm.oftc.net]
19:42 -!- tim [~tim@cpe-66-67-139-238.rochester.res.rr.com] has quit [iridium.oftc.net charm.oftc.net]
19:42 -!- dwh [~sc@h-67-100-122-88.sttnwaho.dynamic.covad.net] has quit [iridium.oftc.net charm.oftc.net]
19:42 -!- homebaum_ [~michael@wbar1.sea1-4-5-031-104.sea1.dsl-verizon.net] has quit [iridium.oftc.net charm.oftc.net]
19:42 -!- JViz [Anomaly@cpe-065-190-033-248.triad.res.rr.com] has quit [iridium.oftc.net charm.oftc.net]
19:42 -!- tessier_ [~treed@203.210.216.1] has quit [iridium.oftc.net charm.oftc.net]
19:42 -!- viewbee [~viewbee@198.146.4.74] has quit [iridium.oftc.net charm.oftc.net]
19:42 -!- Shaun [ndci@ip68-111-70-41.oc.oc.cox.net] has quit [iridium.oftc.net charm.oftc.net]
19:42 -!- knewt [~jmb@zeus.pimb.org] has quit [iridium.oftc.net charm.oftc.net]
19:42 -!- cdub [~chrisw@cdub.netrep.oftc.net] has quit [iridium.oftc.net charm.oftc.net]
19:42 -!- paavon [paavon@alpha.phnet.fi] has quit [iridium.oftc.net charm.oftc.net]
19:42 -!- drbyte [~cc2@c210-49-121-44.eburwd3.vic.optusnet.com.au] has quit [iridium.oftc.net charm.oftc.net]
19:42 -!- muli_ [~muli@alhambra.mulix.org] has quit [iridium.oftc.net charm.oftc.net]
19:44 -!- cdub [~chrisw@fw.osdl.org] has joined #xen
19:44 -!- paavon [paavon@alpha.phnet.fi] has joined #xen
19:44 -!- yarihm [~yarihm@80-218-6-139.dclient.hispeed.ch] has quit [Quit: Leaving]
19:52 -!- knewt [~jmb@zeus.pimb.org] has joined #xen
19:55 -!- cilkay [~cilkay@CPE00d0b743a22f-CM0011ae01fcbe.cpe.net.cable.rogers.com] has joined #xen
19:55 -!- tim [~tim@cpe-66-67-139-238.rochester.res.rr.com] has joined #xen
19:55 -!- homebaum_ [~michael@wbar1.sea1-4-5-031-104.sea1.dsl-verizon.net] has joined #xen
19:56 -!- viewbee [~viewbee@198.146.4.74] has joined #xen
19:56 -!- JViz [Anomaly@cpe-065-190-033-248.triad.res.rr.com] has joined #xen
19:57 -!- drbyte [~cc2@c210-49-121-44.eburwd3.vic.optusnet.com.au] has joined #xen
19:57 -!- knewt [~jmb@zeus.pimb.org] has quit [Remote host closed the connection]
19:57 -!- tessier_ [~treed@203.210.216.1] has joined #xen
19:58 -!- Arnald [~Arnald@81-86-116-102.dsl.pipex.com] has joined #xen
20:00 -!- dwh [~sc@h-67-100-122-88.sttnwaho.dynamic.covad.net] has joined #xen
20:02 -!- knewt [~jmb@p213.54.100.97.tisdip.tiscali.de] has joined #xen
20:10 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has quit [Quit: Quitting]
21:04 -!- muli [~muli@nesher3.haifa.il.ibm.com] has quit [Quit: My damn controlling terminal disappeared!]
21:05 -!- tessier [~treed@222.253.64.128] has quit [Read error: Connection reset by peer]
21:13 -!- movement [~moz@82.152.177.227] has quit [Ping timeout: 480 seconds]
21:25 -!- movement [~moz@82.152.177.227] has joined #xen
21:39 -!- muli_ [~muli@alhambra.mulix.org] has joined #xen
21:44 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
21:57 -!- dwh [~sc@h-67-100-122-88.sttnwaho.dynamic.covad.net] has quit [Ping timeout: 480 seconds]
21:59 < tessier_> hmmm
21:59 < tessier_> Anyone know anything about the IBM blade systems?
21:59 < tessier_> They have some interesting partitioning and clustering technology in them.
22:00 < hollis> the x86 or PPC blades?
22:00 < hollis> the PPC blades are not partitionable
22:00 < hollis> I guess you could install VMware on the x86 blades, but aside from that...
22:01 < tessier_> x86 blades
22:01 < hollis> what partitioning technology are you referring to?
22:01 < tessier_> A friend of mine has one at work. $100k for 14 blades with 2 cpu's each. Runs ESX server, a modified version of Linux
22:02 < tessier_> All of the blades can be clustered together. Then you can partition it back out arbitararily, apparently. The virtual machine instances use vmware it seems. So you can run any OS that runs under vmware. I wonder if that has the same performance limitations as the ones in the paper that studied xen vs vmware.
22:06 -!- dwh [~sc@h-67-100-122-88.sttnwaho.dynamic.covad.net] has joined #xen
22:41 < knewt> ah, so nothing special with them being blades then. you could do exactly the same with any set of 14 2-way computers and the same software
22:43 < tessier_> Apparently they can cluster all of the cpu's together to look like one big computer. I think the blades might have some high-speed interconnect.
22:43 < hollis> I don't believe these blades do
22:44 < tessier_> Interesting. My friends and I in #kernel-panic were speculating if they were using MOSIX or something to cluster the blades.
22:44 < hollis> why don't you ask your friend? :)
22:48 < knewt> i wouldn't imagine you could assign more than 2 cpu's to any individual virtual machine, as that's not something esx can do, even with the vsmp add-on. really sounds just like perfectly normal esx server to me
22:50 < knewt> (well, esx server plus the vsmp add-on plus the VirtualCenter add-on)
23:24 -!- dwh [~sc@h-67-100-122-88.sttnwaho.dynamic.covad.net] has quit [Ping timeout: 480 seconds]
23:27 -!- liberie [~root@dsl027-160-029.atl1.dsl.speakeasy.net] has joined #xen
23:39 -!- dwh [~sc@c-24-21-82-55.hsd1.or.comcast.net] has joined #xen
--- Log closed Mon May 23 23:59:01 2005