[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Scst-devel] iSCSI connection corrupts Xen block devices.

On Mar 26,  7:39am, matthew patton wrote:
} Subject: Re: [Scst-devel] iSCSI connection corrupts Xen block devices.

Hi Matt, thanks for taking the time to respond.

>> filesystem.The corruption doesn't occur when the VM shuts down, only
>> when the iSCSI connection is closed.

> Does it happen if the iscsi block device is NOT hosting the root
> filesystem but something else (eg. /var)? So you're netbooting the
> 2nd VM or have a separate /boot partition exported from dom0 with a
> sufficiently populated initrd that invokes an iSCSI initiator,
> mounts the block device and switches root? OR are you mounting the
> ISCSI target from VM1 (which is or portion thereof already a native
> device on dom0) as a second block device on dom0 and then adding
> that device to VM2's specification?
> If the 2nd route, you're doing it wrong. But going with it for the
> moment, having shut down VM2 and left the iSCSI session on dom0
> still running, have you loopback mounted and checked the VM2's root
> filesystem (aka the iSCSI LUN) to see if the filesystem is still
> intact? And if so, is it still intact when you check it from within
> VM1? And again check it on VM1 after you have logged out of the iSCS
> If you're doing the first method, how did you modify VM2's
> shutdown/reboot scripts to NOT yank the network out from underneath
> itself and likewise keep the iscsi session logged in till AFTER the
> root filesystem's blocks were flushed (remounted RO) before it did
> the power off/reset?

The Xen-SAN package uses the second method you noted above to allow
domU guests to participate in an iSCSI or FC storage are network.  The
notion of whether or not it is the 'right' way to do things is,
perhaps, a matter of perspective.

Implementing and staging a block device in dom0 allows the guests to
handle the root device without having to worry about initrd setups
and/or minimal boot implementations.  With the experience of having
used both methods extensiely we opted for dom0 staging.

Roger and Konrad both replied and the root cause of the problem is an
issue with the page grant mechanism which is used by both the network
and block backend drivers to reduce the need to copy pages between the
host and guest.  Fixing it is not straight forward and given the
somewhat niche status of this use case for storage target development
and testing, is not something which I would advocate to be a primary

Have a good weekend.


}-- End of excerpt from matthew patton

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@xxxxxxxxxxxx
"Opportunity is missed by most people because it is dressed in overalls
 and looks like work."
                                -- Thomas Edison

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.