Re: [BUG] blkback reporting incorrect number of sectors, unable to boot

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 10 November 2017 09:53
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: Anthony Perard <anthony.perard@citrix.com>; Roger Pau Monne
> <roger.pau@citrix.com>; Mike Reardon <mule@inso.org>; Stefano Stabellini
> <sstabellini@kernel.org>; xen-devel@lists.xen.org; Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com>
> Subject: RE: [Xen-devel] [BUG] blkback reporting incorrect number of
> sectors, unable to boot
> 
> >>> On 10.11.17 at 10:40, <Paul.Durrant@citrix.com> wrote:
> >> Anthony PERARD
> >> Sent: 09 November 2017 17:50
> >> The problem is that QEMU 4.10 have a lock on the disk image. When
> >> booting an HVM guest with a qdisk backend, the disk is open twice, but
> >> can only be locked once, so when the pv disk is been initialized, the
> >> initialisation kind of fail.
> >> Unfortunatly, OVMF will wait indefinitly until the PV disk is
> >> initialized.
> >
> > That's presumably because the OVMF frontend leaves the emulated disk
> plugged
> > in despite talking via PV?
> 
> Well, how could it not? It can't know whether the OS to be booted
> is going to have PV drivers, and iirc the unplug is not reversible.

Oh, quite, but this is a fundamental problem if QEMU believes that it is not safe to open the underlying storage shared read-write (which would be the case for a qcow, or vhd where there is metadata to worry about). QEMU will open the storage as soon as the emulated device is realised so when xen_disk tries to open it again at connect time, it's always going to fail.

  Paul

> Shouldn't OVMF close the blkif connection, with the backend
> responding to this by unlocking (and maybe closing) the image?
> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel