xensource@pivert.org
2009-Jul-22 15:28 UTC
[Xen-users] Xen 3.4.1-rc7 network problem (vif/tap)
Hi, I''m now blocked for 2 days on getting the network to work in my domU. Here is the problem : The domU refuses to start when a vif is configured. It''s just staying paused for about 1m40s, then the xm create command line give back with an "Error: Device 0 (vif) could not be connected. Hotplug scripts not working.", and the domU is destroyed. Nothing particular in the xend.log, xend-debug.log or qemu-dm-domUname.log. However, if I manually unpause the domU, and cancel (<CTRL><C>) the xm create command to avoid the destruction of the domU after the 1m40s timeout, I get a perfectly working domU with Network. Strangely, the vif network interfaces are now named tap[domUid].[interface#] (ie tap2.0). So, my questions : - Why is there no clear log about vif-bridge script, and how can I debug this script. - Why are the interfaces named tapX.X instead of vifX.X ? - Is there a default name for the bridge interface ? I''m currently using xenbr0, but I see that some documentations are talking about eth0, should I use eth0 as default bridge name ? Thanks, François. My config : root@UbuntuTST-Blade:~# xm info host : UbuntuTST-Blade release : 2.6.31-rc3 version : #8 SMP Mon Jul 20 15:01:16 CEST 2009 machine : x86_64 nr_cpus : 16 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 2 cpu_mhz : 2400 hw_caps : bfebfbff:28100800:00000000:00000340:009ce3bd:00000000:00000001:00000000 virt_caps : hvm total_memory : 36853 free_memory : 1043 node_to_cpu : node0:0-15 node_to_memory : node0:1043 xen_major : 3 xen_minor : 4 xen_extra : .1-rc7 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : Wed Jul 15 13:26:50 2009 +0100 19696:22ef8e900a6d cc_compiler : gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) cc_compile_by : root cc_compile_domain : local.modernprocessing.lu cc_compile_date : Thu Jul 16 21:46:26 CEST 2009 xend_config_format : 4 root@UbuntuTST-Blade:~# _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Boris Derzhavets
2009-Jul-22 15:57 UTC
Re: [Xen-users] Xen 3.4.1-rc7 network problem (vif/tap)
> use eth0 as default bridge name ?I guess , yes. However,please, post:- # brctl show # ifconfig Content /etc/init.d/networking (how you configure the bridge ?) Profile of your DomU Boris. --- On Wed, 7/22/09, xensource@pivert.org <xensource@pivert.org> wrote: From: xensource@pivert.org <xensource@pivert.org> Subject: [Xen-users] Xen 3.4.1-rc7 network problem (vif/tap) To: xen-users@lists.xensource.com Date: Wednesday, July 22, 2009, 11:28 AM Hi, I''m now blocked for 2 days on getting the network to work in my domU. Here is the problem : The domU refuses to start when a vif is configured. It''s just staying paused for about 1m40s, then the xm create command line give back with an "Error: Device 0 (vif) could not be connected. Hotplug scripts not working.", and the domU is destroyed. Nothing particular in the xend.log, xend-debug.log or qemu-dm-domUname.log. However, if I manually unpause the domU, and cancel (<CTRL><C>) the xm create command to avoid the destruction of the domU after the 1m40s timeout, I get a perfectly working domU with Network. Strangely, the vif network interfaces are now named tap[domUid].[interface#] (ie tap2.0). So, my questions : - Why is there no clear log about vif-bridge script, and how can I debug this script. - Why are the interfaces named tapX.X instead of vifX.X ? - Is there a default name for the bridge interface ? I''m currently using xenbr0, but I see that some documentations are talking about eth0, should I use eth0 as default bridge name ? Thanks, François. My config : root@UbuntuTST-Blade:~# xm info host : UbuntuTST-Blade release : 2.6.31-rc3 version : #8 SMP Mon Jul 20 15:01:16 CEST 2009 machine : x86_64 nr_cpus : 16 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 2 cpu_mhz : 2400 hw_caps : bfebfbff:28100800:00000000:00000340:009ce3bd:00000000:00000001:00000000 virt_caps : hvm total_memory : 36853 free_memory : 1043 node_to_cpu : node0:0-15 node_to_memory : node0:1043 xen_major : 3 xen_minor : 4 xen_extra : .1-rc7 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : Wed Jul 15 13:26:50 2009 +0100 19696:22ef8e900a6d cc_compiler : gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) cc_compile_by : root cc_compile_domain : local.modernprocessing.lu cc_compile_date : Thu Jul 16 21:46:26 CEST 2009 xend_config_format : 4 root@UbuntuTST-Blade:~# _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
François Delpierre
2009-Jul-22 17:43 UTC
Re: [Xen-users] Xen 3.4.1-rc7 network problem (vif/tap)
Maybe here is an interesting part :
The script is just waiting at :
[2009-07-22 19:30:22 4325] DEBUG (DevController:139) Waiting for devices vif.
[2009-07-22 19:30:22 4325] DEBUG (XendDomainInfo:1709)
XendDomainInfo.handleShutdownWatch
[2009-07-22 19:30:22 4325] DEBUG (DevController:144) Waiting for 0.
[2009-07-22 19:30:22 4325] DEBUG (DevController:629) hotplugStatusCallback
/local/domain/0/backend/vif/5/0/hotplug-status.
If I look closer into
/usr/local/lib/python2.6/dist-packages/xen/xend/server/DevController.py after
line 629, there is a call to xstransact.Read(statusPath) that never answers.
François.
----- Original Message -----
From: xensource@pivert.org
To: xen-users@list.xensource.com
Sent: Wednesday, 22 July, 2009 19:08:03 GMT +01:00 Amsterdam / Berlin / Bern /
Rome / Stockholm / Vienna
Subject: Re: [Xen-users] Xen 3.4.1-rc7 network problem (vif/tap)
Well, I had exactly the same problem by configuring the bridge with the provided
network-bridge script or externally through the ubuntu /etc/network/interfaces
parameters, and with both eth0 and xenbr0 default bridge interface name.
I just reverted back to eth0 as default bridge name, and network-bridge script
executing at the xend init script. So, after a fresh reboot I have only eth0 up
with the dhcp configured address.
After starting /etc/init.d/xend, everything is OK, and the bridge is correctly
configured :
root@UbuntuTST-Blade:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:21:5e:96:07:94
inet addr:172.17.4.46 Bcast:172.17.4.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:73 errors:0 dropped:0 overruns:0 frame:0
TX packets:19 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4552 (4.5 KB) TX bytes:3358 (3.3 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:140 errors:0 dropped:0 overruns:0 frame:0
TX packets:140 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:12068 (12.0 KB) TX bytes:12068 (12.0 KB)
peth0 Link encap:Ethernet HWaddr 00:21:5e:96:07:94
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:72 errors:0 dropped:0 overruns:0 frame:0
TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5868 (5.8 KB) TX bytes:3760 (3.7 KB)
Interrupt:30 Memory:92000000-92012800
root@UbuntuTST-Blade:~# brctl show
bridge name bridge id STP enabled interfaces
eth0 8000.00215e960794 no peth0
After starting the domU, the xm create just hangs, and the domU stays in paused
state for 1m40s :
root@UbuntuTST-Blade:~# brctl show
bridge name bridge id STP enabled interfaces
eth0 8000.00215e960794 no peth0
tap1.0
root@UbuntuTST-Blade:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:21:5e:96:07:94
inet addr:172.17.4.46 Bcast:172.17.4.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3795 errors:0 dropped:0 overruns:0 frame:0
TX packets:808 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:230414 (230.4 KB) TX bytes:117990 (117.9 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:232 errors:0 dropped:0 overruns:0 frame:0
TX packets:232 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:20640 (20.6 KB) TX bytes:20640 (20.6 KB)
peth0 Link encap:Ethernet HWaddr 00:21:5e:96:07:94
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:3947 errors:0 dropped:0 overruns:0 frame:0
TX packets:966 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:314792 (314.7 KB) TX bytes:135314 (135.3 KB)
Interrupt:30 Memory:92000000-92012800
tap1.0 Link encap:Ethernet HWaddr 62:0f:06:f9:c4:d0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:55 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:3434 (3.4 KB)
root@UbuntuTST-Blade:~# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 31853 16 r----- 32.8
XPTST1 1 1024 1 --p--- 0.0
root@UbuntuTST-Blade:~#
At this step, if I manually unpause the domain, and cancel the xm create comand
to avoid it to destroy the domU after timeout, the domU starts and the network
is working.
If I just wait, the domU will be destroyed after timeout, and the tap interface
will be removed from the bridge.
So, it really seems to come from the vif-bridge script, but how can I debug it ?
Which arguments are passed to it ?
root@UbuntuTST-Blade:~# cat /etc/network/interfaces | grep -v
''^#\|^$''
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
root@UbuntuTST-Blade:~#
root@UbuntuTST-Blade:~# cat /etc/xen/XPTST1 | grep -v ''^#\|^$''
import os, re
arch = os.uname()[4]
if re.search(''64'', arch):
arch_libdir = ''lib64''
else:
arch_libdir = ''lib''
kernel = "/usr/lib/xen/boot/hvmloader"
builder=''hvm''
memory = 1024
shadow_memory = 8
name = "XPTST1"
vif = [ '''' ]
disk = [ ''file:/localstorage/XPTST1.img,hda,w'',
''file:/localstorage/install/WindowsXP-Pro-32.iso,hdc:cdrom,r''
]
device_model = ''/usr/'' + arch_libdir +
''/xen/bin/qemu-dm''
boot="dc"
sdl=0
vnc=1
vncconsole=1
stdvga=0
serial=''pty''
usbdevice=''tablet''
root@UbuntuTST-Blade:~#
----- Original Message -----
From: "Boris Derzhavets" <bderzhavets@yahoo.com>
To: xen-users@lists.xensource.com, xensource@pivert.org
Sent: Wednesday, 22 July, 2009 17:57:23 GMT +01:00 Amsterdam / Berlin / Bern /
Rome / Stockholm / Vienna
Subject: Re: [Xen-users] Xen 3.4.1-rc7 network problem (vif/tap)
> use eth0 as default bridge name ?
I guess , yes.
However,please, post:-
# brctl show
# ifconfig
Content /etc/init.d/networking (how you configure the bridge ?)
Profile of your DomU
Boris.
--- On Wed, 7/22/09, xensource@pivert.org <xensource@pivert.org> wrote:
From: xensource@pivert.org <xensource@pivert.org>
Subject: [Xen-users] Xen 3.4.1-rc7 network problem (vif/tap)
To: xen-users@lists.xensource.com
Date: Wednesday, July 22, 2009, 11:28 AM
Hi,
I''m now blocked for 2 days on getting the network to work in my domU.
Here is
the problem :
The domU refuses to start when a vif is configured. It''s just staying
paused
for about 1m40s, then the xm create command line give back with an
"Error: Device 0 (vif) could not be connected. Hotplug scripts not
working.",
and the domU is destroyed.
Nothing particular in the xend.log, xend-debug.log or qemu-dm-domUname.log.
However, if I manually unpause the domU, and cancel (<CTRL><C>) the
xm create
command to avoid the destruction of the domU after the 1m40s timeout, I get a
perfectly working domU with Network. Strangely, the vif network interfaces are
now named tap[domUid].[interface#] (ie tap2.0).
So, my questions :
- Why is there no clear log about vif-bridge script, and how can I debug this
script.
- Why are the interfaces named tapX.X instead of vifX.X ?
- Is there a default name for the bridge interface ? I''m currently
using
xenbr0, but I see that some documentations are talking about eth0, should I
use eth0 as default bridge name ?
Thanks,
François.
My config :
root@UbuntuTST-Blade:~# xm info
host : UbuntuTST-Blade
release : 2.6.31-rc3
version : #8 SMP Mon Jul 20 15:01:16 CEST 2009
machine : x86_64
nr_cpus : 16
nr_nodes : 1
cores_per_socket : 4
threads_per_core : 2
cpu_mhz : 2400
hw_caps :
bfebfbff:28100800:00000000:00000340:009ce3bd:00000000:00000001:00000000
virt_caps : hvm
total_memory : 36853
free_memory : 1043
node_to_cpu : node0:0-15
node_to_memory : node0:1043
xen_major : 3
xen_minor : 4
xen_extra : .1-rc7
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler : credit
xen_pagesize : 4096
platform_params : virt_start=0xffff800000000000
xen_changeset : Wed Jul 15 13:26:50 2009 +0100 19696:22ef8e900a6d
cc_compiler : gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
cc_compile_by : root
cc_compile_domain : local.modernprocessing.lu
cc_compile_date : Thu Jul 16 21:46:26 CEST 2009
xend_config_format : 4
root@UbuntuTST-Blade:~#
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
François Delpierre
2009-Jul-23 21:48 UTC
Re: [Xen-users] Xen 3.4.1-rc7 network problem (vif/tap)
Just replying to myself.
It really looks like I found a bug about the xstransact.Read(statusPath)
function that is called from
/usr/local/lib/python2.6/dist-packages/xen/xend/server/DevController.py at line
631.
xstransact.Read(statusPath) is returning None, so the return of the function is
1 and it blocks the startup of the domU.
I just added these lines to the file :
---
/usr/src/xen-3.4-testing.hg/tools/python/build/lib.linux-x86_64-2.6/xen/xend/server/DevController.py
2009-07-16 21:40:55.000000000 +0200
+++ /usr/local/lib/python2.6/dist-packages/xen/xend/server/DevController.py
2009-07-22 20:03:00.000000000 +0200
@@ -629,7 +629,14 @@
log.debug("hotplugStatusCallback %s.", statusPath)
status = xstransact.Read(statusPath)
+
+ log.debug("Status : %s.", status)
+ log.debug("FDE: overriding the status variable if set to None.")
+ if status is None:
+ status = "SomethingDifferent"
+ log.debug("Status : %s.", status)
+
if status is not None:
if status == HOTPLUG_STATUS_ERROR:
result[''status''] = Error
and restarted xend... I know this is really a shitty patch, but at least now my
DomU are starting and working wirh network enabled. The problem is that I
don''t know which test I disabled and I really need a developper with
more experience to help pointing the problem.
Regards,
François.
----- Original Message -----
From: "François Delpierre" <francois.delpierre@pivert.org>
To: xen-users@lists.xensource.com
Sent: Wednesday, 22 July, 2009 19:43:45 GMT +01:00 Amsterdam / Berlin / Bern /
Rome / Stockholm / Vienna
Subject: Re: [Xen-users] Xen 3.4.1-rc7 network problem (vif/tap)
Maybe here is an interesting part :
The script is just waiting at :
[2009-07-22 19:30:22 4325] DEBUG (DevController:139) Waiting for devices vif.
[2009-07-22 19:30:22 4325] DEBUG (XendDomainInfo:1709)
XendDomainInfo.handleShutdownWatch
[2009-07-22 19:30:22 4325] DEBUG (DevController:144) Waiting for 0.
[2009-07-22 19:30:22 4325] DEBUG (DevController:629) hotplugStatusCallback
/local/domain/0/backend/vif/5/0/hotplug-status.
If I look closer into
/usr/local/lib/python2.6/dist-packages/xen/xend/server/DevController.py after
line 629, there is a call to xstransact.Read(statusPath) that never answers.
François.
----- Original Message -----
From: xensource@pivert.org
To: xen-users@list.xensource.com
Sent: Wednesday, 22 July, 2009 19:08:03 GMT +01:00 Amsterdam / Berlin / Bern /
Rome / Stockholm / Vienna
Subject: Re: [Xen-users] Xen 3.4.1-rc7 network problem (vif/tap)
Well, I had exactly the same problem by configuring the bridge with the provided
network-bridge script or externally through the ubuntu /etc/network/interfaces
parameters, and with both eth0 and xenbr0 default bridge interface name.
I just reverted back to eth0 as default bridge name, and network-bridge script
executing at the xend init script. So, after a fresh reboot I have only eth0 up
with the dhcp configured address.
After starting /etc/init.d/xend, everything is OK, and the bridge is correctly
configured :
root@UbuntuTST-Blade:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:21:5e:96:07:94
inet addr:172.17.4.46 Bcast:172.17.4.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:73 errors:0 dropped:0 overruns:0 frame:0
TX packets:19 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4552 (4.5 KB) TX bytes:3358 (3.3 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:140 errors:0 dropped:0 overruns:0 frame:0
TX packets:140 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:12068 (12.0 KB) TX bytes:12068 (12.0 KB)
peth0 Link encap:Ethernet HWaddr 00:21:5e:96:07:94
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:72 errors:0 dropped:0 overruns:0 frame:0
TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5868 (5.8 KB) TX bytes:3760 (3.7 KB)
Interrupt:30 Memory:92000000-92012800
root@UbuntuTST-Blade:~# brctl show
bridge name bridge id STP enabled interfaces
eth0 8000.00215e960794 no peth0
After starting the domU, the xm create just hangs, and the domU stays in paused
state for 1m40s :
root@UbuntuTST-Blade:~# brctl show
bridge name bridge id STP enabled interfaces
eth0 8000.00215e960794 no peth0
tap1.0
root@UbuntuTST-Blade:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:21:5e:96:07:94
inet addr:172.17.4.46 Bcast:172.17.4.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3795 errors:0 dropped:0 overruns:0 frame:0
TX packets:808 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:230414 (230.4 KB) TX bytes:117990 (117.9 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:232 errors:0 dropped:0 overruns:0 frame:0
TX packets:232 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:20640 (20.6 KB) TX bytes:20640 (20.6 KB)
peth0 Link encap:Ethernet HWaddr 00:21:5e:96:07:94
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:3947 errors:0 dropped:0 overruns:0 frame:0
TX packets:966 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:314792 (314.7 KB) TX bytes:135314 (135.3 KB)
Interrupt:30 Memory:92000000-92012800
tap1.0 Link encap:Ethernet HWaddr 62:0f:06:f9:c4:d0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:55 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:3434 (3.4 KB)
root@UbuntuTST-Blade:~# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 31853 16 r----- 32.8
XPTST1 1 1024 1 --p--- 0.0
root@UbuntuTST-Blade:~#
At this step, if I manually unpause the domain, and cancel the xm create comand
to avoid it to destroy the domU after timeout, the domU starts and the network
is working.
If I just wait, the domU will be destroyed after timeout, and the tap interface
will be removed from the bridge.
So, it really seems to come from the vif-bridge script, but how can I debug it ?
Which arguments are passed to it ?
root@UbuntuTST-Blade:~# cat /etc/network/interfaces | grep -v
''^#\|^$''
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
root@UbuntuTST-Blade:~#
root@UbuntuTST-Blade:~# cat /etc/xen/XPTST1 | grep -v ''^#\|^$''
import os, re
arch = os.uname()[4]
if re.search(''64'', arch):
arch_libdir = ''lib64''
else:
arch_libdir = ''lib''
kernel = "/usr/lib/xen/boot/hvmloader"
builder=''hvm''
memory = 1024
shadow_memory = 8
name = "XPTST1"
vif = [ '''' ]
disk = [ ''file:/localstorage/XPTST1.img,hda,w'',
''file:/localstorage/install/WindowsXP-Pro-32.iso,hdc:cdrom,r''
]
device_model = ''/usr/'' + arch_libdir +
''/xen/bin/qemu-dm''
boot="dc"
sdl=0
vnc=1
vncconsole=1
stdvga=0
serial=''pty''
usbdevice=''tablet''
root@UbuntuTST-Blade:~#
----- Original Message -----
From: "Boris Derzhavets" <bderzhavets@yahoo.com>
To: xen-users@lists.xensource.com, xensource@pivert.org
Sent: Wednesday, 22 July, 2009 17:57:23 GMT +01:00 Amsterdam / Berlin / Bern /
Rome / Stockholm / Vienna
Subject: Re: [Xen-users] Xen 3.4.1-rc7 network problem (vif/tap)
> use eth0 as default bridge name ?
I guess , yes.
However,please, post:-
# brctl show
# ifconfig
Content /etc/init.d/networking (how you configure the bridge ?)
Profile of your DomU
Boris.
--- On Wed, 7/22/09, xensource@pivert.org <xensource@pivert.org> wrote:
From: xensource@pivert.org <xensource@pivert.org>
Subject: [Xen-users] Xen 3.4.1-rc7 network problem (vif/tap)
To: xen-users@lists.xensource.com
Date: Wednesday, July 22, 2009, 11:28 AM
Hi,
I''m now blocked for 2 days on getting the network to work in my domU.
Here is
the problem :
The domU refuses to start when a vif is configured. It''s just staying
paused
for about 1m40s, then the xm create command line give back with an
"Error: Device 0 (vif) could not be connected. Hotplug scripts not
working.",
and the domU is destroyed.
Nothing particular in the xend.log, xend-debug.log or qemu-dm-domUname.log.
However, if I manually unpause the domU, and cancel (<CTRL><C>) the
xm create
command to avoid the destruction of the domU after the 1m40s timeout, I get a
perfectly working domU with Network. Strangely, the vif network interfaces are
now named tap[domUid].[interface#] (ie tap2.0).
So, my questions :
- Why is there no clear log about vif-bridge script, and how can I debug this
script.
- Why are the interfaces named tapX.X instead of vifX.X ?
- Is there a default name for the bridge interface ? I''m currently
using
xenbr0, but I see that some documentations are talking about eth0, should I
use eth0 as default bridge name ?
Thanks,
François.
My config :
root@UbuntuTST-Blade:~# xm info
host : UbuntuTST-Blade
release : 2.6.31-rc3
version : #8 SMP Mon Jul 20 15:01:16 CEST 2009
machine : x86_64
nr_cpus : 16
nr_nodes : 1
cores_per_socket : 4
threads_per_core : 2
cpu_mhz : 2400
hw_caps :
bfebfbff:28100800:00000000:00000340:009ce3bd:00000000:00000001:00000000
virt_caps : hvm
total_memory : 36853
free_memory : 1043
node_to_cpu : node0:0-15
node_to_memory : node0:1043
xen_major : 3
xen_minor : 4
xen_extra : .1-rc7
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler : credit
xen_pagesize : 4096
platform_params : virt_start=0xffff800000000000
xen_changeset : Wed Jul 15 13:26:50 2009 +0100 19696:22ef8e900a6d
cc_compiler : gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
cc_compile_by : root
cc_compile_domain : local.modernprocessing.lu
cc_compile_date : Thu Jul 16 21:46:26 CEST 2009
xend_config_format : 4
root@UbuntuTST-Blade:~#
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
_______________________________________________ Xen-users mailing list
Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Dustin Henning
2009-Jul-24 12:01 UTC
RE: [Xen-users] Xen 3.4.1-rc7 network problem (vif/tap)
I’m just guessing, but you should probably try the xen developers list
(xen-devel, and presumably you have to join it the same way you join the users
list).
Dustin
From: xen-users-bounces@lists.xensource.com
[mailto:xen-users-bounces@lists.xensource.com] On Behalf Of François Delpierre
Sent: Thursday, July 23, 2009 17:48
To: xen-users@lists.xensource.com
Subject: Re: [Xen-users] Xen 3.4.1-rc7 network problem (vif/tap)
Just replying to myself.
It really looks like I found a bug about the xstransact.Read(statusPath)
function that is called from
/usr/local/lib/python2.6/dist-packages/xen/xend/server/DevController.py at line
631.
xstransact.Read(statusPath) is returning None, so the return of the function is
1 and it blocks the startup of the domU.
I just added these lines to the file :
---
/usr/src/xen-3.4-testing.hg/tools/python/build/lib.linux-x86_64-2.6/xen/xend/server/DevController.py
2009-07-16 21:40:55.000000000 +0200
+++ /usr/local/lib/python2.6/dist-packages/xen/xend/server/DevController.py
2009-07-22 20:03:00.000000000 +0200
@@ -629,7 +629,14 @@
log.debug("hotplugStatusCallback %s.", statusPath)
status = xstransact.Read(statusPath)
+
+ log.debug("Status : %s.", status)
+ log.debug("FDE: overriding the status variable if set to None.")
+ if status is None:
+ status = "SomethingDifferent"
+ log.debug("Status : %s.", status)
+
if status is not None:
if status == HOTPLUG_STATUS_ERROR:
result[''status''] = Error
and restarted xend... I know this is really a shitty patch, but at least now my
DomU are starting and working wirh network enabled. The problem is that I
don''t know which test I disabled and I really need a developper with
more experience to help pointing the problem.
Regards,
François.
----- Original Message -----
From: "François Delpierre" <francois.delpierre@pivert.org>
To: xen-users@lists.xensource.com
Sent: Wednesday, 22 July, 2009 19:43:45 GMT +01:00 Amsterdam / Berlin / Bern /
Rome / Stockholm / Vienna
Subject: Re: [Xen-users] Xen 3.4.1-rc7 network problem (vif/tap)
Maybe here is an interesting part :
The script is just waiting at :
[2009-07-22 19:30:22 4325] DEBUG (DevController:139) Waiting for devices vif.
[2009-07-22 19:30:22 4325] DEBUG (XendDomainInfo:1709)
XendDomainInfo.handleShutdownWatch
[2009-07-22 19:30:22 4325] DEBUG (DevController:144) Waiting for 0.
[2009-07-22 19:30:22 4325] DEBUG (DevController:629) hotplugStatusCallback
/local/domain/0/backend/vif/5/0/hotplug-status.
If I look closer into
/usr/local/lib/python2.6/dist-packages/xen/xend/server/DevController.py after
line 629, there is a call to xstransact.Read(statusPath) that never answers.
François.
----- Original Message -----
From: xensource@pivert.org
To: xen-users@list.xensource.com
Sent: Wednesday, 22 July, 2009 19:08:03 GMT +01:00 Amsterdam / Berlin / Bern /
Rome / Stockholm / Vienna
Subject: Re: [Xen-users] Xen 3.4.1-rc7 network problem (vif/tap)
Well, I had exactly the same problem by configuring the bridge with the provided
network-bridge script or externally through the ubuntu /etc/network/interfaces
parameters, and with both eth0 and xenbr0 default bridge interface name.
I just reverted back to eth0 as default bridge name, and network-bridge script
executing at the xend init script. So, after a fresh reboot I have only eth0 up
with the dhcp configured address.
After starting /etc/init.d/xend, everything is OK, and the bridge is correctly
configured :
root@UbuntuTST-Blade:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:21:5e:96:07:94
inet addr:172.17.4.46 Bcast:172.17.4.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:73 errors:0 dropped:0 overruns:0 frame:0
TX packets:19 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4552 (4.5 KB) TX bytes:3358 (3.3 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:140 errors:0 dropped:0 overruns:0 frame:0
TX packets:140 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:12068 (12.0 KB) TX bytes:12068 (12.0 KB)
peth0 Link encap:Ethernet HWaddr 00:21:5e:96:07:94
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:72 errors:0 dropped:0 overruns:0 frame:0
TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5868 (5.8 KB) TX bytes:3760 (3.7 KB)
Interrupt:30 Memory:92000000-92012800
root@UbuntuTST-Blade:~# brctl show
bridge name bridge id STP enabled interfaces
eth0 8000.00215e960794 no peth0
After starting the domU, the xm create just hangs, and the domU stays in paused
state for 1m40s :
root@UbuntuTST-Blade:~# brctl show
bridge name bridge id STP enabled interfaces
eth0 8000.00215e960794 no peth0
tap1.0
root@UbuntuTST-Blade:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:21:5e:96:07:94
inet addr:172.17.4.46 Bcast:172.17.4.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3795 errors:0 dropped:0 overruns:0 frame:0
TX packets:808 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:230414 (230.4 KB) TX bytes:117990 (117.9 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:232 errors:0 dropped:0 overruns:0 frame:0
TX packets:232 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:20640 (20.6 KB) TX bytes:20640 (20.6 KB)
peth0 Link encap:Ethernet HWaddr 00:21:5e:96:07:94
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:3947 errors:0 dropped:0 overruns:0 frame:0
TX packets:966 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:314792 (314.7 KB) TX bytes:135314 (135.3 KB)
Interrupt:30 Memory:92000000-92012800
tap1.0 Link encap:Ethernet HWaddr 62:0f:06:f9:c4:d0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:55 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:3434 (3.4 KB)
root@UbuntuTST-Blade:~# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 31853 16 r----- 32.8
XPTST1 1 1024 1 --p--- 0.0
root@UbuntuTST-Blade:~#
At this step, if I manually unpause the domain, and cancel the xm create comand
to avoid it to destroy the domU after timeout, the domU starts and the network
is working.
If I just wait, the domU will be destroyed after timeout, and the tap interface
will be removed from the bridge.
So, it really seems to come from the vif-bridge script, but how can I debug it ?
Which arguments are passed to it ?
root@UbuntuTST-Blade:~# cat /etc/network/interfaces | grep -v
''^#\|^$''
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
root@UbuntuTST-Blade:~#
root@UbuntuTST-Blade:~# cat /etc/xen/XPTST1 | grep -v ''^#\|^$''
import os, re
arch = os.uname()[4]
if re.search(''64'', arch):
arch_libdir = ''lib64''
else:
arch_libdir = ''lib''
kernel = "/usr/lib/xen/boot/hvmloader"
builder=''hvm''
memory = 1024
shadow_memory = 8
name = "XPTST1"
vif = [ '''' ]
disk = [ ''file:/localstorage/XPTST1.img,hda,w'',
''file:/localstorage/install/WindowsXP-Pro-32.iso,hdc:cdrom,r''
]
device_model = ''/usr/'' + arch_libdir +
''/xen/bin/qemu-dm''
boot="dc"
sdl=0
vnc=1
vncconsole=1
stdvga=0
serial=''pty''
usbdevice=''tablet''
root@UbuntuTST-Blade:~#
----- Original Message -----
From: "Boris Derzhavets" <bderzhavets@yahoo.com>
To: xen-users@lists.xensource.com, xensource@pivert.org
Sent: Wednesday, 22 July, 2009 17:57:23 GMT +01:00 Amsterdam / Berlin / Bern /
Rome / Stockholm / Vienna
Subject: Re: [Xen-users] Xen 3.4.1-rc7 network problem
(vif/tap)> use eth0 as default bridge name ?
I guess , yes.
However,please, post:-
# brctl show
# ifconfig
Content /etc/init.d/networking (how you configure the bridge ?)
Profile of your DomU
Boris.
--- On Wed, 7/22/09, xensource@pivert.org <xensource@pivert.org> wrote:
From: xensource@pivert.org <xensource@pivert.org>
Subject: [Xen-users] Xen 3.4.1-rc7 network problem (vif/tap)
To: xen-users@lists.xensource.com
Date: Wednesday, July 22, 2009, 11:28 AM
Hi,
I''m now blocked for 2 days on getting the network to work in my domU.
Here is
the problem :
The domU refuses to start when a vif is configured. It''s just staying
paused
for about 1m40s, then the xm create command line give back with an
"Error: Device 0 (vif) could not be connected. Hotplug scripts not
working.",
and the domU is destroyed.
Nothing particular in the xend.log, xend-debug.log or qemu-dm-domUname.log.
However, if I manually unpause the domU, and cancel (<CTRL><C>) the
xm create
command to avoid the destruction of the domU after the 1m40s timeout, I get a
perfectly working domU with Network. Strangely, the vif network interfaces are
now named tap[domUid].[interface#] (ie tap2.0).
So, my questions :
- Why is there no clear log about vif-bridge script, and how can I debug this
script.
- Why are the interfaces named tapX.X instead of vifX.X ?
- Is there a default name for the bridge interface ? I''m currently
using
xenbr0, but I see that some documentations are talking about eth0, should I
use eth0 as default bridge name ?
Thanks,
François.
My config :
root@UbuntuTST-Blade:~# xm info
host : UbuntuTST-Blade
release : 2.6.31-rc3
version : #8 SMP Mon Jul 20 15:01:16 CEST 2009
machine : x86_64
nr_cpus : 16
nr_nodes : 1
cores_per_socket : 4
threads_per_core : 2
cpu_mhz : 2400
hw_caps :
bfebfbff:28100800:00000000:00000340:009ce3bd:00000000:00000001:00000000
virt_caps : hvm
total_memory : 36853
free_memory : 1043
node_to_cpu : node0:0-15
node_to_memory : node0:1043
xen_major : 3
xen_minor : 4
xen_extra : .1-rc7
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler : credit
xen_pagesize : 4096
platform_params : virt_start=0xffff800000000000
xen_changeset : Wed Jul 15 13:26:50 2009 +0100 19696:22ef8e900a6d
cc_compiler : gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
cc_compile_by : root
cc_compile_domain : local.modernprocessing.lu
cc_compile_date : Thu Jul 16 21:46:26 CEST 2009
xend_config_format : 4
root@UbuntuTST-Blade:~#
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
_______________________________________________ Xen-users mailing list
Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users