| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
Re: [Xen-users] Re: Debian Squeeze, xen, multipath and iscsi
On Wed, Apr 06, 2011 at 12:08:37AM -0700, davide.vaghetti@xxxxxxxxxxxx wrote:
> Hi,
>
> I had the very same problem. After getting almost mad trying to fix the
> issue mixing different combination of boot option I followed the advice of
> Henrik: let the multipath be completely loaded __before__ the iscsi daemon.
> That is, don't let the open-iscsi be loaded at boot time, or at least remove
> it from the relevant runlevel and load via rc.local. In my environment that
> fixed the issue (the latest kernel update from Debian do not make any
> difference).
Hi Davide,
I had to reboot my Xen host recently and upon iSCSI login I repeatedly ran
into that same problem. I don't do any automatic iSCSI logins during boot
and I don't start any Xen guest on boot. So the system _was_ completely up
and idle. Still everytime I did the iscsi login (which currently logs in
to 12 volumes via 2 paths each) I ended up with a CPUs stuck for a minute
or something plainly wrong like this:
[225060.039126] BUG: unable to handle kernel paging request at ffff88001558b010
[225060.039172] IP: [<ffffffff8100e428>] xen_set_pmd+0x15/0x2c
[225060.039210] PGD 1002067 PUD 1006067 PMD 18a067 PTE 801000001558b065
[225060.039253] Oops: 0003 [#1] SMP
[225060.039284] last sysfs file: /sys/devices/virtual/block/dm-6/dm/suspended
[225060.039319] CPU 0
...
where kpartx_id or udevd or any other part of the device mapper eco system
would trigger a memory management problem.
The workaround "hold your breath and cross your fingers"-style was to
- stop the multipath daemon, then
- do the iSCSI login, and then
- restart the mutipath daemon.
like this:
/etc/init.d/multipath-tools stop
sleep 5
iscsiadm -m node -p '192.168.0.1:3260' --login
sleep 5
/etc/init.d/multipath-tools start
( while alternately praying and cursing. ;-) )
That way I was able to login to all iSCSI targets without immediately
triggering bugs / race conditions.
Actually I am not sure that I need the multipathd at all. I have after all a
pretty
simple setup.
# multipath -ll
...
36090a068302e3e73a9d4041bd000e0b3 dm-11 EQLOGIC,100E-00
size=10G features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=2 status=active
|- 24:0:0:0 sdt 65:48 active ready running
`- 23:0:0:0 sdo 8:224 active ready running
36090a068302e4ee710d5341bd000a04b dm-16 EQLOGIC,100E-00
size=38G features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=2 status=active
|- 20:0:0:0 sdl 8:176 active ready running
`- 19:0:0:0 sdk 8:160 active ready running
...
My host has two gigabit interfaces that are dedicated to storage traffic.
Each connects to a switch that connects to one of the controllers of my
storage. There is no cross-connect between the switches. So if any one
part fails, then one path is unavailable but there should be no need to
reconfigure anything. Could anybody hit me with a clue stick? ;-)
Did anybody try a different Dom0 system?
I am tempted to try XCP as Dom0 instead of Debian but I'd love to
know if anybody else already did that switch and what their experience
was.
Does anybody have experience with iSCSI and multipath on XCP ?
cheers
-henrik
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home