> On 13 Jun 2019, at 12:38, Gerd Hoffmann <kra...@redhat.com> wrote:
>
> Hi,
>
>> Yes they are pretty rare.
>> Windows 2000 and Windows XP guests migrated from VMware to Qemu/KVM
>> would not boot due to incorrect disk geometries (some had 32/56 spt instead
>> of
>> 56. Also number of heads was not entirely correct)
>
> Ok.
>
>>> Why? Asking the user to deal with the mess is pretty lame if there are
>>> better options. And IMO doing this fully automatic in seabios is
>>> better.
>>
>> I’m not against an automatic approach, however I do think that doing this
>> in SeaBIOS might break compatibility for already existing guests that will
>> suddenly see different LCHS values. (Explanation below)
>
>>> I can't see how this can break guests. It should either have no effect
>>> (guests using LBA) or unbreak guests due to LCHS changing from "wrong"
>>> to "correct”.
>>
>> I’m not sure what do you mean by "unbreak guests” if you change an existing
>> guest that uses LCHS from 56 spt to LBA (63 spt) it will stop booting.
>
> Well, that LCHS change happens because you move the guest from vmware to
> qemu and seabios uses 63 spt no matter what if the disk is too big for
> chs addressing.
>
> When seabios is changed to look at the MBR to figure what the lchs of
> the disk is that will make your guest boot.
See below
>
>> Your guessing algorithm will have to guess 56, if it will fail guessing 56
>> correctly,
>> the user can not perform any action beside downgrading SeaBIOS in order to
>> run
>> the guest.
>
> Sure, if the guess is wrong then the guest will not boot. That isn't
> worse than the situation we have today where seabios will not even try
> to figure what the lchs of the disk is.
>
> And, no, downgrading seabios will not make your vmware guest with 56 spt
> boot.
I’m not talking about the vmware case here.
If you introduce MBR guessing into SeaBIOS and change its default behaviour you
risk making operating systems such as Windows XP / 2003 / 2000 created on
QEMU to not work anymore.
Example:
Consider a Windows XP that works with the following geometries on
standard
QEMU/SeaBIOS today:
Disk is very large, therefore INT13 AH=02:
255 heads, 63 spt
Now you change SeaBIOS to guess from the MBR.
In some cases the MBR guess can be incorrect so now SeaBIOS will guess:
255 heads, 62 spt
The guest no longer boots with these geometries and you broke
compatibility.
Can there be a guest that will fail the MBR in such a way? Yes.
Look at the following MBR partition table of a Windows XP guest in our
production
environment:
Disk size in sectors: 16777216
Binary (only one partition 16 bytes): 80 01 01 00 07 fe ff ff 3f 00 00 00 d5 ea
ff 00
Start: (0, 1, 1, 63)
End: (1023, 254, 63, 16771859)
As can be easily seen, any MBR guessing algorithm should guess:
255 heads (since a value of 254 appears), 63 spt (since a value of 63
appears)
Turns out that this image does not work with 255, 63 but actually requires
16 heads, 63 spt
to boot.
So relying on MBR partitions alone is not always enough and sometimes manual
intervention
is required.
(VMware solves this by specifying 16 heads, 63 spt in the descriptor file and
overrides its
default guessing algorithm which also fails here)
(By the way this is not a VMware specific problem, the disk itself was imported
to VMware in
a P2V scenario, so that probably explains why the ddb.geometry.bios* values
appear in the
VMDK in the first place)
>
> cheers,
> Gerd
>
