Re: [Qemu-devel] [PATCH v5 0/5] Geometry and blocksize detection for backing devices.

[Stefan Hajnoczi]

On Thu, Dec 18, 2014 at 12:17:59PM +0100, Ekaterina Tumanova wrote:
> Updates v4 -> v5:
> 
> Minor Updates according the last review from Markus:
> 1. update commit message for patch 2
> 2. fix comment typos
> 3. fix check_for_dasd to return -1 instead of -ENOTSUP
> 
> Thanks,
> Kate.
> 
> ---------------------------------------------------------------
>    Patchset Description (didn't change):
> 
> Proper geometry and blocksize information is vital for support of
> DASD/ECKD drives in Linux guests. Otherwise things will fail in
> certain cases.
> 
> The existing geometry and blocksize qemu defaults have no sense
> for DASD drives (hd_geometry_guess detection and 512 for sizes).
> Setting this information manually in XML file is far from user-friendly,
> as the admin has to manually look up the properties of the
> host disks and then modify the guest definition accordingly.

What is the expected behavior when you dd the disk image from the DASD
to a raw image file on an NFS file system on the host?

It seems you'd lose the geometry detection and the disk image could be
unusable from inside the guest.

> Since Linux uses DASDs as normal block devices, we actually
> want to use virtio-blk to pass those to KVM guests.
> 
> In order to avoid any change in behavior of other drives, the DASD
> special casing was advised. We call ioctl BIODASDINFO2 on the block
> device, which will only succeed if the device is really a DASD.
> 
> In order to retrieve the underlying device geometry and blocksizes
> a new block-backend functions and underlying driver functions were
> introduced (blk_probe_blocksizes anf blk_probe_geometry wrappers
> and corresponding bdrv_xxxxxx functions).
> 
> As for now only "host_device" driver received new detection methods.
> For "raw" we call childs method as usual. In future one may update
> other drivers to add some other detection heuristics.
> 
> If the host_device appears to be a DASD, the driver functions
> (hdev_probe_blocksizes and hdev_probe_geometry) will call certain
> ioctls in order to detect geometry and blocksizes of the underlying device.
> if probing failed bdrv_probe_blocksizes caller will set defaults,
> and bdrv_probe_geometry will fail to allow fallback to old detection logic.
> 
> The front-end (BlockConf API) was updated:
> 1. a new blkconf_blocksizes function was added. It doesn't
> change user-defined blocksize values. If properties are unset, it will
> set values, returned by blk_probe_backend. In order to allow this logic,
> blocksize properties were initialized with 0. (driver will return 512 if
> backing device probing didn't succeed or if driver method is not defined).
> 2. hd_geometry guess was changed to firstly try to retrieve values via
> blk_probe_geometry and if it fails, fallback to the old logic.

Thanks for the detailed cover letter, it's much more than I had in mind
when I requested a cover letter.  I'm looking for an overview of the
problem this series fixes and the rationale for the solution.  It's not
necessary to explain the individual code changes in the cover letter
since they are already covered by the patches.

pgpBDBRPzar9l.pgp
Description: PGP signature