From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: Stubdom and blktap Date: Mon, 29 Sep 2008 12:31:34 +0100 Message-ID: <48E0BC96.3080109@eu.citrix.com> References: <48DF3509.8010003@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <48DF3509.8010003@intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Yang, Xiaowei" Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Yang, Xiaowei wrote: > Recently we had a try of stubdom, whose general status is good. > > One issue we found is with aio/sync blktap as backend, disk performance > is obviously slower, and there are some IDE kernel error messages (like > irq timeout) at boot time. I'll try to reproduce the problem, thanks for reporting it. > Another issue (not stubdom specific) comes from blktap's support for > QCOW image which is based on a backing file. We never tried this > configure before. The root cause is that in tdqcow_get_parent_id(), the > backing file is hard-coded to be QCOW type and tdqcow_validate_parent() > also presumes it, though the backing file is a raw image normally. With > the image type set correctly and a good method for image validation, > QCOW works. > I am not sure to understand what the issue is exactly: there is no image format guessing using blktap, the user is supposed to specify correctly the format in the VM configuration file.