[9fans] hotels for iwp9

[9fans] hotels for iwp9

[Francisco J Ballesteros]

Hi,

we updated the web page with information regarding a suggested hotel for IWP9
and pointers for a local travel agency.

See http://lsub.org/iwp9/ for details.

In few words, any hotel near the Madrid Atocha train station would be
a great choice.

If anyone has any problem regarding this, please, let us know.

best regards

Re: [9fans] hotels for iwp9

[Bruce Ellis]

"Puerta de Toledo" Hotel seems to be the go.  You can get a
good price if you look.  I'm annoyed that skip got it a dollar
cheaper than me, crafty man he is.

brucee

On 11/1/06, Francisco J Ballesteros <nemo@lsub.org> wrote:
> Hi,
>
> we updated the web page with information regarding a suggested hotel for IWP9
> and pointers for a local travel agency.
>
> See http://lsub.org/iwp9/ for details.
>
> In few words, any hotel near the Madrid Atocha train station would be
> a great choice.
>
> If anyone has any problem regarding this, please, let us know.
>
> best regards
>

Re: [9fans] hotels for iwp9

[Skip Tavakkolian]

> I'm annoyed that skip got it a dollar
> cheaper than me, crafty man he is.

i'll be spending my savings on cigars.

Re: [9fans] hotels for iwp9

[Bruce Ellis]

tapas fight!

On 11/1/06, Skip Tavakkolian <9nut@9netics.com> wrote:
> > I'm annoyed that skip got it a dollar
> > cheaper than me, crafty man he is.
>
> i'll be spending my savings on cigars.

Re: [9fans] hotels for iwp9

[Gorka guardiola]

Madrid is short for places in hotels. Be sure you book as possible.

On 10/31/06, Francisco J Ballesteros <nemo@lsub.org> wrote:
> Hi,
>
> we updated the web page with information regarding a suggested hotel for IWP9
> and pointers for a local travel agency.
>
> See http://lsub.org/iwp9/ for details.
>
> In few words, any hotel near the Madrid Atocha train station would be
> a great choice.
>
> If anyone has any problem regarding this, please, let us know.
>
> best regards
>


-- 
- curiosity sKilled the cat

[9fans] Xen 3.0.3

[Richard Miller]

For those interested in Xen: a new "stable" version 3.0.3 has been
released.  Plan 9 guest kernels built for 3.0.2 will also work with
3.0.3.  However there are some incompatible changes to the
/usr/include/xen headers.  So if you want to recompile a Plan 9 guest
kernel with the Xen 3.0.3 headers, you should update mkfile and cppx
from sources/xen/xen3/9/xen3 first, to get a version which can be
used with either 3.0.2 or 3.0.3 Xen headers.

-- Richard

Re: [9fans] Xen 3.0.3

[ron minnich]

Richard,

I've got your xen 3.0.3 up but, as usual, am totally baffled by xen
networking (I worked this out once, but lost all my scripts in a hard
drive disaster).

How are you doing networking? bridged or routed? have any handy
scripts I could see?

Do you run venti in its own domain?

thanks

ron

Re: [9fans] Xen 3.0.3

[Georg Lehner]

"ron minnich" <rminnich@gmail.com> writes:

> Richard,
>
> I've got your xen 3.0.3 up but, as usual, am totally baffled by xen
> networking (I worked this out once, but lost all my scripts in a hard
> drive disaster).
>
> How are you doing networking? bridged or routed? have any handy
> scripts I could see?

Just complemented:

  http://www.magma.com.ni/moin/Plan9Tutorial/XenInstall

with the xend-config.sxp from my setup, so the Tutorial should give
all needed details.

Nothing specially crafted though, it just works for me.

>
> Do you run venti in its own domain?
...

I guess that this would reduce performance, since Networking is not
particularily fast in Xen.


Regards,

    Jorge-León

Re: [9fans] Xen 3.0.3

[ron minnich]

I am copying this xen stuff to the list as I think we need it in the archives.

