[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 regression. Have a good weekend. Greg }-- 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 Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |