* [Qemu-devel] Disk geometry and migration
@ 2012-07-10 18:34 Markus Armbruster
2012-07-10 19:42 ` Blue Swirl
0 siblings, 1 reply; 4+ messages in thread
From: Markus Armbruster @ 2012-07-10 18:34 UTC (permalink / raw)
To: qemu-devel; +Cc: Kevin Wolf, Paolo Bonzini, Juan Quintela
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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] Disk geometry and migration
2012-07-10 18:34 [Qemu-devel] Disk geometry and migration Markus Armbruster
@ 2012-07-10 19:42 ` Blue Swirl
2012-07-11 7:16 ` Markus Armbruster
0 siblings, 1 reply; 4+ messages in thread
From: Blue Swirl @ 2012-07-10 19:42 UTC (permalink / raw)
To: Markus Armbruster; +Cc: Kevin Wolf, Paolo Bonzini, qemu-devel, Juan Quintela
On Tue, Jul 10, 2012 at 6:34 PM, Markus Armbruster <armbru@redhat.com> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] Disk geometry and migration
2012-07-10 19:42 ` Blue Swirl
@ 2012-07-11 7:16 ` Markus Armbruster
2012-07-11 7:57 ` Paolo Bonzini
0 siblings, 1 reply; 4+ messages in thread
From: Markus Armbruster @ 2012-07-11 7:16 UTC (permalink / raw)
To: Blue Swirl; +Cc: Kevin Wolf, Paolo Bonzini, qemu-devel, Juan Quintela
Blue Swirl <blauwirbel@gmail.com> writes:
> On Tue, Jul 10, 2012 at 6:34 PM, Markus Armbruster <armbru@redhat.com> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] Disk geometry and migration
2012-07-11 7:16 ` Markus Armbruster
@ 2012-07-11 7:57 ` Paolo Bonzini
0 siblings, 0 replies; 4+ messages in thread
From: Paolo Bonzini @ 2012-07-11 7:57 UTC (permalink / raw)
To: Markus Armbruster; +Cc: Blue Swirl, Kevin Wolf, qemu-devel, Juan Quintela
Il 11/07/2012 09:16, Markus Armbruster ha scritto:
>>> C. Do not derive default geometry from DOS partition table
>>>
>>> Can do only for new machine type, because it may break guests.
It will indeed break boot of old images (e.g. FreeDOS). Hence:
C1. Do not derive default geometry from DOS partition table.
Dig out an old PC (the kind where you had to customize manually
the CHS in the BIOS setup) and make a list of valid CHS values.
Warn at startup if the disk is smaller than the biggest value
in the table _and_ geometry is not in the table and is not
specified manually.
This will still be doable only for new machine types, but perhaps for
old machine types we can print a warning if the guess does not match the
result of the above algorithm. Then deprecate the guessing in a few
releases, even for old machine types.
Of course, teh Google is a good replacement from digging out an old PC.
http://www.modemsoft.it/bios.html gives the following table, with only
two ambiguous settings:
C H S sectors MB | alt C alt H alt S
-------------------------------------------|
306 4 17 20808 10.1602
306 5 17 26010 12.7002
1024 2 17 34816 17
306 8 17 41616 20.3203 | 612 4 17
615 4 17 41820 20.4199 | 820 3 17
733 5 17 62305 30.4224
615 6 17 62730 30.6299
462 8 17 62832 30.6797
977 4 17 66436 32.4395
855 5 17 72675 35.4858
809 6 17 82518 40.292
977 5 17 83045 40.5493
820 6 17 83640 40.8398
1024 5 17 87040 42.5
733 7 17 87227 42.5913
940 6 17 95880 46.8164
855 7 17 101745 49.6802
977 7 17 116263 56.769
1024 7 17 121856 59.5
809 6 26 126204 61.623
940 8 17 127840 62.4219
1024 5 26 133120 65
1024 8 17 139264 68
1224 7 17 145656 71.1211
1024 9 17 156672 76.5
918 11 17 171666 83.8213
925 11 17 172975 84.4604
1024 10 17 174080 85
1224 9 17 187272 91.4414
776 8 33 204864 100.031
1024 12 17 208896 102
1024 13 17 226304 110.5
1224 11 17 228888 111.762
900 15 17 229500 112.061
918 15 17 234090 114.302
1024 14 17 243712 119
1024 15 17 261120 127.5
1024 16 17 278528 136
684 16 38 415872 203.062
(let's also add 1024/16/63 to the list). Just before sending I found a
more complete table at
http://www.win.tue.nl/~aeb/linux/hdtypes/hdtypes-3.html.
Paolo
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-07-11 7:57 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-10 18:34 [Qemu-devel] Disk geometry and migration Markus Armbruster
2012-07-10 19:42 ` Blue Swirl
2012-07-11 7:16 ` Markus Armbruster
2012-07-11 7:57 ` Paolo Bonzini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).