We recently found a disk corruption issue with SLES11 SP1 guest. Basically the
guest disk becomes non-bootable after guest shutdown. This is a SLES specific
issue as we didn''t see on other Linux and Windows VMs. Here is the
configuration:
===========
1. Xen: xen-4.1-testing, changeset 23096
2. Dom0: Jeremy''s latest pvops 6d94b75 (June 1)
3. VM: SLES 11 SP1, installed as physical machine with raw disk format
===========
Regarding the disk before corruption, "file sles11sp1.img" command
read: "/root/guests/sles11-sp1/sles11sp1.img: x86 boot sector; partition 1:
ID=0x82, starthead 1, startsector 63, 4208967 sectors; partition 2: ID=0x83,
active, starthead 0, startsector 4209030, 16755795 sectors". After
corruption, it became a data file:
""/root/guests/sles11-sp1/sles11sp1.img: data".
I traced back to the blkback commit 28080265 by Konrad. If I disabled this
change, the corruption issue will disappear.
===========diff --git a/drivers/xen/blkback/blkback.c
b/drivers/xen/blkback/blkback.c
index fd88f32..30772ec 100644
--- a/drivers/xen/blkback/blkback.c
+++ b/drivers/xen/blkback/blkback.c
@@ -409,8 +409,7 @@ static void dispatch_rw_block_io(blkif_t *blkif,
break;
case BLKIF_OP_WRITE_BARRIER:
operation = WRITE_BARRIER;
- /* vbd_translate is alergic to bizzare sectors. */
- req->sector_number = 0;
break;
default:
operation = 0; /* make gcc happy */
===========
Thanks,
-Wei
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jul-06 21:57 UTC
[Xen-devel] Re: HVM guest disk corruption after shutdown
On Wed, Jul 06, 2011 at 02:22:30PM -0700, Huang2, Wei wrote:> We recently found a disk corruption issue with SLES11 SP1 guest. Basically the guest disk becomes non-bootable after guest shutdown. This is a SLES specific issue as we didn''t see on other Linux and Windows VMs. Here is the configuration: > ===========> > 1. Xen: xen-4.1-testing, changeset 23096 > > 2. Dom0: Jeremy''s latest pvops 6d94b75 (June 1) > > 3. VM: SLES 11 SP1, installed as physical machine with raw disk format > ===========> > Regarding the disk before corruption, "file sles11sp1.img" command read: "/root/guests/sles11-sp1/sles11sp1.img: x86 boot sector; partition 1: ID=0x82, starthead 1, startsector 63, 4208967 sectors; partition 2: ID=0x83, active, starthead 0, startsector 4209030, 16755795 sectors". After corruption, it became a data file: ""/root/guests/sles11-sp1/sles11sp1.img: data". > > I traced back to the blkback commit 28080265 by Konrad. If I disabled this change, the corruption issue will disappear.Oh nice. I wonder how the fix went in - I vagually remember talking to Jan about this and having a discussion and then using Jan''s patch instead of mine. Jeremy, can you revert it please? Jan posted a better fix that was ultimately better. Something along this upstream 8ab521506c4dbb144f0c04c55e3d8bec42c1b2b9 git commit> > ===========> diff --git a/drivers/xen/blkback/blkback.c b/drivers/xen/blkback/blkback.c > index fd88f32..30772ec 100644 > --- a/drivers/xen/blkback/blkback.c > +++ b/drivers/xen/blkback/blkback.c > @@ -409,8 +409,7 @@ static void dispatch_rw_block_io(blkif_t *blkif, > break; > case BLKIF_OP_WRITE_BARRIER: > operation = WRITE_BARRIER; > - /* vbd_translate is alergic to bizzare sectors. */ > - req->sector_number = 0; > break; > default: > operation = 0; /* make gcc happy */ > ===========> > Thanks, > -Wei > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel