[vbox-dev] [PATCH] Fix for Guest "OS type" future-compatibility
al4321 at gmail.com
Fri May 8 13:38:29 UTC 2015
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:
>> 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.
> vbox-dev mailing list
> vbox-dev at virtualbox.org
-Alexey Eromenko "Technologov"
More information about the vbox-dev