Re: [Qemu-devel] Disk geometry and migration

[Blue Swirl]

On Tue, Jul 10, 2012 at 6:34 PM, Markus Armbruster <address@hidden> wrote:
> 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.

E. Detect the inconsistency and warn user

  Mismatch between physical and DOS geometry can be detected. Before
migration, output a warning message for the users. Perhaps QEMU should
do this on startup as well.

>
> Preferences?  Comments?
>

EACDB