I have followed the tutorial at
http://www.magma.com.ni/moin/Plan9Tutorial/XenInstall and things are
indeed better -- my venti is up and alive.

But as always, the rub with xen is the networking.

xm list shows this:
[root@q rminnich]# xm list
Name                                      ID Mem(MiB) VCPUs State   Time(s)
Domain-0                                   0      906     1 r-----    196.5
plan9                                      2       96     1 ------     89.9




and brctl shows this:
bridge name     bridge id               STP enabled     interfaces
xenbr0          8000.feffffffffff       no              peth0
                                                        vif0.0
                                                        vif2.0

So things are nicely bridged together.

With a bridge, it is as  though they're on the same wire.  Sort of.

(for those of you who don't recall, a bridge was a two-port device
that could be used as a mac-level connection between two networks. I
used to use them to isolate clusers from a main network, such that
intra-cluster traffic did not bleed off to the backbone -- this was in
the days of 10 mbit ethernet.)

At the same time, Linux bridges don't work like the good old hardware
ones, I have a thread I found long ago between me and some of the xen
guys discussing this. ...

OK, so Plan 9 is domain 2, and hence vif2.0 is the dom0 side of it:
[root@q rminnich]# ifconfig vif2.0
vif2.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
          inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:20 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:11520 (11.2 KiB)  TX bytes:0 (0.0 b)

note that they only give it an IPV6 adress, and it runs NOARP, a few
funny bits there.

I also do this:
[root@q rminnich]# echo 1 > /proc/sys/net/ipv4/ip_forward


an ipconfig from Plan 9 side gets this:
[root@q rminnich]# tcpdump -i vif2.0
tcpdump: WARNING: vif2.0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vif2.0, link-type EN10MB (Ethernet), capture size 96 bytes
21:06:16.033763 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 50:6c:61:6e:39:00, length: 548
21:06:20.032192 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 50:6c:61:6e:39:00, length: 548
21:06:24.043403 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 50:6c:61:6e:39:00, length: 548


etc.

Now my wireless router is 192.168.0.1. This linux host is
192.168.0.103. So in Plan 9 dom2 I do this:
 ip/ipconfig -g 192.168.0.1 ether /net/ether0 192.168.0.99 255.255.255.0

So I make the router my gateway.

And I can now ping the 192.168.0.1, such fun.

Xen docs do recommend that you hardwire the IP for a domU, not use
dhcp, so I guess I'll do that.

What's amusing is that I can NOT ping the dom0 linux box ... i.e. the
box I am running on: tcpdump sez:
21:15:41.641627 IP 192.168.0.99 > 192.168.0.103: icmp 44: echo request seq 5857

So I've got a bit more setup to do. Once this sort of works, I will
upate the wiki.

ron

Re: [9fans] Xen 3.0.3

[ron minnich]

On 12/3/06, Richard Miller <9fans@hamnavoe.com> wrote:

> I haven't changed anything in the scripts which are installed
> by Xen, and it "just works" for me.  It seems to be bridged - the
> guest's virtual ethernet address is exposed to the outside world
> by the host.  I just run ip/ipconfig on the virtual Plan 9 machine,
> and it's given an IP address by my normal dhcp server running
> on another machine.

damn. It won't work for me at all.

Do you have your /lib/ndb/local handy? Or does the installed one "just work".

More linux distro diffs, I bet: what did you install under?

can you do an ifconfig -a and send it to me?

thanks

ron

Re: [9fans] Xen 3.0.3

[Richard Miller]

> How are you doing networking? bridged or routed? have any handy
> scripts I could see?

I haven't changed anything in the scripts which are installed
by Xen, and it "just works" for me.  It seems to be bridged - the
guest's virtual ethernet address is exposed to the outside world
by the host.  I just run ip/ipconfig on the virtual Plan 9 machine,
and it's given an IP address by my normal dhcp server running
on another machine.

> Do you run venti in its own domain?

No, so far I have only tried a single Plan 9 domain.  I suppose
you might gain some security by putting venti in a different
vm but it would cost you some efficiency.  I might try the
experiment some time.