From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <13426df10612031926y40478bdah80a63496bff45756@mail.gmail.com> Date: Sun, 3 Dec 2006 20:26:50 -0700 From: "ron minnich" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Xen 3.0.3 In-Reply-To: <13426df10612031813o5b2a3bf0if3ba05abd42f8b73@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <13426df10612031813o5b2a3bf0if3ba05abd42f8b73@mail.gmail.com> Topicbox-Message-UUID: e9cfc5ba-ead1-11e9-9d60-3106f5b1d025 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