On 13 Jun 2019, at 12:38, Gerd Hoffmann kraxel@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