From: "Sébastien Riccio" <sr@swisscenter.com>
To: Daniel Stodden <daniel.stodden@citrix.com>
Cc: "dmeyer@cs.ubc.ca" <dmeyer@cs.ubc.ca>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: xm/xl block-detach issue
Date: Tue, 12 Jul 2011 07:47:27 +0200 [thread overview]
Message-ID: <4E1BDFEF.6070104@swisscenter.com> (raw)
In-Reply-To: <1310420912.16930.21.camel@agari.van.xensource.com>
[-- Attachment #1.1: Type: text/plain, Size: 3865 bytes --]
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
[-- Attachment #1.2: Type: text/html, Size: 5442 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2011-07-12 5:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-09 14:34 xm/xl block-detach issue Sébastien Riccio
2011-07-09 17:28 ` Sébastien Riccio
2011-07-10 9:05 ` Daniel Stodden
2011-07-10 12:07 ` Sébastien Riccio
2011-07-10 18:19 ` Daniel Stodden
2011-07-11 17:09 ` Sébastien Riccio
2011-07-11 18:22 ` Daniel Stodden
2011-07-11 21:37 ` Sébastien Riccio
2011-07-11 21:48 ` Daniel Stodden
2011-07-12 5:21 ` Sébastien Riccio
2011-07-12 5:47 ` Sébastien Riccio [this message]
2011-07-12 5:30 ` Sébastien Riccio
2011-07-12 5:44 ` Sébastien Riccio
2011-07-13 8:32 ` Sébastien Riccio
2011-07-13 8:44 ` Sébastien Riccio
2011-07-29 14:25 ` Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E1BDFEF.6070104@swisscenter.com \
--to=sr@swisscenter.com \
--cc=daniel.stodden@citrix.com \
--cc=dmeyer@cs.ubc.ca \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.