Re: [Qemu-devel] Disk geometry and migration

[Markus Armbruster]

Blue Swirl <address@hidden> writes:

> 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.

Define "mismatch".  Differences between physical and logical geometry
are normal (otherwise we wouldnt' have logical geometry).  So, what kind
of difference should trigger warnings?

Note that a warning message is prone to be buried in logs, where nobody
sees it until something goes wrong badly enough to make someone examine
the logs.

Double-checking: you suggest to migrate regardless of the warning, don't
you?

>> Preferences?  Comments?
>>
>
> EACDB