[vbox-dev] [PATCH] Fix for Guest "OS type" future-compatibility

[Alexey Eromenko]

1. Things like "CMPXCHG16B", PAE/NX might just become "hidden" VM
settings. Same as Firmware = BIOS or EFI. (not even needed in GUI, but
setting "Windows 8" should automatically enable them).

2. My patch doesn't delete "OS type" information from *.vbox files,
until user actually changes any VM settings for a particular VM.

3. When he re-upgrades to new VirtualBox, he can manually choose the
right OS type (Windows 8 or 10).

4. This is way better than having inaccessible VMs.

5. Why "CMPXCHG16B", "NX/PAE" and other such instructions are not
enabled by default ?

On Fri, May 8, 2015 at 3:44 PM, Klaus Espenlaub
<klaus.espenlaub at oracle.com> wrote:
> Hi Alexey,
>
> On 08.05.2015 00:08, Alexey Eromenko wrote:
>> Hi,
>>
>> Today if I revert to older VirtualBox (to 4.3.20) from newer (v5.0
>> BETA), I lose access to certain VMs, such as "Windows 10", because it
>> has a new guest OS type ID.
>>
>> Those VMs become "inaccessible" for no good reason. I can understand a
>> VM becoming "inaccessible" if hard disk new format is coming or a disk
>> image is lacking, but Guest OS type ?
>
> Yes, it's intentional. The reason is that VirtualBox uses it for certain
> small detail "tweaks" - like for Windows 8.1 it enables the CMPXCHG16B
> instruction support.
>
>> My patch allows to recognize and start VMs with future guest OS type
>> IDs. They will revert to "unknown" OS type.
>
> See above. Possible loss of significant information, which might make
> some VMs fail to run in the new version after upgrading again. That's
> why we opted for making the VMs inaccessible.
>
> We're running into such issues ourselves, and we keep re-evaluating out
> options, but so far we decided that the risk outweighs the benefits of
> being more generous with new configs in old versions.
>
> Another way to look at it: predicting the effects of such "config
> adjustments" would need a time machine: this code needs to be in the
> "old" version, which means that it would be a promise that we will never
> change the underlying assumption.
>
>> This is particularly useful in combination with "vbox-unattended"
>> patch, that adds new OS types every now and then, but also for Oracle
>> VirtualBox itself.
>>
>> I have tested it together with VirtualBox GUI and with VBoxManage commands.
>> Plus tested OVF, Import / Export appliance.
>
> Klaus
>
> _______________________________________________
> vbox-dev mailing list
> vbox-dev at virtualbox.org
> https://www.virtualbox.org/mailman/listinfo/vbox-dev



-- 
-Alexey Eromenko "Technologov"