From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH for 4.5] libxl: Tell qemu to use raw format when using a tapdisk Date: Wed, 10 Dec 2014 11:30:46 -0500 Message-ID: <20141210163046.GF4268@laptop.dumpdata.com> References: <1418133859-27763-1-git-send-email-george.dunlap@eu.citrix.com> <1418136501.14361.83.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1418136501.14361.83.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: George Dunlap , Ian Jackson , Wei Liu , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Tue, Dec 09, 2014 at 02:48:21PM +0000, Ian Campbell wrote: > On Tue, 2014-12-09 at 14:04 +0000, George Dunlap wrote: > > At the moment libxl unconditinally passes the underlying file format > > to qemu in the device string. However, when tapdisk is in use, > > tapdisk handles the underlying format and presents qemu with > > effectively a raw disk. When qemu looks at the tapdisk block device > > and doesn't find the image format it was looking for, it will fail. > > > > This effectively means that tapdisk cannot be used with HVM domains at > > the moment except for raw files. > > > > Instead, if we're using a tapdisk backend, tell qemu to use a raw file > > format. > > > > Signed-off-by: George Dunlap > > Acked-by: Ian Campbell Release-Acked-by: Konrad Rzeszutek Wilk > > > --- > > CC: Ian Campbell > > CC: Ian Jackson > > CC: Wei Liu > > CC: Konrad Wilk > > > > Release exception justification: > > I agree with your reasoning. > > > This fixes a bug in functionality, in > > that at the moment HVM guests cannot boot with tapdisk and vhd format. > > > > This is not a regression in xl functionality per se, since (AFAICT) > > this has never worked. However, given that 4.5 is the first release > > without xend, this *does* represent a regression in functionality for > > Xen as a whole (since before people using hvm guest with vhd on blktap > > could use xend). > > > > The fix is very simple and should only affect codepaths that already > > don't work, so the risk of regressions should be very low. > > > > While preparing this patch, I also noticed that cdroms will ignore the > > backend parameter and treat everything as a file. This is a bug but I > > think it's a much less important one to address this late in the > > release cycle. > > --- > > tools/libxl/libxl_dm.c | 7 +++++-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c > > index b25b574..10f3090 100644 > > --- a/tools/libxl/libxl_dm.c > > +++ b/tools/libxl/libxl_dm.c > > @@ -797,11 +797,14 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc, > > continue; > > } > > > > - if (disks[i].backend == LIBXL_DISK_BACKEND_TAP) > > + if (disks[i].backend == LIBXL_DISK_BACKEND_TAP) { > > + format = qemu_disk_format_string(LIBXL_DISK_FORMAT_RAW); > > pdev_path = libxl__blktap_devpath(gc, disks[i].pdev_path, > > disks[i].format); > > - else > > + } else { > > pdev_path = disks[i].pdev_path; > > + } > > + > > > > /* > > * Explicit sd disks are passed through as is. > >