| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] xm/xl block-detach issue
Hi again :)
Going further with my investigations, I'm definitively now sure that
it's not an issue with ocfs2.
Same behavior occures on a local file.
There is really something going wrong with xm/xl. In order to
continue my tests I've tried to attach
and .img (raw) file and this time not attaching it to dom0 but to a
running domU vm:
no way with xl
box# xl block-attach 2 file:/cloud/data2/images/xen/slackware.13-37.x86.20110428/slackware.13-37.x86.20110428.img
xvdc w
libxl_device_disk_add failed.
with xm
box# xm block-attach 2 file:/cloud/data2/images/xen/slackware.13-37.x86.20110428/slackware.13-37.x86.20110428.img
xvdc w
this worked. Now trying to list with xl :
box# xl block-list 2
Vdev BE handle state evt-ch ring-ref BE-path
Segmentation fault
box# xm block-list 2
Vdev BE handle state evt-ch ring-ref BE-path
51712 0 0 4 23 8
/local/domain/0/backend/vbd/2/51712
51728 0 0 4 24 17
/local/domain/0/backend/vbd/2/51728
51744 0 0 4 25 50
/local/domain/0/backend/vbd/2/51744
Unplugging with xm:
box# xm block-detach 2 51744
box# xm block-list 2
Vdev BE handle state evt-ch ring-ref BE-path
51712 0 0 4 23 8
/local/domain/0/backend/vbd/2/51712
51728 0 0 4 24 17
/local/domain/0/backend/vbd/2/51728
Gone :)
Summary:
1) block-attach / block-detach / block-list actions issued from xl
and xm are not having the same behaviors,
xl tend to crash a lot and mess things.
2) attaching an .img file with xm and file:/ let me
detach it with xm block-detach
3) attaching a .vhd file with xm and tap:vhd:/ does not let
me detach it with xm block-detach
I almost got rid of all specialities on my box, except maybe
konrad's 2.6.39.2 kernel. This is a quite serious issue, am I the
only one able to reproduce it ?
For information, we've tried the same action (xl block-attach and xl
block-detach of a vhd on XenServer 6.0 beta (project boston) and the
same
issue happens, can't detach it, then it throws ugly messages at
console:
Message from syslogd@ at Mon Jul 11 21:13:43 2011 ...
xenblade13 kernel: ------------[ cut here ]------------
Message from syslogd@ at Mon Jul 11 21:13:43 2011 ...
xenblade13 kernel: invalid opcode: 0000 [#1] SMP
Message from syslogd@ at Mon Jul 11 21:13:43 2011 ...
xenblade13 kernel: last sysfs file:
/sys/devices/xen-backend/vbd-0-51712/statistics/rd_usecs
Message from syslogd@ at Mon Jul 11 21:13:43 2011 ...
xenblade13 kernel: Process xenwatch (pid: 48, ti=ee9d0000
task=ee8d5070 task.ti=ee9d0000)
Message from syslogd@ at Mon Jul 11 21:13:43 2011 ...
xenblade13 kernel: Stack:
Message from syslogd@ at Mon Jul 11 21:13:43 2011 ...
xenblade13 kernel: Call Trace:
Message from syslogd@ at Mon Jul 11 21:13:43 2011 ...
xenblade13 kernel: Code: 88 ff ff e9 5c ff ff ff 89 44 24 04 c7 44
24 08 2e a1 44 c0 8b 4d ec 89 0c 24 e8 62 88 ff ff 89 f8 e8 db ee ff
ff e9 f7 fe ff ff <0f> 0b eb fe 66 90 ba 98 00 00 00 b8 ba a0
44 c0 e8 61 48 e8 ff
Message from syslogd@ at Mon Jul 11 21:13:43 2011 ...
xenblade13 kernel: EIP: [<c02a985a>]
blkback_queue_start+0x2ca/0x2f0 SS:ESP 0069:ee9d1f38
So my conclusions are that something is not right with xl/xm
commands and block attaching/detaching. I guess XenServer is not
using
this method to attach/detach disks as attaching them with xe
commands and with xencenter do not show any problems.
Could someone try it on their side and confirms if this is a
confirmed problem ? That would be nice to fix it if it's the case,
as shipping xen with a "russian roulette" enabled xm/xl is maybe not
the best :)
I can provide root access to my test machines if you want to try
things on the best :)
Cheers,
Sébastien
|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home