From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Haigh Subject: Re: Xen 3.0.3 tap:aio disk image fails on RAID5/XFS filesystem Date: Tue, 27 Apr 2010 23:12:00 +1000 Message-ID: References: <20100427090054.GS17817@reaktio.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Steven Haigh Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Tue, 27 Apr 2010 19:48:01 +1000, Steven Haigh wrote= : > On Tue, 27 Apr 2010 12:00:54 +0300, Pasi K=C3=A4rkk=C3=A4inen wrote: >> On Tue, Apr 27, 2010 at 05:19:54PM +1000, Steven Haigh wrote: >>>=20 >>> On Tue, 27 Apr 2010 14:01:17 +1000, Steven Haigh >>> wrote: >>> > Hi all, >>> >=20 >>> > Upon bashing my head against a wall trying to get Xen working on my > new >>> > hardware I came across an interesting discovery. Every install usin= g >>> > virt-install was failing and I could only use the file: access method >>> for >>> > my DomUs. Every time I tries to use tap:aio the guest would error o= n >>> boot >>> > saying it couldn't find the root partition. >>> >=20 >>> > My system is as follows: >>> > OS: CentOS 5.4 >>> > Xen: 3.0.3-94.el5_4.3 >>> > / =3D 2 x 80Gb HDDs, dmraid1, ext3 >>> > /mnt/raid =3D 3 x 1Tb HDDs, dmraid5, xfs >>> >=20 >>> > On whim, I moved the DomU images from /mnt/raid/vm-images to > /vm-images >>> > and instantly tap:aio worked again. >>> >=20 >>> > This brings me to my question: >>> >=20 >>> > Why would tap:aio fail when the images are on an XFS/RAID5 filesystem >>> but >>> > work correctly when on a RAID1/ext3 filesystem? >>> >=20 >>> > To me, this seems like a bug. >>>=20 >>> Oh, and for the record, this is my config file: >>>=20 >>> name =3D "mail.crc.id.au" >>> uuid =3D "929c5a29-10c2-b388-ff01-42110c4ea66e" >>> maxmem =3D 512 >>> memory =3D 512 >>> vcpus =3D 2 >>> bootloader =3D "/usr/bin/pygrub" >>> on_poweroff =3D "destroy" >>> on_reboot =3D "restart" >>> on_crash =3D "restart" >>> #disk =3D [ "file:/vm-images/mail.crc.id.au.img,xvda,w" ] >>> disk =3D [ "tap:aio:/vm-images/mail.crc.id.au.img,xvda,w" ] >>> vif =3D [ "mac=3D00:16:3E:00:00:13, bridge=3Dvirbr0" ] >>>=20 >>=20 >> Since you're using EL5 distribution you might want to search Redhat >> bugzilla >> to see if there are already existing bugreports about this issue. >>=20 >=20 > I did have a hunt around - but I couldn't locate anything relevant - hence > my post here to see if it is anything that is already known - and maybe > documented somewhere... For what it's worth, a bit more digging turned up this: https://bugzilla.redhat.com/show_bug.cgi?id=3D217098 As I'm not quite cluey enough to know exactly what was discovered in this bug report, I can't say for sure if it is related - however I have filed this:=20 https://bugzilla.redhat.com/show_bug.cgi?id=3D586387 I believe I have tagged this correctly as a kmod-xfs bug - as I don't believe it is a problem with Xen as such - however any hints / contributions to the bug report would be appreciated. --=20 Steven Haigh =20 Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299