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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 10 November 2017 09:53
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>; Roger Pau Monne
> <roger.pau@xxxxxxxxxx>; Mike Reardon <mule@xxxxxxxx>; Stefano Stabellini
> <sstabellini@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxx; Konrad Rzeszutek Wilk
> <konrad.wilk@xxxxxxxxxx>
> Subject: RE: [Xen-devel] [BUG] blkback reporting incorrect number of
> sectors, unable to boot
> 
> >>> On 10.11.17 at 10:40, <Paul.Durrant@xxxxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel