RE: BUG? domu network interface configuration

RE: BUG? domu network interface configuration

[Ian Pratt]

 
> > One fix would be for you to just hack the hotplug script. Another, 
> > slightly better, way would be to grep around in xend's 
> config script 
> > to find out what script should be run, and call that. We might even 
> > take that as an interim patch.

Can you confirm that things work OK if you rename vif-route to
vif-bridge? 

> Any idea when this would be implemented?

Getting this cleaned up is important.

Ian

Re: BUG? domu network interface configuration

[Michal Ostrowski]

[-- Attachment #1.1: Type: text/plain, Size: 1729 bytes --]

The immediate problem is in fact that vif-bridge is being called instead of 
vif-route.

I'm working on something like the following to detect the script: 

SCRIPT=/bin/false
if [ -r $CONFIG_FILE ]; then
    SCRIPT=$(sed -e '/^[^#]*vif-script/!d;s/^(vif-script *\([^ )]*\)).*$/\1/' \
		$CONFIG_FILE)
fi

if [ -z "`which $SCRIPT`" ] ; then
    # not in path, should probably log an error
    exit
fi

As you can see, sxp is not very script friendly.

Having been able to call vif-route, is just the beginning of the real problems...

Once I'm in vif-route I need to get the IP address that I assigned to the partition.

To get that I need to figure out the domain id.  (I suppose I could guess that from 
the device name.)

Then I need to find the SXP config file in xenstore (and now I need a
tool to parse it and extract the "(ip a.b.c.d)" statement), but I don't
see a way of doing that because there seem to be no scripting tools to
access xenstore.

Now, even if I did have such a tool, I don't see a way of going from
domain id to uuid, which is what I think I need in order to interact
with xenstore.

-- 
Michal Ostrowski




On Wed, 31 Aug 2005 13:01:29 +0100
"Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> wrote:

>  
> > > One fix would be for you to just hack the hotplug script. Another, 
> > > slightly better, way would be to grep around in xend's 
> > config script 
> > > to find out what script should be run, and call that. We might even 
> > > take that as an interim patch.
> 
> Can you confirm that things work OK if you rename vif-route to
> vif-bridge? 
> 
> > Any idea when this would be implemented?
> 
> Getting this cleaned up is important.
> 
> Ian


[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: BUG? domu network interface configuration

[Christian Limpach]

On 8/31/05, Michal Ostrowski <mostrows@watson.ibm.com> wrote:
> I'm working on something like the following to detect the script:

That would be a good stop-gap...

> Having been able to call vif-route, is just the beginning of the real problems...
>
> Once I'm in vif-route I need to get the IP address that I assigned to the partition.
> 
> To get that I need to figure out the domain id.  (I suppose I could guess that from
> the device name.)
> 
> Then I need to find the SXP config file in xenstore (and now I need a
> tool to parse it and extract the "(ip a.b.c.d)" statement), but I don't
> see a way of doing that because there seem to be no scripting tools to
> access xenstore.
> 
> Now, even if I did have such a tool, I don't see a way of going from
> domain id to uuid, which is what I think I need in order to interact
> with xenstore.

The solution we envision looks like this:
- xenbus adds a hotplug environment variable to its devices which
indicates the path in the store where the device configuration
information is stored
- we implement a simple tool to read/write values in the store from
the command line
- xend puts the additional device configuration information in the
store as seperate nodes
- we extend the hotplug script to read device configuration
information out of the store using the path from the environment
variable and then use this information to run the right script with
arguments

We'll also use something similar to fix file: support and use the
hotplug infrastructure to effectively move file: setup out of xend
into the backend domain.

    christian

Re: BUG? domu network interface configuration

[Nivedita Singhvi]

Michal Ostrowski wrote:
> The immediate problem is in fact that vif-bridge is being called instead of 
> vif-route.
> 
> I'm working on something like the following to detect the script: 
> 
> SCRIPT=/bin/false
> if [ -r $CONFIG_FILE ]; then
>     SCRIPT=$(sed -e '/^[^#]*vif-script/!d;s/^(vif-script *\([^ )]*\)).*$/\1/' \
> 		$CONFIG_FILE)
> fi
> 
> if [ -z "`which $SCRIPT`" ] ; then
>     # not in path, should probably log an error
>     exit
> fi
> 
> As you can see, sxp is not very script friendly.

The above isn't going to be sufficient.

> Having been able to call vif-route, is just the beginning of the real problems...

Right.

> Once I'm in vif-route I need to get the IP address that I assigned to the partition.

Would have been nice to get some head's up on the hotplug
stuff going in so we could test for various networking situations.

> To get that I need to figure out the domain id.  (I suppose I could guess that from 
> the device name.)
> 
> Then I need to find the SXP config file in xenstore (and now I need a
> tool to parse it and extract the "(ip a.b.c.d)" statement), but I don't
> see a way of doing that because there seem to be no scripting tools to
> access xenstore.

We're trying to come up with a temporary hack to work around this
right now.

> Now, even if I did have such a tool, I don't see a way of going from
> domain id to uuid, which is what I think I need in order to interact
> with xenstore.

Can't do it this way :(.

thanks,
Nivedita

Re: BUG? domu network interface configuration

[Michal Ostrowski]

[-- Attachment #1.1: Type: text/plain, Size: 6759 bytes --]

I've managed to get vif-route working again, but it requires some changes.

Patch is attached below (posted for sake of discussion, I don't expect
all of this to be immediately applicable).

First, I've added a new tool "sxp_get", which extract data from sxp
formatted data and presents it in a format that is usable in shell
scripts.

Also, my scripts depend on an up-to-date version of vm-tools (vm-xs in
particular), to be able to extract data from xenstored.


Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com>


--- a/tools/examples/backend.hotplug	Wed Aug 31 23:22:45 2005
+++ b/tools/examples/backend.hotplug	Thu Sep  1 22:14:10 2005
@@ -3,15 +3,37 @@
 #DEVPATH=/devices/xen-backend/vif-1-0
 #ACTION=add
 
-PATH=/etc/xen/scripts:$PATH
+export PATH=/etc/xen/scripts:$PATH
+
+CONFIG_FILE=/etc/xen/xend-config.sxp
+SCRIPT=/bin/false
+if [ -r $CONFIG_FILE ]; then
+    tmp=$(sxp_get vif-script <$CONFIG_FILE)
+    SCRIPT=${tmp#*=}
+fi
+
+if [ -z "$(which $SCRIPT)" ] ; then
+    # not in path, should probably log an error
+    exit
+fi
 
 DEV=$(basename "$DEVPATH")
+
+# DEV is of the form vif-x-y.  This extracts "x"
+idx=${DEV%-*}
+idx=${idx#*-}
+
+dom0_uuid=$(vm-xs -f /domain id 0)
+domU_uuid=$(vm-xs -f /domain/${dom0_uuid}/backend/vif 0/frontend-id $idx)
+
+domain=$(vm-xs -g /domain/$domU_uuid/id)
+
 case "$ACTION" in
   add)
     case "$DEV" in
       vif-*)
         vif=$(echo "$DEV" | sed 's/-\([0-9]*\)-\([0-9]*\)/\1.\2/')
-        vif-bridge up domain=unknown vif="$vif" mac=fe:ff:ff:ff:ff:ff bridge=xen-br0 >/dev/null 2>&1
+        $SCRIPT up domain=$domain vif="$vif" mac=fe:ff:ff:ff:ff:ff bridge=xen-br0 >/dev/null 2>&1
         ;;
     esac
     ;;
diff -r f0dc15fd3c1b tools/examples/init.d/xend
--- a/tools/examples/vif-route	Wed Aug 31 23:22:45 2005
+++ b/tools/examples/vif-route	Thu Sep  1 22:14:10 2005
@@ -41,12 +44,28 @@
 # Optional parameters. Set defaults.
 ip=${ip:-''}   # default to null (do nothing)
 
-main_ip=`ifconfig eth0 | grep "inet addr:" | sed -e 's/.*inet addr:\(\w\w*\.\w\w*\.\w\w*\.\w\w*\).*/\1/'`
+id=$(echo -n $vif | sed -e 's/vif\(.*\)\..*/\1/')
+
+if [ -z "${ip}" ] ; then
+    # Finds "x" such that /domain/x/id == $id  i.e., identifies uuid
+    uuid=$(vm-xs -f /domain id $id)
+    tmp=$(vm-xs -g /domain/$uuid/config | sxp_get.py vm device vif ip)
+    if [ "${tmp%=*}" = "vm_device_vif_ip" ] ; then
+	ip=${tmp#*=}
+    fi
+fi
+
+
+if [ -z "${netdev}" ] ; then
+    netdev=`ip route | sed -e '/default/!d' -e 's/^.*dev \(.*\)$/\1/'`
+fi
+
+main_ip=`ifconfig ${netdev} | grep "inet addr:" | sed -e 's/.*inet addr:\(\w\w*\.\w\w*\.\w\w*\.\w\w*\).*/\1/'`
 
 # Are we going up or down?
 case $OP in
     up)
-        ifconfig ${vif} 169.254.1.0 netmask 255.255.255.255 up
+        ifconfig ${vif} ${main_ip} netmask 255.255.255.255 up
         echo 1 >/proc/sys/net/ipv4/conf/${vif}/proxy_arp
         iptcmd='-A'
         ipcmd='a'
diff -r f0dc15fd3c1b tools/examples/xend-config.sxp
--- a/tools/misc/Makefile	Wed Aug 31 23:22:45 2005
+++ b/tools/misc/Makefile	Thu Sep  1 22:14:10 2005
@@ -15,7 +15,7 @@
 
 TARGETS  = xenperf xc_shadow
 
-INSTALL_BIN  = $(TARGETS) xencons
+INSTALL_BIN  = $(TARGETS) xencons sxp_get
 INSTALL_SBIN = netfix xm xend xenperf
 
 all: build
diff -r f0dc15fd3c1b tools/misc/sxp_get
--- /dev/null	Wed Aug 31 23:22:45 2005
+++ b/tools/misc/sxp_get	Thu Sep  1 22:17:24 2005
@@ -0,0 +1,98 @@
+#!/usr/bin/env python2.3
+#
+# (C) Copyright IBM Corp. 2005 Michal Ostrowski <mostrows at watson ibm com>
+#
+# This library is free software; you can redistribute it and/or
+# modify it under the terms of version 2.1 of the GNU Lesser General Public
+# License as published by the Free Software Foundation.
+#
+# This library is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# Lesser General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public
+# License along with this library; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+import sys
+import re
+sys.path.append('/usr/lib/python')
+sys.path.append('/usr/lib64/python')
+from xen.xend import sxp
+
+def usage():
+    help = """Usage: sxp_get [key1] [key2] ....
+    Parse the sxp file from stdin and print selected key values in a format
+    that is easily handled by shell scripts.
+
+    Keys specified on the command line provide a filtering mechanism.
+    Example:
+    echo (a (b (c d) (e f)) (g h)) |sxp_get a b
+    a_b_c=d
+    a_b_e=f
+
+    echo (a (b (c d) (e f)) (g h)) |sxp_get a
+    a_b_c=d
+    a_b_e=f
+    a_g=h
+    """
+    print help;
+    
+
+def __show_val(prefix1, prefix2, sxpr, match, out=sys.stdout):
+    """Print an sxpr in key1.key2.key3 = value format.
+       'match' is a list of keys, and if non-empty will restrict
+       printing to those key prefixes that match this list.
+    """
+    
+    prefix = (prefix1 + "_" + prefix2).lstrip("_")
+
+    if isinstance(sxpr, sxp.types.ListType):
+        element = sxp.name(sxpr)
+        for attr in sxp.attributes(sxpr):
+            out.write("%s_%s_%s=%s\n" % (prefix, element, attr[0], attr[1]))
+        for x in sxp.children(sxpr):
+            if len(match) > 0 :
+                item = match[0]
+            else:
+                item = element
+                
+            if item == element:
+                __show_val(prefix, element, x, match[1:], out)
+    elif isinstance(sxpr, sxp.types.StringType) and sxp.atomp(sxpr):
+        out.write('%s=%s\n' % (prefix, sxpr))
+    else:
+        out.write("%s=%s\n" % (prefix,str(sxpr)))
+
+def show_val(sxpr, match, out=sys.stdout):
+    """Print an sxpr in key1.key2.key3 = value format.
+       'match' is a list of keys, and if non-empty will restrict
+       printing to those key prefixes that match this list.
+    """
+    __show_val("", "", sxpr, match, out)
+
+
+def main(argv=sys.argv):
+    if len(argv) > 1:
+        print len(argv);
+        if re.compile('-*help').match(argv[1]):
+            usage();
+            sys.exit(0)
+
+    if len(argv) > 0:
+        match = argv[1:]
+    pin = sxp.Parser()
+    while 1:
+        buf = sys.stdin.read(1024)
+        #buf = sys.stdin.readline()
+        pin.input(buf)
+        while pin.ready():
+            val = pin.get_val()
+            show_val(val, match)
+        if len(buf) == 0:
+            break
+        
+
+
+if __name__ == "__main__":
+    main()

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: BUG? domu network interface configuration

[Ted Kaczmarek]

On Wed, 2005-08-31 at 13:01 +0100, Ian Pratt wrote:
>  > > One fix would be for you to just hack the hotplug script. Another, 
> > > slightly better, way would be to grep around in xend's 
> > config script 
> > > to find out what script should be run, and call that. We might even 
> > > take that as an interim patch.
> 
> Can you confirm that things work OK if you rename vif-route to
> vif-bridge? 
> 
> > Any idea when this would be implemented?
> 
> Getting this cleaned up is important.
> 
> Ian
Made no difference.

These are the interface I get on Domain-0
eth0 configured and up
lo configured and up
peth0 configured and up ipv6
vif0.0 configured and up ipv6
xen-br0 configured and up cole of eth0 but HWaddr FE:FF:FF:FF:FF:FF

The all foxes mac address on xen-br0 is a little odd to say the least.

This is with no network related configs for the xm domain.

If I add a vif line after the fact kill everything and restart I still
see xen-br0 with an all foxes mac address.

In both cases netstat -rn only shows xen-br0 devices.

Will try another reboot and see what happens.

If their is any specific configs you want me to try in the domains
config let me know. 

Still see all the 
xend ERROR (process:37) [network-bridge] errors in the xend.log as well.


Regards,
Ted

RE: BUG? domu network interface configuration

[Hien Nguyen]

On Wed, 2005-08-31 at 10:00 -0500, Hien Nguyen wrote:
> Ian,
> I had the same problem, and the things worked OK when it went back to 
> vif-bridge.
> 
> Hien Nguyen
> 
> 
>> Can you elaborate on that for the less versed?

>> Regards,
>> Ted


I startded dom0 with the default of bridge using. Then I created domU 
using filebacked VBD and static ip address. Network communication between 
dom0 and domU worked fine. It also worked with outside world.

But if I started dom0 using route, dom0 can communicate with outside 
world. Then I created the same domU above with the same static ip address. 
domU couldn't talk to anyone.

Here are network info on dom0 and domU:

dom0:
====

x335-hien2:/etc/sysconfig/network # ip addr list
1: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:11:25:3e:0c:66 brd ff:ff:ff:ff:ff:ff
    inet 9.3.189.226/24 brd 9.3.189.255 scope global eth0
    inet6 fe80::211:25ff:fe3e:c66/64 scope link
       valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:11:25:3e:0c:67 brd ff:ff:ff:ff:ff:ff
3: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
4: vif0.0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
5: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
6: sit0: <NOARP> mtu 1480 qdisc noqueue
    link/sit 0.0.0.0 brd 0.0.0.0
7: vif1.0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet 169.254.1.0/32 brd 169.254.255.255 scope global vif1.0
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever
x335-hien2:/etc/sysconfig/network # ip route list
9.3.189.241 dev vif1.0  scope link  src 9.3.189.226
9.3.189.0/24 dev eth0  proto kernel  scope link  src 9.3.189.226
169.254.0.0/16 dev eth0  scope link
127.0.0.0/8 dev lo  scope link
default via 9.3.189.1 dev eth0

x335-hien2:/etc/sysconfig/network # ifconfig
eth0      Link encap:Ethernet  HWaddr 00:11:25:3E:0C:66
          inet addr:9.3.189.226  Bcast:9.3.189.255  Mask:255.255.255.0
          inet6 addr: fe80::211:25ff:fe3e:c66/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:15504 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2787 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1715230 (1.6 Mb)  TX bytes:493255 (481.6 Kb)
          Interrupt:24
 
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:174 errors:0 dropped:0 overruns:0 frame:0
          TX packets:174 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:17926 (17.5 Kb)  TX bytes:17926 (17.5 Kb)
 
vif1.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
          inet addr:169.254.1.0  Bcast:169.254.255.255 
Mask:255.255.255.255
          inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:68 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:5 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:5128 (5.0 Kb)  TX bytes:420 (420.0 b)
 
x335-hien2:/etc/sysconfig/network # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use 
Iface
9.3.189.241     0.0.0.0         255.255.255.255 UH    0      0        0 
vif1.0
9.3.189.0       0.0.0.0         255.255.255.0   U     0      0        0 
eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 
eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         9.3.189.1       0.0.0.0         UG    0      0        0 
eth0
------------

domU:
====
x335-sles9-vm1:/etc/sysconfig/network # ip addr list
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: vif0.0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
3: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
4: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether aa:00:00:17:12:6e brd ff:ff:ff:ff:ff:ff
    inet 9.3.189.241/24 brd 9.3.189.255 scope global eth0
    inet6 fe80::a800:ff:fe17:126e/64 scope link
       valid_lft forever preferred_lft forever
5: sit0: <NOARP> mtu 1480 qdisc noqueue
    link/sit 0.0.0.0 brd 0.0.0.0
x335-sles9-vm1:/etc/sysconfig/network # ip route list
9.3.189.0/24 dev eth0  proto kernel  scope link  src 9.3.189.241
169.254.0.0/16 dev eth0  scope link
127.0.0.0/8 dev lo  scope link
default via 9.3.189.1 dev eth0

x335-sles9-vm1:/etc/sysconfig/network # ifconfig
eth0      Link encap:Ethernet  HWaddr AA:00:00:17:12:6E
          inet addr:9.3.189.241  Bcast:9.3.189.255  Mask:255.255.255.0
          inet6 addr: fe80::a800:ff:fe17:126e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:84 (84.0 b)  TX bytes:914 (914.0 b)
 
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:10 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:658 (658.0 b)  TX bytes:658 (658.0 b)
 
x335-sles9-vm1:/etc/sysconfig/network # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use 
Iface
9.3.189.0       0.0.0.0         255.255.255.0   U     0      0        0 
eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 
eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         9.3.189.1       0.0.0.0         UG    0      0        0 
eth0

Regards,

 Hien Nguyen
 Linux Technology Center             AUSTIN
 Phone: (512) 838-4140            Tie Line: 678-4140
 e-mail: hien1@us.ibm.com

RE: BUG? domu network interface configuration

[Hien Nguyen]

Ian,
I had the same problem, and the things worked OK when it went back to 
vif-bridge.

Hien Nguyen

RE: BUG? domu network interface configuration

[Ted Kaczmarek]

On Wed, 2005-08-31 at 10:00 -0500, Hien Nguyen wrote:
> Ian,
> I had the same problem, and the things worked OK when it went back to 
> vif-bridge.
> 
> Hien Nguyen
> 
> 
Can you elaborate on that for the less versed?

Regards,
Ted

RE: BUG? domu network interface configuration

[Hien Nguyen]

On Wed, 2005-08-31 at 10:00 -0500, Hien Nguyen wrote:
> Ian,
> I had the same problem, and the things worked OK when it went back to 
> vif-bridge.
> 
> Hien Nguyen
> 
> 
>> Can you elaborate on that for the less versed?

>> Regards,
>> Ted


I startded dom0 with the default of bridge using. Then I created domU 
using filebacked VBD and static ip address. Network communication between 
dom0 and domU worked fine. It also worked with outside world.

But if I started dom0 using route, dom0 can communicate with outside 
world. Then I created the same domU above with the same static ip address. 
domU couldn't talk to anyone.

Regards,

 Hien Nguyen
 Linux Technology Center             AUSTIN
 Phone: (512) 838-4140            Tie Line: 678-4140
 e-mail: hien1@us.ibm.com

Re: BUG? domu network interface configuration

[Michal Ostrowski]

[-- Attachment #1.1: Type: text/plain, Size: 441 bytes --]

Unfortunately, I need to do NFS-root (for dom0 and domU) and so I can't
really use a bridge  (in configuring the bridge I'll lose network
connectivity which is needed to run the script that does the
configuration).

On Wed, 31 Aug 2005 10:00:02 -0500
Hien Nguyen <hien1@us.ibm.com> wrote:

> Ian,
> I had the same problem, and the things worked OK when it went back to 
> vif-bridge.
> 
> Hien Nguyen


-- 
Michal Ostrowski

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

BUG? domu network interface configuration

[Michal Ostrowski]

[-- Attachment #1.1: Type: text/plain, Size: 734 bytes --]

I have a config file to specify a domU that contains the following:

nics=1
vif = [ 'mac=aa:00:00:00:00:11,ip=9.2.209.165' ]

(The rest of the config is nothing special; sets up kernel arguments for
nfsroot.)

- xend is configured to use routing.

- xend.log now contains:

[2005-08-30 15:14:01 xend] ERROR (XendDomainInfo:434) ['vif', ['mac', 'aa:00:00:00:00:11'], ['ip', '9.2.209.165']]
[2005-08-30 15:14:01 xend] ERROR (XendDomainInfo:454) aa:00:00:00:00:11

- vif-route has never been called, so the domain's networking doesn't
come up, even though the domain runs.

- this same configuration was working prior to an update this afternoon
(previous snapshot was from last Thursday).


-- 
Michal Ostrowski

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: BUG? domu network interface configuration

[Keir Fraser]

On 31 Aug 2005, at 01:24, Michal Ostrowski wrote:

> - vif-route has never been called, so the domain's networking doesn't
> come up, even though the domain runs.
>
> - this same configuration was working prior to an update this afternoon
> (previous snapshot was from last Thursday).

The changes to xenbus mean that we call vif up/down via hotplug, and 
our hotplug script is hardcoded to call the bridge script. Probably it 
ought to pull stuff out of xenstore to work out what to do, but that's 
not implemented right now.

One fix would be for you to just hack the hotplug script. Another, 
slightly better, way would be to grep around in xend's config script to 
find out what script should be run, and call that. We might even take 
that as an interim patch.

  -- Keir

Re: BUG? domu network interface configuration

[Ted Kaczmarek]

On Wed, 2005-08-31 at 09:00 +0100, Keir Fraser wrote: 
> On 31 Aug 2005, at 01:24, Michal Ostrowski wrote:
> 
> > - vif-route has never been called, so the domain's networking doesn't
> > come up, even though the domain runs.
> >
> > - this same configuration was working prior to an update this afternoon
> > (previous snapshot was from last Thursday).
> 
> The changes to xenbus mean that we call vif up/down via hotplug, and 
> our hotplug script is hardcoded to call the bridge script. Probably it 
> ought to pull stuff out of xenstore to work out what to do, but that's 
> not implemented right now.
> 
> One fix would be for you to just hack the hotplug script. Another, 
> slightly better, way would be to grep around in xend's config script to 
> find out what script should be run, and call that. We might even take 
> that as an interim patch.
> 
>   -- Keir
> 
Any idea when this would be implemented?

Regards,
Ted