[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Disk geometry and migration
From: |
Markus Armbruster |
Subject: |
[Qemu-devel] Disk geometry and migration |
Date: |
Tue, 10 Jul 2012 20:34:52 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) |
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?
- [Qemu-devel] Disk geometry and migration,
Markus Armbruster <=