Hello everyone, I''m running Xen 4.2 on a Ubuntu 12.04 and I''m trying to run a paravirtualized machine using vif-route script but while trying to bringing up the virtual machine I get the following error message: Parsing config from virtual_machine libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/vif-route online [9649] exited with error status 1 libxl: error: libxl_device.c:978:device_hotplug_child_death_cb: script: /etc/xen/scripts/vif-route failed; error detected. libxl: error: libxl_create.c:1096:domcreate_attach_pci: unable to add nic devices libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/vif-route offline [9712] exited with error status 1 libxl: error: libxl_device.c:978:device_hotplug_child_death_cb: script: /etc/xen/scripts/vif-route failed; error detected. Could anyone guess what caused this error and how to fix it? p.s.: Here the configuration of file "virtual_machine" name = "Name" builder = "generic" memory = 500 disk = ["format=raw,vdev=xvda1,backendtype=tap,target=/home/xen/disco.img"] vif = ["script=vif-route"] kernel = "/home/xen/kernel/vmlinuz-3.2.0-31-generic" ramdisk = "/home/xen/kernel/initrd.img-3.2.0-31-generic" extra = "root=/dev/xvda1 ro" I thank in advance for any help Giorgio Mossa
On Fri, 2012-10-26 at 08:28 +0100, Giorgio Mossa wrote:> libxl: error: libxl_device.c:978:device_hotplug_child_death_cb: > script: /etc/xen/scripts/vif-route failed; error detected.This means that a command has failed somewhere in the script (i.e. ''set -e'' and ''trap .. ERR'' are in use). Sadly it doesn''t give much hint as to what/where it has failed. To debug this I would add near the top of vif-route something like: exec 1>>/tmp/vif-route.log exec 2>&1 echo "$0 $@ at `date` set -x and then try it and look and see what the logs have to say. Ian.
Hi, I''ve tryed to do as you suggested and added the lines to vif-route script by the way I cannot get where the script fails and there''s also something strange it seems that the script is called four times. Here the vif-route.log file''s content, do you see anything useful? /etc/xen/scripts/vif-route online type_if=vif at ven 26 ott 2012, 14.14.23, CEST ++ dirname /etc/xen/scripts/vif-route + dir=/etc/xen/scripts + . /etc/xen/scripts/vif-common.sh +++ dirname /etc/xen/scripts/vif-route ++ dir=/etc/xen/scripts ++ . /etc/xen/scripts/xen-hotplug-common.sh +++ ''['' -n '''' '']'' ++++ dirname /etc/xen/scripts/vif-route +++ dir=/etc/xen/scripts +++ . /etc/xen/scripts/hotplugpath.sh ++++ SBINDIR=/usr/sbin ++++ BINDIR=/usr/bin ++++ LIBEXEC=/usr/lib/xen/bin ++++ LIBDIR=/usr/lib ++++ SHAREDIR=/usr/share ++++ PRIVATE_BINDIR=/usr/lib/xen/bin ++++ XENFIRMWAREDIR=/usr/lib/xen/boot ++++ XEN_CONFIG_DIR=/etc/xen ++++ XEN_SCRIPT_DIR=/etc/xen/scripts ++++ XEN_LOCK_DIR=/var/lock ++++ XEN_RUN_DIR=/var/run/xen ++++ XEN_PAGING_DIR=/var/lib/xen/xenpaging +++ . /etc/xen/scripts/logging.sh +++ . /etc/xen/scripts/xen-script-common.sh ++++ set -e +++ . /etc/xen/scripts/locking.sh ++++ LOCK_BASEDIR=/var/run/xen-hotplug +++ exec /etc/xen/scripts/vif-route online type_if=vif at Fri Oct 26 14:14:23 CEST 2012 ++ dirname /etc/xen/scripts/vif-route + dir=/etc/xen/scripts + . /etc/xen/scripts/vif-common.sh +++ dirname /etc/xen/scripts/vif-route ++ dir=/etc/xen/scripts ++ . /etc/xen/scripts/xen-hotplug-common.sh +++ ''['' -n 1 '']'' +++ xenstore-read libxl/disable_udev +++ exit 0 /etc/xen/scripts/vif-route offline type_if=vif at Fri Oct 26 14:14:23 CEST 2012 /etc/xen/scripts/vif-route offline type_if=vif at ven 26 ott 2012, 14.14.23, CEST ++ dirname /etc/xen/scripts/vif-route ++ dirname /etc/xen/scripts/vif-route + dir=/etc/xen/scripts + . /etc/xen/scripts/vif-common.sh + dir=/etc/xen/scripts + . /etc/xen/scripts/vif-common.sh +++ dirname /etc/xen/scripts/vif-route +++ dirname /etc/xen/scripts/vif-route ++ dir=/etc/xen/scripts ++ . /etc/xen/scripts/xen-hotplug-common.sh +++ ''['' -n 1 '']'' +++ xenstore-read libxl/disable_udev ++ dir=/etc/xen/scripts ++ . /etc/xen/scripts/xen-hotplug-common.sh +++ ''['' -n '''' '']'' +++ exit 0 ++++ dirname /etc/xen/scripts/vif-route +++ dir=/etc/xen/scripts +++ . /etc/xen/scripts/hotplugpath.sh ++++ SBINDIR=/usr/sbin ++++ BINDIR=/usr/bin ++++ LIBEXEC=/usr/lib/xen/bin ++++ LIBDIR=/usr/lib ++++ SHAREDIR=/usr/share ++++ PRIVATE_BINDIR=/usr/lib/xen/bin ++++ XENFIRMWAREDIR=/usr/lib/xen/boot ++++ XEN_CONFIG_DIR=/etc/xen ++++ XEN_SCRIPT_DIR=/etc/xen/scripts ++++ XEN_LOCK_DIR=/var/lock ++++ XEN_RUN_DIR=/var/run/xen ++++ XEN_PAGING_DIR=/var/lib/xen/xenpaging +++ . /etc/xen/scripts/logging.sh +++ . /etc/xen/scripts/xen-script-common.sh ++++ set -e +++ . /etc/xen/scripts/locking.sh ++++ LOCK_BASEDIR=/var/run/xen-hotplug +++ exec On Fri, Oct 26, 2012 at 08:40:41AM +0100, Ian Campbell wrote:> On Fri, 2012-10-26 at 08:28 +0100, Giorgio Mossa wrote: > > libxl: error: libxl_device.c:978:device_hotplug_child_death_cb: > > script: /etc/xen/scripts/vif-route failed; error detected. > > This means that a command has failed somewhere in the script (i.e. ''set > -e'' and ''trap .. ERR'' are in use). Sadly it doesn''t give much hint as to > what/where it has failed. > > To debug this I would add near the top of vif-route something like: > exec 1>>/tmp/vif-route.log > exec 2>&1 > echo "$0 $@ at `date` > set -x > > and then try it and look and see what the logs have to say. > > Ian.
On Fri, 2012-10-26 at 13:15 +0100, Giorgio Mossa wrote:> Hi, > I''ve tryed to do as you suggested and added the lines to vif-route script > by the way I cannot get where the script fails and there''s also > something strange it seems that the script is called four times. > > > Here the vif-route.log file''s content, do you see anything useful?Nothing hugely useful.> +++ execThis is, I think, the: eval "exec $_lockfd>>$_lockfile" from locking.sh. It seems to be last in many of the cases. It might be worth adding an echo both before and after to confirm. The other option is that it is exec 2>>/var/log/xen/xen-hotplug.log from xen-hotplug-common.sh. Actually that one looks more likely. Do you get anything output in that file?
You were absolutely right, looking xen-hotplug.log was the way to the solution, apparently the error was due to a call to the function dom0_ip which not finding the address on interface eth0 arose the error. Adding an ip address to the interface solved the problem. Thanks a lot for all your help. On Fri, Oct 26, 2012 at 01:37:34PM +0100, Ian Campbell wrote:> On Fri, 2012-10-26 at 13:15 +0100, Giorgio Mossa wrote: > > Hi, > > I''ve tryed to do as you suggested and added the lines to vif-route script > > by the way I cannot get where the script fails and there''s also > > something strange it seems that the script is called four times. > > > > > > Here the vif-route.log file''s content, do you see anything useful? > > Nothing hugely useful. > > > +++ exec > > This is, I think, the: > eval "exec $_lockfd>>$_lockfile" > from locking.sh. It seems to be last in many of the cases. It might be > worth adding an echo both before and after to confirm. > > The other option is that it is > exec 2>>/var/log/xen/xen-hotplug.log > from xen-hotplug-common.sh. Actually that one looks more likely. Do you > get anything output in that file?
On Fri, 2012-10-26 at 18:09 +0100, Giorgio Mossa wrote:> You were absolutely right,Great!> looking xen-hotplug.log was the way to the solution, > apparently the error was due to a call to the function dom0_ip > which not finding the address on interface eth0 arose the error. > Adding an ip address to the interface solved the problem.Can you post the relevant bit of the log please, so we can see if we can make it fail with a more helpful message. Thanks, Ian.> > Thanks a lot for all your help. > > > > On Fri, Oct 26, 2012 at 01:37:34PM +0100, Ian Campbell wrote: > > On Fri, 2012-10-26 at 13:15 +0100, Giorgio Mossa wrote: > > > Hi, > > > I''ve tryed to do as you suggested and added the lines to vif-route script > > > by the way I cannot get where the script fails and there''s also > > > something strange it seems that the script is called four times. > > > > > > > > > Here the vif-route.log file''s content, do you see anything useful? > > > > Nothing hugely useful. > > > > > +++ exec > > > > This is, I think, the: > > eval "exec $_lockfd>>$_lockfile" > > from locking.sh. It seems to be last in many of the cases. It might be > > worth adding an echo both before and after to confirm. > > > > The other option is that it is > > exec 2>>/var/log/xen/xen-hotplug.log > > from xen-hotplug-common.sh. Actually that one looks more likely. Do you > > get anything output in that file?
On Fri, Oct 26, 2012 at 07:30:18PM +0100, Ian Campbell wrote:> > Can you post the relevant bit of the log please, so we can see if we can > make it fail with a more helpful message. > > Thanks, > Ian. >Well I don''t know how much can anyone get from this log without knowing which scripts called this anyway here''s the extract of the log (I was using ''set -x'') ++ dom0_ip ++ local nd=eth0 +++ ip_of eth0 +++ ip -4 -o addr show primary dev eth0 +++ awk ''$3 == "inet" {split($4,i,"/"); print i[1]; exit}'' ++ local result++ ''['' -z '''' '']'' ++ fatal ++ _xenstore_write backend/vif/1/0/hotplug-error '''' backend/vif/1/0/hotplug-status error ++ log debug ''Writing backend/vif/1/0/hotplug-error'' '''' backend/vif/1/0/hotplug-status ''error to xenstore.'' through grep I''ve found that vif-route called dom0_ip defined in vif-common.sh and this function arose a fatal because result which contains the output of the command `ip -4 -o addr show primary dev eth0` is empty. Hope this help, thank you again Giorgio
Hello Ian,
hello all,
thanks for your great work on Xen.
Actually I am facing a similar Problem with Xen 4.2.1 and vif-route:
Routing setup does not work as the IP(4)-Address of domU vif is not
transferred to xenstore, therefore the ${ip} variable in the xen scripts
is empty, and I cannot add the route to my domU in dom0 (no proxy_arp
setup). The setup has worked perfectly under Xen 4.1 with xm/xend
toolstack before I switched to 4.2.1.
It seems that
1) in xl.conf you cannot pass a parameter to vif-route like
vifscript="vif-route netdev=bond0" any more,
as /etc/xen/scripts/vif-route netdev=bond0 cannot be executed (error in
xl log). I could workaround that...
2) from domU config:
vif = [ ''mac=de:ad:a:1e:42:3,ip=10.3.2.3'',
''mac=ba:cc:7f:0:4:1,bridge=backupbr0,script=vif-bridge'']
The IP is not parsed so the ${ip} variable in the xen scripts is empty.
If this is not a (known) bug or a general issue, I will provide some
logs (xen-hotplug.log or verbose vif-route etc).
Please let me know if you need more information.
Many thanks and best Regards,
Ulf
_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users
I''m ccing xen-devel and Roger since he''s been looking at the hotplug stuff. On Thu, 2013-01-24 at 16:13 +0000, Ulf Kreutzberg wrote:> It seems that > 1) in xl.conf you cannot pass a parameter to vif-route like > vifscript="vif-route netdev=bond0" any more, > as /etc/xen/scripts/vif-route netdev=bond0 cannot be executed (error in > xl log). I could workaround that...I didn''t realise this was a feature of the old stuff, but yes I can now see that tools/hotplug/Linux/vif-common.sh:dom0_ip() expects netdev=<foo> to have been passed as a parameter to the script. This something we should fix in the libxl layer I think. In the meantime the obvious workaround would be to create vif-route-bond0 as a simple wrapper around vif-route.> 2) from domU config: > vif = [ ''mac=de:ad:a:1e:42:3,ip=10.3.2.3'', > ''mac=ba:cc:7f:0:4:1,bridge=backupbr0,script=vif-bridge''] > > The IP is not parsed so the ${ip} variable in the xen scripts is empty.ip should be parsed and written to xenstore -- do you see it there (in the backend dir)? I can see the code which reads it in the hotplug script.> If this is not a (known) bug or a general issue, I will provide some > logs (xen-hotplug.log or verbose vif-route etc).If the IP address is in xenstore then more verbose vif-route output would be useful. I usually do exec 1>>/tmp/vif-hotplug.log exec 2>&1 set -x at the top of the script.. Thanks, Ian.> Please let me know if you need more information. > > Many thanks and best Regards, > Ulf > >
I''m ccing xen-devel and Roger since he''s been looking at the hotplug stuff. On Thu, 2013-01-24 at 16:13 +0000, Ulf Kreutzberg wrote:> It seems that > 1) in xl.conf you cannot pass a parameter to vif-route like > vifscript="vif-route netdev=bond0" any more, > as /etc/xen/scripts/vif-route netdev=bond0 cannot be executed (error in > xl log). I could workaround that...I didn''t realise this was a feature of the old stuff, but yes I can now see that tools/hotplug/Linux/vif-common.sh:dom0_ip() expects netdev=<foo> to have been passed as a parameter to the script. This something we should fix in the libxl layer I think. In the meantime the obvious workaround would be to create vif-route-bond0 as a simple wrapper around vif-route.> 2) from domU config: > vif = [ ''mac=de:ad:a:1e:42:3,ip=10.3.2.3'', > ''mac=ba:cc:7f:0:4:1,bridge=backupbr0,script=vif-bridge''] > > The IP is not parsed so the ${ip} variable in the xen scripts is empty.ip should be parsed and written to xenstore -- do you see it there (in the backend dir)? I can see the code which reads it in the hotplug script.> If this is not a (known) bug or a general issue, I will provide some > logs (xen-hotplug.log or verbose vif-route etc).If the IP address is in xenstore then more verbose vif-route output would be useful. I usually do exec 1>>/tmp/vif-hotplug.log exec 2>&1 set -x at the top of the script.. Thanks, Ian.> Please let me know if you need more information. > > Many thanks and best Regards, > Ulf > >
On 25/01/13 10:20, Ian Campbell wrote:> I''m ccing xen-devel and Roger since he''s been looking at the hotplug > stuff.Thanks for Ccing me> > On Thu, 2013-01-24 at 16:13 +0000, Ulf Kreutzberg wrote: >> It seems that >> 1) in xl.conf you cannot pass a parameter to vif-route like >> vifscript="vif-route netdev=bond0" any more, >> as /etc/xen/scripts/vif-route netdev=bond0 cannot be executed (error in >> xl log). I could workaround that... > > I didn''t realise this was a feature of the old stuff, but yes I can now > see that tools/hotplug/Linux/vif-common.sh:dom0_ip() expects > netdev=<foo> to have been passed as a parameter to the script. > > This something we should fix in the libxl layer I think. In the meantime > the obvious workaround would be to create vif-route-bond0 as a simple > wrapper around vif-route.I will look at adding an option to specify a default netdev in the global xl config file and to allow passing a "netdev" option in the vif specification. Also, the vif-route script is not working with HVM domains, it is lacking the "add" and "remove" actions used by HVM interfaces, it only supports "online" and "offline".> >> 2) from domU config: >> vif = [ ''mac=de:ad:a:1e:42:3,ip=10.3.2.3'', >> ''mac=ba:cc:7f:0:4:1,bridge=backupbr0,script=vif-bridge''] >> >> The IP is not parsed so the ${ip} variable in the xen scripts is empty. > > ip should be parsed and written to xenstore -- do you see it there (in > the backend dir)? I can see the code which reads it in the hotplug > script.I''ve tried this config and ip is written to xenstore: /local/domain/0/backend/vif/6/0/ip = "192.168.1.230" (n0,r6)>> If this is not a (known) bug or a general issue, I will provide some >> logs (xen-hotplug.log or verbose vif-route etc). > > If the IP address is in xenstore then more verbose vif-route output > would be useful. I usually do > > exec 1>>/tmp/vif-hotplug.log > exec 2>&1 > set -x > > at the top of the script.. > > Thanks, > Ian. > >> Please let me know if you need more information. >> >> Many thanks and best Regards, >> Ulf >> >> > >
On 25/01/13 10:20, Ian Campbell wrote:> I''m ccing xen-devel and Roger since he''s been looking at the hotplug > stuff.Thanks for Ccing me> > On Thu, 2013-01-24 at 16:13 +0000, Ulf Kreutzberg wrote: >> It seems that >> 1) in xl.conf you cannot pass a parameter to vif-route like >> vifscript="vif-route netdev=bond0" any more, >> as /etc/xen/scripts/vif-route netdev=bond0 cannot be executed (error in >> xl log). I could workaround that... > > I didn''t realise this was a feature of the old stuff, but yes I can now > see that tools/hotplug/Linux/vif-common.sh:dom0_ip() expects > netdev=<foo> to have been passed as a parameter to the script. > > This something we should fix in the libxl layer I think. In the meantime > the obvious workaround would be to create vif-route-bond0 as a simple > wrapper around vif-route.I will look at adding an option to specify a default netdev in the global xl config file and to allow passing a "netdev" option in the vif specification. Also, the vif-route script is not working with HVM domains, it is lacking the "add" and "remove" actions used by HVM interfaces, it only supports "online" and "offline".> >> 2) from domU config: >> vif = [ ''mac=de:ad:a:1e:42:3,ip=10.3.2.3'', >> ''mac=ba:cc:7f:0:4:1,bridge=backupbr0,script=vif-bridge''] >> >> The IP is not parsed so the ${ip} variable in the xen scripts is empty. > > ip should be parsed and written to xenstore -- do you see it there (in > the backend dir)? I can see the code which reads it in the hotplug > script.I''ve tried this config and ip is written to xenstore: /local/domain/0/backend/vif/6/0/ip = "192.168.1.230" (n0,r6)>> If this is not a (known) bug or a general issue, I will provide some >> logs (xen-hotplug.log or verbose vif-route etc). > > If the IP address is in xenstore then more verbose vif-route output > would be useful. I usually do > > exec 1>>/tmp/vif-hotplug.log > exec 2>&1 > set -x > > at the top of the script.. > > Thanks, > Ian. > >> Please let me know if you need more information. >> >> Many thanks and best Regards, >> Ulf >> >> > >
Hi, many thanks for your replies. On 25.01.2013 14:51, Roger Pau Monné wrote:>>> 2) from domU config: >>> vif = [ ''mac=de:ad:a:1e:42:3,ip=10.3.2.3'', >>> ''mac=ba:cc:7f:0:4:1,bridge=backupbr0,script=vif-bridge''] >>> >>> The IP is not parsed so the ${ip} variable in the xen scripts is empty. >> >> ip should be parsed and written to xenstore -- do you see it there (in >> the backend dir)? I can see the code which reads it in the hotplug >> script. > > I''ve tried this config and ip is written to xenstore: > > /local/domain/0/backend/vif/6/0/ip = "192.168.1.230" (n0,r6)At least xenstore-ls did not reveal the IP for the domu. I will give it another try and see if I did something wrong. Could you please tell me where the parsing code for the ip= parameter in xl.cfg is located so I could insert a printf or something like that for debugging? Best regards, Ulf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Hi, many thanks for your replies. On 25.01.2013 14:51, Roger Pau Monné wrote:>>> 2) from domU config: >>> vif = [ ''mac=de:ad:a:1e:42:3,ip=10.3.2.3'', >>> ''mac=ba:cc:7f:0:4:1,bridge=backupbr0,script=vif-bridge''] >>> >>> The IP is not parsed so the ${ip} variable in the xen scripts is empty. >> >> ip should be parsed and written to xenstore -- do you see it there (in >> the backend dir)? I can see the code which reads it in the hotplug >> script. > > I''ve tried this config and ip is written to xenstore: > > /local/domain/0/backend/vif/6/0/ip = "192.168.1.230" (n0,r6)At least xenstore-ls did not reveal the IP for the domu. I will give it another try and see if I did something wrong. Could you please tell me where the parsing code for the ip= parameter in xl.cfg is located so I could insert a printf or something like that for debugging? Best regards, Ulf _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On Fri, 2013-01-25 at 14:04 +0000, Ulf Kreutzberg wrote:> > Could you please tell me where the parsing code for the ip= parameter > in xl.cfg is located so I could insert a printf or something like that > for debugging?Look for "ip" (with the quotes) in tools/libxl/xl_cmdimpl.c parse_config_data. There''s another one in main_networkattach but that is the hotplug (xl network-attach) case (yes, these should be consolidated...). Ian.
On Fri, 2013-01-25 at 14:04 +0000, Ulf Kreutzberg wrote:> > Could you please tell me where the parsing code for the ip= parameter > in xl.cfg is located so I could insert a printf or something like that > for debugging?Look for "ip" (with the quotes) in tools/libxl/xl_cmdimpl.c parse_config_data. There''s another one in main_networkattach but that is the hotplug (xl network-attach) case (yes, these should be consolidated...). Ian.
Roger ->>> 2) from domU config: >>> vif = [ ''mac=de:ad:a:1e:42:3,ip=10.3.2.3'', >>> ''mac=ba:cc:7f:0:4:1,bridge=backupbr0,script=vif-bridge''] >>> >>> The IP is not parsed so the ${ip} variable in the xen scripts is empty. >> >> ip should be parsed and written to xenstore -- do you see it there >> (in >> the backend dir)? I can see the code which reads it in the hotplug >> script. > > I''ve tried this config and ip is written to xenstore: > > /local/domain/0/backend/vif/6/0/ip = "192.168.1.230" (n0,r6) >I think I could track down the issue: The mac address is not parsed correctly if not padded with leading zeros (and no error reported, though): Using the example above which worked perfectly with the old xm, xl create -n test.domU ===...shortened output... "nics": [ { ... "mac": "de:ad:0a:0e:02:00", "ip": null, "bridge": null, "ifname": null, ... }, { ... "mac": "ba:cc:7f:00:00:0b", "ip": null, "bridge": null, "ifname": null, ... } ] ====If I use padded bytes, vif = [ ''mac=de:ad:0a:1e:42:03, ip=10.3.2.3'', ''mac=ba:cc:7f:00:04:01,bridge=backupbr0,script=vif-bridge''] it creates correctly ===="nics": [ { ... "mac": "de:ad:0a:1e:42:03", "ip": "10.3.2.3", "bridge": null, "ifname": null, ... }, { ... "mac": "ba:cc:7f:00:04:01", "ip": null, "bridge": "backupbr0", "ifname": null, ... } ] ====which is totally ok for me. Routes are set and the IP of the routed vif shows up in xenstore. Many thanks and best regards, Ulf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Roger ->>> 2) from domU config: >>> vif = [ ''mac=de:ad:a:1e:42:3,ip=10.3.2.3'', >>> ''mac=ba:cc:7f:0:4:1,bridge=backupbr0,script=vif-bridge''] >>> >>> The IP is not parsed so the ${ip} variable in the xen scripts is empty. >> >> ip should be parsed and written to xenstore -- do you see it there >> (in >> the backend dir)? I can see the code which reads it in the hotplug >> script. > > I''ve tried this config and ip is written to xenstore: > > /local/domain/0/backend/vif/6/0/ip = "192.168.1.230" (n0,r6) >I think I could track down the issue: The mac address is not parsed correctly if not padded with leading zeros (and no error reported, though): Using the example above which worked perfectly with the old xm, xl create -n test.domU ===...shortened output... "nics": [ { ... "mac": "de:ad:0a:0e:02:00", "ip": null, "bridge": null, "ifname": null, ... }, { ... "mac": "ba:cc:7f:00:00:0b", "ip": null, "bridge": null, "ifname": null, ... } ] ====If I use padded bytes, vif = [ ''mac=de:ad:0a:1e:42:03, ip=10.3.2.3'', ''mac=ba:cc:7f:00:04:01,bridge=backupbr0,script=vif-bridge''] it creates correctly ===="nics": [ { ... "mac": "de:ad:0a:1e:42:03", "ip": "10.3.2.3", "bridge": null, "ifname": null, ... }, { ... "mac": "ba:cc:7f:00:04:01", "ip": null, "bridge": "backupbr0", "ifname": null, ... } ] ====which is totally ok for me. Routes are set and the IP of the routed vif shows up in xenstore. Many thanks and best regards, Ulf _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On Mon, 2013-01-28 at 13:45 +0000, Ulf Kreutzberg wrote:> The mac address is not parsed correctly if not padded with leading > zeros (and no error reported, though):Ick, well spotted. It is a bug in xl that it doesn''t Do The Right Thing here, even if stripping the leading zeroes is somewhat unconventional IMHO. Ian.
On Mon, 2013-01-28 at 13:45 +0000, Ulf Kreutzberg wrote:> The mac address is not parsed correctly if not padded with leading > zeros (and no error reported, though):Ick, well spotted. It is a bug in xl that it doesn''t Do The Right Thing here, even if stripping the leading zeroes is somewhat unconventional IMHO. Ian.
On 28.01.2013 14:59, Ian Campbell wrote:> On Mon, 2013-01-28 at 13:45 +0000, Ulf Kreutzberg wrote: >> The mac address is not parsed correctly if not padded with leading >> zeros (and no error reported, though): > > Ick, well spotted. It is a bug in xl that it doesn''t Do The Right Thing > here, even if stripping the leading zeroes is somewhat unconventional > IMHO. > > Ian.How shall I proceed here? Shall I open a bug report or did some of you already open one? Thanks and regards, Ulf _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On 28.01.2013 14:59, Ian Campbell wrote:> On Mon, 2013-01-28 at 13:45 +0000, Ulf Kreutzberg wrote: >> The mac address is not parsed correctly if not padded with leading >> zeros (and no error reported, though): > > Ick, well spotted. It is a bug in xl that it doesn''t Do The Right Thing > here, even if stripping the leading zeroes is somewhat unconventional > IMHO. > > Ian.How shall I proceed here? Shall I open a bug report or did some of you already open one? Thanks and regards, Ulf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 01/02/13 15:46, Ulf Kreutzberg wrote:> > On 28.01.2013 14:59, Ian Campbell wrote: >> On Mon, 2013-01-28 at 13:45 +0000, Ulf Kreutzberg wrote: >>> The mac address is not parsed correctly if not padded with leading >>> zeros (and no error reported, though): >> >> Ick, well spotted. It is a bug in xl that it doesn''t Do The Right Thing >> here, even if stripping the leading zeroes is somewhat unconventional >> IMHO. >> >> Ian. > > How shall I proceed here? Shall I open a bug report or did some of you > already open one?Hello, I''ve send a patch series that I think should fix your issues, could you please try them and report back? http://lists.xen.org/archives/html/xen-devel/2013-01/msg02217.html Thanks, Roger.
On 01/02/13 15:46, Ulf Kreutzberg wrote:> > On 28.01.2013 14:59, Ian Campbell wrote: >> On Mon, 2013-01-28 at 13:45 +0000, Ulf Kreutzberg wrote: >>> The mac address is not parsed correctly if not padded with leading >>> zeros (and no error reported, though): >> >> Ick, well spotted. It is a bug in xl that it doesn''t Do The Right Thing >> here, even if stripping the leading zeroes is somewhat unconventional >> IMHO. >> >> Ian. > > How shall I proceed here? Shall I open a bug report or did some of you > already open one?Hello, I''ve send a patch series that I think should fix your issues, could you please try them and report back? http://lists.xen.org/archives/html/xen-devel/2013-01/msg02217.html Thanks, Roger.