Code: Select all
/*
* Don't report vendor as 'Microsoft Hv'[1] by default, see @bugref{7270#c152}.
* [1]: ebx=0x7263694d ('rciM') ecx=0x666f736f ('foso') edx=0x76482074 ('vH t')
*/
Code: Select all
/*
* Don't report vendor as 'Microsoft Hv'[1] by default, see @bugref{7270#c152}.
* [1]: ebx=0x7263694d ('rciM') ecx=0x666f736f ('foso') edx=0x76482074 ('vH t')
*/
That sounds like you're misreading the VirtualBox source code:adamxx wrote:HyperV is not reported to guest by default
The VirtualBox source code references the internal bug tracker, which is not accessible to us mere VirtualBox users.adamxx wrote:I cannot find the @bugref{7270#c152}, anyone has the link?
Let me add one thing to connect that to the issue at hand:scottgus1 wrote:'Paravirtualization Interface' is a comm channel for virtualization-aware OS's to talk to whatever hypervisor is running them, so they can run more efficiently. This comm channel needs a 'language' to use, defined only by the type of OS running in the VM. When running Windows VMs Virtualbox uses Hyper-V 'language' to talk to the Guest OS. When running Linux VMs, Virtualbox uses KVM 'language' to talk to the Guest OS. This is regardless of what type of host OS Virtualbox is running under.
The "setextradata" does not work. Below commands works:fth0 wrote:That sounds like you're misreading the VirtualBox source code:adamxx wrote:HyperV is not reported to guest by default
By default, VirtualBox sets the Hyper-V Vendor ID to "VBoxVBoxVBox", puts that into the CPUID hypervisor leaves and provides the Hyper-V paravirtualization interface to the guest OS. If for any reason you need to pretend that the Hyper-V paravirtualization interface is provided by Windows instead of VirtualBox, you can use VBoxManage setextradata "VM Name" "VBoxInternal/GIM/HyperV/VendorID" "Microsoft Hv".
My use case:fth0 wrote:Let me add one thing to connect that to the issue at hand:scottgus1 wrote:'Paravirtualization Interface' is a comm channel for virtualization-aware OS's to talk to whatever hypervisor is running them, so they can run more efficiently. This comm channel needs a 'language' to use, defined only by the type of OS running in the VM. When running Windows VMs Virtualbox uses Hyper-V 'language' to talk to the Guest OS. When running Linux VMs, Virtualbox uses KVM 'language' to talk to the Guest OS. This is regardless of what type of host OS Virtualbox is running under.
On a communication channel, both ends better speak the same language. So what VirtualBox does, is to pretend to be a Hyper-V hypervisor in the case of a Windows guest and a KVM hypervisor in the case of a Linux guest, by providing some paravirtualization interfaces automatically supported by the guest OS.
I'll make an educated guess here what could be part of the reasoning in the internal bug ticket: If VirtualBox would not only provide expected paravirtualization interfaces, but also fake the Hyper-V Vendor ID, a Windows guest could expect all paravirtualization interfaces and their functionality that a real Hyper-V hypervisor provides.
adamxx wrote:Is there any known issue?
From what I gather from fth0's thoughts above:fth0 wrote:I'll make an educated guess here what could be part of the reasoning in the internal bug ticket: If VirtualBox would not only provide expected paravirtualization interfaces, but also fake the Hyper-V Vendor ID, a Windows guest could expect all paravirtualization interfaces and their functionality that a real Hyper-V hypervisor provides.
You're right, and I didn't try it myself beforehand. While the command is syntactically correct and works (which can be verified in a VBox.log file), VirtualBox (6.1.40 in my case) apparently does not accept the resulting VM configuration as valid because of the missing Hyper-V debug interface that you found yourself. Kudos for that!adamxx wrote:The "setextradata" does not work.
Thanks, understood. So there should no known issue if I use '--paravirtdebug "enabled=1"' to expose "Microsoft Hv" to guest, right?klaus wrote:From our investigation Microsoft distinguishes between a 'Microsoft compatible' and a 'is Microsoft' hypervisor. We simply decided to play safe and not make a false claim.
Talking to myself:fth0 wrote:When VirtualBox uses the underlying Windows hypervisor (Hyper-V, NEM), does it pass through the paravirtualization interface to the guest OS or does it still use its own implementation? If it's the latter, wouldn't it make more sense to provide the KVM paravirtualization interface instead, as if VirtualBox runs in VT-x mode? Why do you want to provide the Hyper-V paravirtualization interface?