[Qemu-devel] Geometry and blocksize support for backing devices

[Christian Borntraeger <borntraeger@de.ibm.com>]

Markus, Kevin, Stefan,

here is a (somewhat late) followup of some KVM forum discussions regarding
block size and geometry of pass-through block devices. Let's just do a quick
wrap-up (as of my understanding) and a proposal at the end of the mail





- DASD/ECKD disk devices have several special properties, e.g. the geometry 
  still has an influence on the partitions and each track can have a different
  format and the format of the disk actually follows what z/OS has as basic
  data structures. Linux does a low-level format of the disk to look like a
  block device (most common case is formatted with 4K blocks). There are 
  still some smalls warts for z/OS compatibility (block0 has 28 bytes of data,
  block1 has 148 bytes and block2 has 84 bytes of data. everything else has
  4k. the dasd device driver will fake 4k blocks for all blocks by ignoring 
  writes beyond the data for blocks 0-2 and filling the gaps with 0xe5).

- Since Linux uses DASDs as normal block device, we actually want to use 
  virtio-blk to pass those to KVM guests. Due to the warts mentioned above,
  we have to have the proper block size and geometry in the guest. Otherwise 
  things will fail in certain cases (linux partition detection for example)

- we have libvirt support to provide this information in the XML. This is far 
  from user friendly, though, as the admin has to manually look up the
  properties of the host disks and then modify the guest definition accordingly.

- Kate came up with patches (based on initial patches from Einar Lueck) for
  auto-detection of geometry and block size for host block devices

- Stefan and Paolo had some concerns:
1. if the geometry etc is important, then make it part of the guest definition
2. what about migration and the target disk differs
3. is that issue system z specific or generic?

Regarding 1: this does work as of today, but it is pretty complicated for an
admin to do so

Regarding 2: System z system do not have built-in disks, they are always
accessed via fibre channel (either FICON protocol for DASDs or FCP protocol
for scsi). So its quite common to have shared access to the same disk from 
different System z boxes. system z admins should be able to setup this 
properly. Question is, is it ok to assume that and fail if not?

Regarding 3: No idea. 

At KVM forum I talked to several people regarding a solution:

a) Stefan suggested to make the auto detection explicit, e.g.: provide a
"autodetect" tag for the secs, cylc, heads and logical_sector_size properties
This would require changes in qemu, but also in libvirt and its domain
configuration
b) Markus suggested that there are already some cases in QEMU, where we rely
on the admin to provide a proper setup on the target, e.g. an .iso file as image.
If the target has a different content in the .iso file things will break.

Markus said, there are two classes of this.
a) problems that can be detected by QEMU. Here QEMU will abort migration
b) problems that cannot be detected by QEMU (e.g. different iso content). this
will trigger failures later on

a is preferred

Now here comes my proposal:
Markus statement brought up an idea of special casing DASDs support. We can
call an ioctl BIODASDINFO on the block device that will only succeed if the host
disk is really a dasd. We could enable the auto detection for that case.
In addition, QEMU will check if geometry and block size match during migration, if
not, migration will fail. That would work with the following cases

(manual override == secs, cyls, headers, blocksize given by admin)

HOST A                          HOST B
dasd (auto)            ----->   dasd (auto)
dasd (auto)            ----->   image file (manual override)
image file (manual)    ----->   dasd (auto)
image file (manual)    ----->   image file (manual)
dasd (auto)            ----->   other host block device with manual override

if there are different dasds or different value migration will fail (and that is
what we want)

In addition we could also implement Stefans proposal to add a "autodetect" statement
for secs, cyls, head.... but I am not sure about libvirt support, though

So 3 parts:
1. autodetect on real DASDs 
2. geometry and sector size checking in generic code
3. maybe an autodetect flag

makes sense? Any guidance how to proceed?

Christian