RE: [Xen-users] iSCSI domU - introducing more stability

["netz-haut - stephan seitz" <s.seitz@xxxxxxxxxxxx>]

> > during peak load on some running domU, I noticed random iSCSI
> "Reported LUNs data has changed" which forced me to shutdown the
> respective domU, re-login the target and do a fsck before starting domU
> again.
> >
> 
> Which one logs in to iscsi targets? Dom0 or domUs?
> What is your iscsi target? Linux? An appliance? Is there any error
> message on the  target?

I adopted the block-iscsi script which has been posted on the list a while ago.
It logs in to the respective target on dom0 for each domU. Every domU gets at 
least
one LUN with at least one root partition on it. Most domUs are identical 
configured
with two block devices; one is a LUN with two partitions: root fs ext3 and low 
prio
swap; the other block device is located on local dom0 LVM: a LV with a high 
prio swap.
iSCSI target is a iStor IntegraStor is325 appliance. The appliance takes the 
problem
not really serious. It shows "Reported LUNs data has changed" followed by a 
"Scheduled
Transaction". This is marked as warning, not as failure.
The open-iscsi initiater seems to have more problems. It never received (or 
initiated?)
the scheduled transaction. It marks the LUN as readonly device immediately. 
Depending
on the workload, the domU has obviously some bigger problems with a readonly 
root fs...
I've read about cpu saturation and iscsi timeouts, but I'm pretty sure (from 
dom0 view)
there's enough hardware overhead for I/O. From domU's view, the cpu can and 
will be
saturated by large block I/O. E.g. tar'ing some 800Gigs will kick the load on 
domU up
to about 40-50. Some voodoo which I've never seen on physical machines ;)




_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users