TheGrebs.com:IRC Logs:#xen:2006:06:28

---	Log	opened Wed Jun 28 00:00:50 2006
00:52	<tessier>	Anyone from unixshell.com in here?
00:52	<tessier>	I know they have been having some serious problems with their xen servers.
00:52	<tessier>	They just offered all of their xen customers free migration to virtuozzo systems
00:52	<tessier>	Not exactly a ringing endorsement for xen. :(
00:52	<tessier>	I've had really good luck with xen so far. I wonder what their problems have been.
00:55	<am88b>	interesting
00:56	<am88b>	maybe you could ask them? Esp. if you are a cclient...
01:02	<am88b>	I was just planning to use Xen in production myself, I'd be very interested to know if it wouldn't work
01:03	<tessier>	I am a client and I did ask them. No reply yet but it was just a 8 hours ago. They were probably already out of the office.
01:03	<tessier>	I am setting up a big Xen/AoE cluster. We are quite excited about it.
01:04	<tessier>	Might be able to move all of our infrastructure to it and really cut down on number of machines.
01:04	<am88b>	have you done any testing yet?
01:05	<tessier>	I have been running xen for about a year. So far so good. I did bite myself in the ass by mounting a filesystem which belonged to a saved xen domain though. Caused serious corruption. A lesson learned.
01:05	<tessier>	I haven't tested Xen with AoE yet though. That will be the big challenge with this setup I think.
01:05	<tessier>	Supposedly it works well now.
01:06	<tessier>	My boss is pretty excited to see what it can do.
01:47	\|-\|	mastermind [~mastermin@mastermind.kaltenbrunner.cc] has quit [Quit: Client exiting]
01:59	\|-\|	visik7 [~visi@155.185.28.178] has joined #xen
02:00	\|-\|	Tv [~tv@GMMDXXVII.dsl.saunalahti.fi] has quit [Quit: foo]
02:13	\|-\|	Shoragan_ [~shoragan@d072.apm.etc.tu-bs.de] has joined #xen
02:15	\|-\|	visik7 [~visi@155.185.28.178] has quit [Remote host closed the connection]
02:15	<hensema>	tessier: why AoE and not iSCSI?
02:15	\|-\|	visik7 [~visi@155.185.28.178] has joined #xen
02:19	\|-\|	parabelboi [~parabelbo@blueice3n1.de.ibm.com] has joined #xen
02:27	\|-\|	avdyk [~avdyk@vbstefi118.fapse.ulg.ac.be] has joined #xen
02:29	<tessier>	hensema: AoE is much faster and simpler. Much lower overhead and easier to configure.
02:29	<tessier>	AoE spec is 8 pages.
02:29	<tessier>	iSCSI spec is hundreds.
02:30	<tessier>	AoE is not routable either which is desirable for security.
02:30	<hensema>	yes, but AoE doesn't seem very flexile
02:30	\|-\|	Tv [~tv@i1.inoi.fi] has joined #xen
02:30	<tessier>	Flexible? It presents block devices from one machine to another. What more could you ask?
02:30	<hensema>	there doesn't even seem to be a AoE server for linux, just for some hardware devices sharing entire IDE drives over the net
02:31	<hensema>	I just want a big raid array chopped up in small chunks to be served over the net
02:38	\|-\|	rusty [~rusty@bh02i525f01.au.ibm.com] has quit [Quit: Ex-Chat]
02:40	<tessier>	There is an AoE server for Linux. It is called vblade.
02:40	<tessier>	And AoE client support is included with the standard stable Linux kernel.
02:46	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has joined #xen
03:10	\|-\|	tobi [~tobi@zux006-049-116.adsl.green.ch] has joined #xen
03:21	\|-\|	Basic_py [~Basic@fortress.tanners.org] has quit [Ping timeout: 480 seconds]
03:28	\|-\|	tobi [~tobi@zux006-049-116.adsl.green.ch] has quit [Quit: tobi]
03:31	\|-\|	Basic_py [~Basic@warden.real-time.com] has joined #xen
04:10	\|-\|	athomas [~athomas@host86-136-84-147.range86-136.btcentralplus.com] has joined #xen
04:11	\|-\|	Basic_py [~Basic@warden.real-time.com] has quit [Ping timeout: 480 seconds]
05:13	\|-\|	cableman [~cableman@3e6b42b0.rev.stofanet.dk] has joined #xen
05:20	\|-\|	avdyk [~avdyk@vbstefi118.fapse.ulg.ac.be] has quit [Ping timeout: 480 seconds]
06:03	\|-\|	horms [~horms@vagw.valinux.co.jp] has quit [Quit: Leaving]
06:28	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
06:47	\|-\|	sdague_ [~sdague@user-12lc6iq.cable.mindspring.com] has joined #xen
06:48	\|-\|	Netsplit iridium.oftc.net <-> xenon.oftc.net quits: JViz, sdague, zwane_work, wenchien, DV_, Dougie, dansmith, SNy, cableman, elisboa, (+3 more, use /NETSPLIT to show all of them)
06:53	\|-\|	cableman [~cableman@3e6b42b0.rev.stofanet.dk] has joined #xen
06:53	\|-\|	zwane_work [~zwane@S0106001217d33fa6.vc.shawcable.net] has joined #xen
06:53	\|-\|	elisboa [~elisboa@201.44.96.130] has joined #xen
06:53	\|-\|	DV_ [~veillard@veillard.com] has joined #xen
06:53	\|-\|	ns [~nivedita@c-67-171-181-157.hsd1.or.comcast.net] has joined #xen
06:53	\|-\|	JViz [Anomaly@adsl-065-013-131-023.sip.int.bellsouth.net] has joined #xen
06:53	\|-\|	Dougie [~Doug@shadow.idmf.net] has joined #xen
06:53	\|-\|	wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has joined #xen
06:53	\|-\|	SNy [935ff10299@bmx-chemnitz.de] has joined #xen
06:53	\|-\|	DV [~veillard@veillard.com] has joined #xen
06:53	\|-\|	bored2sleep [~bored2sle@66.111.53.150] has joined #xen
06:53	\|-\|	dansmith [~danms@bi01p1.co.us.ibm.com] has joined #xen
06:54	\|-\|	sdague_ changed nick to sdague
06:55	\|-\|	bernarde [~bernarde@32.104.18.240] has joined #xen
07:06	\|-\|	horms [~horms@p7209-ipbf22marunouchi.tokyo.ocn.ne.jp] has joined #xen
07:23	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Read error: Connection reset by peer]
07:23	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
07:29	\|-\|	avdyk [~avdyk@vbstefi118.fapse.ulg.ac.be] has joined #xen
07:41	\|-\|	riel changed nick to surriel
08:30	\|-\|	unriel changed nick to riel
08:54	\|-\|	avdyk [~avdyk@vbstefi118.fapse.ulg.ac.be] has quit [Quit: got to go :(]
08:54	\|-\|	Marco [~marco@249-174.surfsnel.dsl.internl.net] has joined #xen
08:54	\|-\|	hollisb [~hollisb@pixpat.austin.ibm.com] has joined #xen
09:00	\|-\|	robin [~rnorwood@nat-pool-rdu.redhat.com] has quit [Quit: Leaving]
09:00	\|-\|	Tv [~tv@i1.inoi.fi] has quit [Quit: foo]
09:05	\|-\|	riel [~riel@nat-pool-bos.redhat.com] has quit [Read error: Connection reset by peer]
09:16	\|-\|	rharper [~rharper@pixpat.austin.ibm.com] has joined #xen
09:18	\|-\|	_bernarde [~bernarde@32.104.18.240] has joined #xen
09:23	\|-\|	bernarde [~bernarde@32.104.18.240] has quit [Ping timeout: 480 seconds]
09:27	\|-\|	horms [~horms@p7209-ipbf22marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]
09:42	\|-\|	stekloff [~stekloff@pool-71-245-98-173.ptldor.fios.verizon.net] has quit [Quit: Leaving]
09:47	\|-\|	aliguori [~anthony@w-mob201-128-62-102-202.public.utexas.edu] has joined #xen
09:47	\|-\|	Tv [~tv@GMMDXXVII.dsl.saunalahti.fi] has joined #xen
09:57	\|-\|	aliguori [~anthony@w-mob201-128-62-102-202.public.utexas.edu] has quit [Quit: Ex-Chat]
09:57	\|-\|	robin [~rnorwood@nat-pool-rdu.redhat.com] has joined #xen
09:57	\|-\|	robin [~rnorwood@nat-pool-rdu.redhat.com] has quit [Quit: ]
10:01	\|-\|	bernarde_ [~bernarde@32.104.18.240] has joined #xen
10:08	\|-\|	_bernarde [~bernarde@32.104.18.240] has quit [Ping timeout: 480 seconds]
10:20	\|-\|	stekloff [~stekloff@bi01p1.co.us.ibm.com] has joined #xen
10:37	\|-\|	alekibango [~alekibang@r2ba8.chello.upc.cz] has quit [Ping timeout: 480 seconds]
10:43	\|-\|	visik7 [~visi@155.185.28.178] has quit [Quit: ]
11:17	\|-\|	cableman [~cableman@3e6b42b0.rev.stofanet.dk] has left #xen [Leaving]
11:17	\|-\|	riel [~riel@nat-pool-bos.redhat.com] has joined #xen
11:22	\|-\|	msinhore [~msinhore@correio.samurai.com.br] has joined #xen
11:23	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
11:30	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
11:34	\|-\|	Basic_py [~Basic@gatekeeper.real-time.com] has joined #xen
11:41	\|-\|	Basic_py [~Basic@gatekeeper.real-time.com] has quit [Quit: Leaving]
11:43	\|-\|	Basic_py [~Basic@gatekeeper.real-time.com] has joined #xen
11:51	\|-\|	athomas [~athomas@host86-136-84-147.range86-136.btcentralplus.com] has quit [Quit: Leaving]
11:56	\|-\|	mastermind [~mastermin@mastermind.kaltenbrunner.cc] has joined #xen
11:59	\|-\|	muli [~muli@87.69.40.180.cable.012.net.il] has joined #xen
12:14	\|-\|	mdday_ [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
12:14	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Read error: Connection reset by peer]
12:27	\|-\|	parabelboi [~parabelbo@blueice3n1.de.ibm.com] has quit [Read error: Connection reset by peer]
12:54	\|-\|	Netsplit arion.oftc.net <-> quasar.oftc.net quits: Hunger, lilo2, mejlholm, jforbes, lucca, hollisb, SLot, koki
12:55	\|-\|	Netsplit over, joins: hollisb
12:55	\|-\|	Netsplit over, joins: lucca, mejlholm
12:55	\|-\|	Netsplit over, joins: lilo2
12:55	\|-\|	Netsplit over, joins: Hunger, jforbes, SLot, koki
12:57	\|-\|	visik7 [~visi@host39-8.pool8260.interbusiness.it] has joined #xen
12:59	\|-\|	Z3R0`c00l [~zerocool@83.211.36.216] has quit [Read error: Connection reset by peer]
13:04	\|-\|	Z3R0`c00l [~zerocool@83.211.36.216] has joined #xen
13:17	\|-\|	athena [~athena@tor.noreply.org] has quit [Remote host closed the connection]
13:17	\|-\|	athena [hiddenserv@tor.noreply.org] has joined #xen
13:34	\|-\|	_bernarde [~bernarde@32.104.18.240] has joined #xen
13:34	\|-\|	bernarde_ [~bernarde@32.104.18.240] has quit [Read error: Connection reset by peer]
13:50	\|-\|	_bernarde [~bernarde@32.104.18.240] has quit [Remote host closed the connection]
13:52	\|-\|	athena [hiddenserv@tor.noreply.org] has quit [Remote host closed the connection]
13:55	\|-\|	tobi [~tobi@zux006-049-116.adsl.green.ch] has joined #xen
14:08	\|-\|	jimix [~jimix@ip139.152.45.216.suscom.net] has joined #xen
14:10	\|-\|	athena [hiddenserv@tor.noreply.org] has joined #xen
14:11	\|-\|	dykman [~dykman@bi-02pt1.bluebird.ibm.com] has quit [Read error: Connection timed out]
14:11	\|-\|	Z3R0`c00l [~zerocool@83.211.36.216] has quit [Read error: Connection reset by peer]
14:12	\|-\|	Z3R0`c00l [~zerocool@83.211.36.216] has joined #xen
14:15	\|-\|	dykman [~dykman@bi-02pt1.bluebird.ibm.com] has joined #xen
14:16	\|-\|	Z3R0`c00l [~zerocool@83.211.36.216] has quit [Read error: No route to host]
14:16	\|-\|	Z3R0`c00l [~zerocool@83.211.229.128] has joined #xen
14:31	\|-\|	zwane_work [~zwane@S0106001217d33fa6.vc.shawcable.net] has quit [Ping timeout: 480 seconds]
14:34	\|-\|	aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
14:40	\|-\|	robin [~rnorwood@nat-pool-rdu.redhat.com] has joined #xen
14:40	\|-\|	robin changed nick to robin_
14:47	\|-\|	Z3R0`c11l [~zerocool@83.211.229.128] has joined #xen
14:48	\|-\|	Z3R0`c00l [~zerocool@83.211.229.128] has quit [Read error: Connection reset by peer]
14:59	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has quit [Quit: Client exiting]
15:07	\|-\|	tobi [~tobi@zux006-049-116.adsl.green.ch] has quit [Quit: tobi]
15:07	\|-\|	tobi [~tobi@zux006-049-116.adsl.green.ch] has joined #xen
15:10	\|-\|	Z3R0`c00l [~zerocool@83.211.229.128] has joined #xen
15:11	\|-\|	Z3R0`c11l [~zerocool@83.211.229.128] has quit [Read error: No route to host]
15:16	\|-\|	FireRabbit [~eric@c-24-18-171-99.hsd1.mn.comcast.net] has joined #xen
15:16	<FireRabbit>	good afternoon
15:21	\|-\|	Z3R0`c00l [~zerocool@83.211.229.128] has quit [Read error: No route to host]
15:22	<FireRabbit>	i am trying to set up "routed" networking to my xen domains... right now, if i attempt to ping a domU from another machine, tcpdump shows the dom0 receives the packet (so i assume arp is working) however the domU never receives the packet
15:22	<FireRabbit>	ip_forward is set to 1
15:22	\|-\|	parabelboi [~parabelbo@port-87-234-138-223.dynamic.qsc.de] has joined #xen
15:23	<FireRabbit>	does anyone have any suggestions, and/or does anyone have "routed" networking working properly on their machine?
15:23	\|-\|	Z3R0`c00l [~zerocool@83.211.229.128] has joined #xen
16:25	<FireRabbit>	anyone around here?
16:32	<cdub>	hollisb: ping
16:33	<hollisb>	cdub: hi
16:35	<cdub>	hollisb: what do you do for ppc xen_ulong_t, do you translate those in hv?
16:35	<cdub>	hollisb: i get the feeling this is slowly coding into a corner, which is why i'm worried
16:36	<hollisb>	typedef uint64_t xen_ulong_t;
16:36	<hollisb>	that's what I'll do
16:36	<hollisb>	so it's always 64 bits, and doesn't change for 32- vs 64-bit userland
16:37	<hollisb>	AFAICS we're already in the corner; I'm trying to wiggle out
16:37	<cdub>	so you are taking advantage of no users?
16:37	<cdub>	i.e. half-clean slate
16:37	<hollisb>	yes, PPC has no users
16:37	<hollisb>	but I need to keep x86 in its current state
16:37	<hollisb>	I hope that one day (Xen 4?), people will get fed up with these little typedefs all over the place
16:38	<hollisb>	and fix the ABI when it opens up again
16:38	<visik7>	FireRabbit: are the 2 net on two separated network (I mean one on 10.0.0.1/24 10.0.0.2/24 ) ?
16:38	<FireRabbit>	visik7: what do you mean by "2 net"?
16:38	<cdub>	agreed, we are already in a corner, the interface is really poor, and needs to start over with properly sized and translatable (32 on 64)
16:38	<visik7>	FireRabbit: tell me the 2 net that goes from dom0 to dom1 and from dom0 to dom2
16:38	<FireRabbit>	there is no dom2
16:39	<visik7>	oh
16:39	<visik7>	another
16:39	<visik7>	ok
16:39	<aliguori>	is there such a thing as a statement of how long the current ABI will be supported?
16:39	<FireRabbit>	would you like to see the ifconfig on both the dom0 and domU?
16:39	<FireRabbit>	is that what you are asking?
16:39	<visik7>	FireRabbit: ok tell me the 2 net the one from dom0 to dom1 and the other from dom0 to the real network
16:39	<hollisb>	aliguori: I've heard 5 years. are you looking for that on a website or something?
16:40	<aliguori>	5 years?
16:40	<hollisb>	yes
16:40	<FireRabbit>	visik7: ifconfig?
16:40	<visik7>	no
16:40	<aliguori>	hollisb, no, rough idea was all i was looking for
16:40	<FireRabbit>	visik7: what do you mean by "net"
16:40	<hollisb>	aliguori: for the guest interface only, not including the dom0 stuff
16:40	<hollisb>	aliguori: but a binary guest today is supposed to run on the Xen of 5 years from now
16:40	<cdub>	this is just so damn ugly, and getting uglier...
16:41	<visik7>	FireRabbit: the address of the network e.g. 192.168.0.1/24 the network address is 192.168.0.0
16:41	<hollisb>	aliguori: which I believe is a stronger guarantee than the enterprise distros make
16:41	<aliguori>	hollisb, that seems a bit insane
16:41	<hollisb>	cdub: I know :/
16:41	<FireRabbit>	216.127.61.150 mask is 255.255.255.192
16:41	<hollisb>	aliguori: "ambitious" ;)
16:41	<FireRabbit>	the domU's IP is .151§
16:41	<FireRabbit>	the domU's IP is .151
16:41	<visik7>	FireRabbit: route -n of dom0 should be enougth
16:42	<cdub>	hollisb: we need a proper thunking layer
16:42	<cdub>	hollisb: compat hypercalls
16:43	<FireRabbit>	visik7: http://monoport.com/393
16:43	<cdub>	hollisb: that can go in right now w/out breaking anything since it's effectively on the side
16:43	<visik7>	let me see
16:43	<cdub>	hollisb: maybe i'm just dreaming...
16:44	<hollisb>	cdub: it could happen, and there's even the xen-compat.h stuff to help
16:44	<visik7>	FireRabbit: 255.255.255.255 ?
16:44	<FireRabbit>	visik7: this is what xen added.
16:44	<hollisb>	cdub: my problem about xen_memory_reservation in particular is that it's used by (ppc32) userland and (ppc64) kernel
16:44	<FireRabbit>	the vif-route script
16:44	<visik7>	mmm
16:44	<cdub>	that could take the pressure of the current (legacy) interface a bit
16:44	<visik7>	FireRabbit: the ip of the domU is ?
16:45	<visik7>	151 ?
16:45	<cdub>	ppc64 kernel knows that ppc32 userland is making hypercall
16:45	<visik7>	no
16:45	<cdub>	right?
16:45	<FireRabbit>	visik7: yes, 151
16:45	<visik7>	and of dom0 to domU ?
16:45	<FireRabbit>	you mean, of vif7.0 ?
16:45	<visik7>	yes
16:45	<FireRabbit>	the vif-route script copied the IP from eth0 to this vif... so it is .150
16:45	<visik7>	and they ping eachother ?
16:45	<FireRabbit>	yes
16:46	<hollisb>	cdub: yes. we could add an ioctl32 thing there
16:46	<FireRabbit>	packets are not going from eth0 --> vif7.0
16:46	<visik7>	FireRabbit: change netmask of the route
16:46	<FireRabbit>	to what?
16:46	<hollisb>	cdub: the reason I'd like to avoid that is because if we did that, there would be no incentive to fix the interface
16:46	<visik7>	.254
16:46	<cdub>	hollisb: what's the reaons against it?
16:46	<cdub>	hollisb: ah, heh (lag)
16:47	<hollisb>	cdub: right now e.g. there's this ugly XEN_GUEST_HANDLE stuff around, and every time I see that I wince
16:47	<cdub>	hollisb: how do you expect the fix to look like (in xen 4)
16:47	<FireRabbit>	how do I add that route?
16:47	<cdub>	hollisb: me too!
16:47	<visik7>	delete first the one that exists
16:47	<DV>	cdub: if you manage to garantee hypercall stability over long term I'm all ears !
16:47	<visik7>	and add the new
16:47	<FireRabbit>	ok, done.
16:48	<FireRabbit>	yes, but what is the command to add the route with the 254 netmask?
16:48	<hollisb>	cdub: just make it a fixed size. I think all these memory.h users don't actually need to be long at all
16:48	<cdub>	DV: sadly, that's not on the table here ;-/
16:48	<cdub>	DV: not from me anyway ;-)
16:48	<visik7>	route add -net 216.127.61.150 netmask 255.255.255.254 dev vif7.0
16:49	<cdub>	hollisb: so always keep a single interface that's constant size regardless of 32/64
16:49	<FireRabbit>	but my default gateway is 216.127.61.129 .. will this prevent me from being able to reach that? (through eth0)
16:49	<hollisb>	cdub: yup
16:49	<DV>	cdub: too bad :-)
16:49	<visik7>	FireRabbit: no, why should it ?
16:50	<cdub>	DV: heh, sorry
16:51	<hollisb>	cdub: note that I'm not even dealing with mismatched kernel/hypervisor
16:51	<FireRabbit>	hey cool.. that fixed it!
16:51	<hollisb>	cdub: only mismatched userland/hypervisor
16:51	<FireRabbit>	thank you very much visik7
16:51	<cdub>	hollisb: that was my next comment ;-)
16:51	<FireRabbit>	so.. is this a mistake in the xen network scripts that it adds the .255 route?
16:51	<visik7>	probably
16:51	<visik7>	check why
16:51	<aliguori>	hollisb, you know, this wouldn't be a problem is userspace didn't make hypercalls directly...
16:51	<aliguori>	it's kind of silly in the first place
16:52	<cdub>	aliguori: well it's already slightly indirect
16:52	<hollisb>	aliguori: agreed on the first point. I'm not sure if you want the kernel doing the hypercall structure packing though
16:53	<cdub>	aliguori: it's not exactly fast path in most (all?) cases
16:53	<FireRabbit>	visik7: oh, i bet ifconfig is adding that route ... because the netmask of the interface is 255.255.255.255
16:53	<cdub>	hollisb: it doesn't have to
16:53	<aliguori>	cdub, i suspect that long term we'd like to provide a kernel-controlled interface to userspace instead of just passing through the xen one
16:53	<aliguori>	you'd think the kernel would want to control that interface...
16:53	<cdub>	hollisb: it can just route to a differnet hypercall page
16:54	<cdub>	aliguori: nod
16:54	<cdub>	aliguori: it's part of the problem.
16:54	<cdub>	aliguori: the further you expose the ABI, the harder to change
16:54	<aliguori>	cdub, yeah, i think that's the pain we're feeling now
16:54	<hollisb>	that's certainly true
16:54	<cdub>	DV: sounding familiar? well-abstracted interface
16:55	<aliguori>	hollisb, strictly speaking, if the hypervisor only runs same-bitness guests, it's strange to force it's interface to be 32/64 bit safe
16:55	<cdub>	aliguori: we can get over that someday (w/out HVM) someday ;-)
16:56	<aliguori>	it would be nice to support mixing guests and hypervisors too though :-)
16:56	<DV>	cdub: interface design :-\
16:56	<aliguori>	cdub, yeah, someday...
16:56	<DV>	hi Anthony
16:56	<cdub>	heh
16:56	<hollisb>	aliguori: you would think so, except 1) goals change, and 2) there's a userland/hypervisor interface to consider as well (not just kernel/hypervisor)
16:56	<aliguori>	DV: howdy
16:56	<DV>	technically it's midnight here
16:57	<aliguori>	hollisb, yes, but as you know, i don't think there should be a userland/hypervisor interface :-)
16:57	<cdub>	DV: btw, when you get up too early, you don't need to stay up too late ;-)
16:57	<aliguori>	DV: burning the midnight oil i see :-)
16:57	<hollisb>	aliguori: ok :)
16:57	<DV>	aliguori: started commiting proxy code to libvirt, not yet functional though, but in CVS
16:57	<aliguori>	DV: I suspect that was painful for you to do wasn't it :-)
16:57	<FireRabbit>	visik7: can you explain why i add the route for .150 and not .151?
16:58	<DV>	yeah, coding is painful, until it gets exciting :-)
16:58	<cdub>	hollisb: what do you mean, '1) goals change'
16:58	<visik7>	to explain this I've to explain how networking works
16:58	<visik7>	:)
16:58	<FireRabbit>	heheh ok
16:58	<aliguori>	DV: i meant that you were so opposed to having a proxy :-)
16:58	<DV>	aliguori: once my mind is set I have no regrets, if that's what you were pointing at :-)
16:58	<hollisb>	cdub: people didn't want PAE support for Xen in the past, and then they changed their minds...
16:58	<aliguori>	heh
16:58	<cdub>	hollisb: ahh, i see, yes
16:59	<DV>	aliguori: I'm an old fart but I can still change my mind
16:59	<DV>	aliguori: well considering the timing and technical constraints, that was the best solution, so ...
16:59	<aliguori>	DV: i was thinking about a proxy the other day.. i'm updating cvs right now. my original thought was to just have the proxy filter but i've become increasingly concerned about that
16:59	<visik7>	FireRabbit: btw you need to specify the lower ip of the network and the netmask that specify which host are on the network apt-get install ipcalc and run ipcalc 216.127.61.150/31 and you should understand
17:00	<aliguori>	i'm not sure how well the python xml-rpc stuff validates the packets
17:00	<aliguori>	a malformed xml-rpc packet may still get through (like if it has two methodnames or something)
17:00	<DV>	aliguori: communication lib-proxy won't be http, I expect just local stuff
17:00	<cdub>	hollisb: ok, thanks for clarifying. you have the tough position on ppc
17:01	<FireRabbit>	visik7: ok, i understand that.
17:01	<DV>	aliguori: and once you're having root access, well hypervisor and httpu to xend
17:01	<aliguori>	DV: sure, but local privilege escalation is still a Bad Thing :-)
17:01	<hollisb>	cdub: yeah, it's been quite a ride so far
17:01	<cdub>	hollisb: hehe
17:01	<aliguori>	DV: are you proxying s-expr btw?
17:02	<aliguori>	s-expr/http that is
17:02	<DV>	aliguori: no, no need to. The calls which are allowed don't need S-Expr
17:02	<aliguori>	libvirt isn't using xml-rpc yet is it?
17:02	<DV>	aliguori: no, kzak looked at it after you, it's in CVS but not plugged
17:02	<FireRabbit>	what confuses me is that 216.127.61.150/31 and 216.127.61.151/32 should have the same effect in this case, because the host i want to route to falls under both.
17:03	<FireRabbit>	it seems that*
17:03	<DV>	aliguori: will have to be done though
17:03	<aliguori>	DV: yes, i've been sitting on some patches that remove a few kslocs from xend to get rid of the s-expression stuff
17:03	<DV>	there is like 5 different ways to attack Xen API wise, not any one fully satisfactory
17:04	\|-\|	riel changed nick to unriel
17:04	<aliguori>	DV: the whole xen-api discussion doesn't help either.. it's hard to make a big change like this when the future is so uncertain
17:04	<DV>	aliguori: well :-) do you really trust the XML code more ;-)
17:04	[~]	aliguori may be a little bias :-)
17:05	<DV>	aliguori: I'm getting very biased ... which is fine since the other side is too
17:06	<DV>	aliguori: anyway my opinion is neglectible. There are deadline and existing code facts, and it's all that matters at some point, fine by me I'm an engineer
17:06	<aliguori>	i see, so you implement your own protocol for the proxy
17:06	<DV>	yeah ... it's nearly an habit at this point
17:07	<visik7>	FireRabbit: the problem is that vif7.0 address mismatch with the route
17:07	<DV>	must be the 3rd or 4th time I write such code
17:07	<FireRabbit>	OH
17:07	<aliguori>	DV: virt-manager is pretty nice btw
17:07	<visik7>	'couse 216.127.61.150/32 is outside 216.127.61.151/32
17:07	<FireRabbit>	of course.. right right.
17:07	<aliguori>	i was playing with it this afternoon.. good example of the usefulness of libvirt
17:07	<DV>	aliguori: tell danpb :-)
17:07	<aliguori>	already have :-)
17:07	<visik7>	the reason should be this I'm not absolutly secure but should be
17:08	<DV>	great :-)
17:08	<aliguori>	hollisb, you think keir will get on irc now? :-)
17:08	<visik7>	FireRabbit: probably other OSes act in a different way (or not dunno really) btw increase the netmask in ifconfig and anything should works ok isn't it ?
17:09	<FireRabbit>	so with this configuration, what will I do if I add another domU who has the IP of .152 ? a /31 route wont work for that, if the vif has a .150 IP
17:09	<hollisb>	aliguori: sadly no. I was encouraging other people who may be reading...
17:09	<visik7>	FireRabbit: another domU means another vif
17:09	\|-\|	stekloff [~stekloff@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
17:09	<aliguori>	ah, i see
17:09	<visik7>	routed env act in this way :)
17:10	<FireRabbit>	visik7: yes but... XEN copies the .150 IP to every vif.
17:10	<visik7>	mmm
17:10	<visik7>	dunno really
17:10	<cdub>	hollisb: hmm, you know, a 32-bit compat interface could be 64-bit clean
17:10	<visik7>	I don't use Xen I just interested in the project :)
17:10	<FireRabbit>	oh hehe.. well i appreciate your help..
17:10	<visik7>	or to be more exactly I've used xen but was 2.0.3
17:11	<visik7>	in switched mode
17:11	\|-\|	Shoragan_ [~shoragan@d072.apm.etc.tu-bs.de] has quit [Quit: Leaving]
17:11	<FireRabbit>	it seems that using a bridge is the recommended method to do networking.. but that wasn't working properly on my system, for some reason.
17:12	\|-\|	aliguori [~anthony@pixpat.austin.ibm.com] has quit [Quit: Ex-Chat]
17:16	<visik7>	FireRabbit: try don't using xen scripts
17:16	<visik7>	and do it by your own
17:16	<visik7>	shouldn't be difficult
17:16	<FireRabbit>	yeah
17:16	<FireRabbit>	ill look into it
17:18	<FireRabbit>	the scripts are supposed to do some crazy renaming of interfaces, but it wasnt happening properly
17:19	<hollisb>	cdub: how do you mean?
17:20	<cdub>	hollisb: introduce a 32-bit compat interface, which is actually the 'right fixed size' interface
17:20	<cdub>	hollisb: so, in reality, it's 64-bit safe too
17:21	<hollisb>	cdub: I don't know what you mean by "32-bit compat interface"
17:21	<cdub>	hollisb: hypercall page which is used by 32-bit users on 64-bit
17:22	<cdub>	hollisb: like syscall32 in linux
17:22	\|-\|	mdday_ [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday_]
17:22	<hollisb>	I'm familiar with the ioctl translation hackery Linux does
17:22	<cdub>	hollisb: and the associated compat layer (fs/compat, etc..)
17:23	<hollisb>	but I'm not a fan of requiring translation when I don't have to
17:23	<cdub>	so hypercall32
17:23	<cdub>	hollisb: that's my point
17:23	<hollisb>	I guess I'm missing it
17:24	<cdub>	that interface can be new (no existing users, new ABI)
17:24	<cdub>	and could have properly defined sizes for structures
17:24	<hollisb>	hmm
17:25	<hollisb>	you're thinking of defining a new "32-bit" hypercall number for every hypercall?
17:26	<cdub>	yeah, although the number isn't critical
17:26	<cdub>	could be the same numbers if the jump is from a new hypercall page
17:27	<hollisb>	PPC Linux doesn't have a hypercall page, so I don't think that could apply to us
17:27	<cdub>	ok, so a new number then
17:28	<hollisb>	yeah
17:28	<cdub>	why don't you have a hypercall page?
17:28	<cdub>	just didn't get around to it yet?
17:28	<hollisb>	we have function pointers, which allow us to run the same kernel binary on various classes of hardware, POWER Hypervisor, Xen, ...
17:29	<hollisb>	and we've had it far longer than you x86 people ;)
17:29	<cdub>	lol
17:29	<hollisb>	really the only difference is that our hcalls are just normal functions, not contained within a special memory area
17:30	<hollisb>	the one advantage I can see to the special area is that hypervisors could overwrite that to migrate between systems
17:30	<hollisb>	without kernel involvement
17:31	<cdub>	without the paravirt_ops like rusty is proposing it allows for running on native as well
17:32	\|-\|	Basic_py [~Basic@gatekeeper.real-time.com] has quit [Quit: Leaving]
17:36	<hollisb>	yeah
17:36	<cdub>	well, and hvm
17:40	\|-\|	DV_ [~veillard@veillard.com] has quit [Ping timeout: 480 seconds]
17:40	\|-\|	DV [~veillard@veillard.com] has quit [Ping timeout: 480 seconds]
17:43	\|-\|	aliguori [~anthony@cpe-70-116-9-243.austin.res.rr.com] has joined #xen
17:44	\|-\|	womble [~mpalmer@106.135.233.220.exetel.com.au] has joined #xen
17:48	\|-\|	hollisb [~hollisb@pixpat.austin.ibm.com] has quit [Quit: leaving]
17:50	\|-\|	DV [~veillard@veillard.com] has joined #xen
17:50	<movement>	damn I missed hollis
17:50	\|-\|	DV_ [~veillard@veillard.com] has joined #xen
17:51	<movement>	what's the problem with "unsigned long" ??
17:51	\|-\|	tobi [~tobi@zux006-049-116.adsl.green.ch] has quit [Quit: tobi]
17:53	<movement>	never mind.
17:54	\|-\|	rharper [~rharper@pixpat.austin.ibm.com] has quit [Quit: Leaving]
18:39	\|-\|	horms [~horms@vagw.valinux.co.jp] has joined #xen
18:54	\|-\|	tessier__ [~treed@gw.drjays.com] has quit [Quit: Leaving]
18:55	\|-\|	visik7 [~visi@host39-8.pool8260.interbusiness.it] has quit [Remote host closed the connection]
18:55	\|-\|	tessier__ [~treed@gw.drjays.com] has joined #xen
19:21	\|-\|	Basic_py [~Basic@warden.real-time.com] has joined #xen
20:08	\|-\|	rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
20:30	<aliguori>	howdy rusty
20:30	<rusty>	aliguori: hi!
20:43	\|-\|	knewt [jmb@82.153.157.153] has quit [Ping timeout: 480 seconds]
20:46	\|-\|	knewt [jmb@home.pimb.org] has joined #xen
20:55	\|-\|	movement [~moz@82.152.210.159] has quit [Ping timeout: 480 seconds]
21:05	\|-\|	movement [~moz@82.152.192.196] has joined #xen
21:24	\|-\|	Hunger [Hunger.hu@Hunger.hu] has quit [Quit: changing servers]
21:26	\|-\|	Hunger [Hunger.hu@Hunger.hu] has joined #xen
22:13	\|-\|	zwane_work [~zwane@S0106001217d33fa6.vc.shawcable.net] has joined #xen
22:30	\|-\|	jimix [~jimix@ip139.152.45.216.suscom.net] has quit [Quit: jimix]
22:32	\|-\|	zwane [~zwane@S0106001217d33fa6.vc.shawcable.net] has joined #xen
22:59	\|-\|	VS_ChanLog [~stats@ns.theshore.net] has left #xen [Rotating Logs]
22:59	\|-\|	VS_ChanLog [~stats@ns.theshore.net] has joined #xen
23:08	\|-\|	muli [~muli@87.69.40.180.cable.012.net.il] has quit [Remote host closed the connection]
---	Log	closed Thu Jun 29 00:00:32 2006