[Qemu-devel] Disk geometry and migration

[Markus Armbruster <armbru@redhat.com>]

Scenario:

1. Start a guest with a blank disk (need not be the only disk) and
   default disk geometry.

2. Examine the disk's physical geometry

   Details depend on the device model.  scsi-hd exposes it in mode pages
   4 and 5.  ide-hd in command IDENTIFY, and in its translation from CHS
   to LBA.  virtio-blk in its device configuration (optional, feature
   bit VIRTIO_BLK_F_GEOMETRY).

3. Partition the disk with a DOS partition table

4. Examine the disk's physical geometry

5. Migrate

6. Examine the disk's physical geometry

Bug: if the end of the first valid entry in partition table created in
step 2 has a CHS address with H < 15, the physical geometry in step 6 is
different than the one in steps 2 and 4.  How come?

QEMU picks default physical geometry based on image size and DOS
partition table.

In step 1, there is no partition table, and QEMU picks 16 heads, 63
sectors per track.

In step 5, there is a partition table, and the destination QEMU picks a
geometry that matches it.  Which may differ from the previous one.

Possible solutions:

A. Migrate physical geometry

   Possible once my recent geometry series is merged.  Devil's in the
   compatibility details.  We need to send a geometry subsection when
   the current MBR will make the destination QEMU pick a different
   geometry.  Thus, guest updating a DOS partition table may prevent
   migration to an older QEMU.

   The geometry change still happens on the next non-migration QEMU
   restart.  Implies cold boot, so hardware changes are tolerable.
   Document as feature.  If you want to keep physical geometry stable,
   don't rely on default geometry, specify one.

B. Make physical geometry invisible to the guest

   SCSI: the geometry mode pages are obsolete since SBC-3 (2005).  Guest
   software choking on their absence seems unlikely, but not impossible.

   virtio-blk: geometry information is optional.  But since we've always
   provided it, it's conceivable that some guest software depends on its
   presence.

   IDE: I'm afraid we can't do.  CHS addressing is obsolete in ATA-7
   (2008).  ATA-4 (1998) requires it for disks up to 16,514,064 sectors.
   Plenty of old software uses it.

   To be precise, old software may talk CHS to the disk.  It can also
   talk CHS to the BIOS (int 13h), but that's a separate, logical
   geometry.  The BIOS makes it up from physical geometry (which it
   finds in CMOS) with a translation method (also from CMOS).  Since it
   makes it up during initialization, it doesn't change even when
   migration screws up physical geometry.  Since SeaBIOS translates
   logical geometry to LBA, *not* CHS, it even keeps working.

C. Do not derive default geometry from DOS partition table

   Can do only for new machine type, because it may break guests.

D. Document as feature

   If you want to keep physical geometry stable under migration, specify
   the correct geometry on the destination.

Preferences?  Comments?