[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling
On Fri, Jun 04, 2010 at 11:37:51AM +0200, Michal Novotny wrote: > Oh, one more thing I've discovered now. Since the codebase for > qemu-xen-unstable is looking the same like for qemu-xen-3.4-testing and > the patch is applicable without any modifications it could be working > for xen-4.1 unstable as well, unfortunately I was not able to boot PVOPS > kernel since it always ends up in kernel panic, maybe the missing > drivers or something like that. > What kernel version? Did you use xen/stable-2.6.32.x branch from xen.git? See my example .config files from: http://wiki.xensource.com/xenwiki/XenParavirtOps in the "troubleshooting" section. Works on F12/F13 dom0's. For el5 dom0 you might need these: http://wiki.xensource.com/xenwiki/2.6.18-to-2.6.31-and-higher aka CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y Also atm I think you need CONFIG_XEN_XENBUS_FRONTEND=y in the .config because of the recently added pv-on-hvm drivers (you'll get build failure without that option), so you need XEN_PCIDEV_FRONTEND XEN_BLKDEV_FRONTEND or XEN_NETDEV_FRONTEND or XEN_FBDEV_FRONTEND needs to be =y. -- Pasi > On 06/03/2010 04:12 PM, Michal Novotny wrote: >> Oh, just one more thing that should be mentioned: >> >> When you want to mount an image that is set as read-only in the domain >> configuration file but you omit to set mode to read-only it results >> into I/O errors when processing the requests. Remounting as read-only >> or unmounting and remounting using the `mount /dev/* /path/to/mount -o >> ro` shall do the mounting the correct way, i.e. with no I/O errors, so >> make sure you mount those disks as read-only otherwise you can be >> getting errors like: >> >> end_request: I/O error, dev hdb, sector 52 >> >> Buffer I/O error on device hdb1, logical block 1 >> >> lost page write due to I/O error on hdb1 >> >> >> and for IDE devices you'll be getting several additional DeviceFault >> errors since mounting the device read-write (default setting) writes >> some data onto a disk at the mount-time. >> >> Michal >> >> On 06/03/2010 04:04 PM, Michal Novotny wrote: >>> [Well, I did send an e-mail to the list using git but it's not here >>> so I'm forwarding the e-mail to the list for sure:] >>> >>> Hi, >>> this is the patch for qemu-xen-3.4-testing to fix the read-only >>> image file handling since the image file was always treated as >>> read-write which means that all the HVM guests were able to >>> write to all the disk images available in domain configuration >>> file no matter what the mode of the image was defined. This >>> patch fixes this functionality to honor the O_RDONLY in the >>> BDRV_O_ACCESS flag in block.c and also fixes the IDE and SCSI >>> interfaces that uses it. >>> >>> It's been tested on RHEL-5 with xen-3.4-testing version of >>> upstream xen with xen-3.4-testing qemu implementation. >>> >>> For SCSI devices the DATA PROTECT request sense has been added >>> as found at: http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command >>> >>> file no matter what the mode of the image was defined. This >>> patch fixes this functionality to honor the O_RDONLY in the >>> BDRV_O_ACCESS flag in block.c and also fixes the IDE and SCSI >>> interfaces that uses it. >>> >>> It's been tested on RHEL-5 with xen-3.4-testing version of >>> Michal >>> >>> Signed-off-by: Michal Novotny <minovotn@xxxxxxxxxx> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@xxxxxxxxxxxxxxxxxxx >>> http://lists.xensource.com/xen-devel >> >> > > > -- > Michal Novotny<minovotn@xxxxxxxxxx>, RHCE > Virtualization Team (xen userspace), Red Hat > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |