Nested Virtualization of Windows Hyper-V on XCP-ng
@olivierlambert @AlexanderK I pasted my xl config file here: https://paste.vates.fr/?449c18ba665cd704#GzDDKa4fui6jqbvG7ssT5TpH7uj8uBVrg7zojpGqYmu7
@olivierlambert @AlexanderK One final thing, here is the Xen reference manual link for the xl config file parameters (I learned a lot reading it.) https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html The outstanding issue appears to be whether or not there is a corresponding setting configurable from the xe toolstack to turn on all of the required parameter/value pairs as implemented by my test configuration on the pure Xen hypervisor. If so, we should then be able to make nested virtualization of Hyper-V work on XCP-ng.
As long as we know exactly what's missing, we can fix it
It's still unclear what parameter is missing on XAPI vs libxl, waiting for more details from @XCP-ng-JustGreat
@AlexanderK can you share the VM record here please? (the one that's nested but doesn't work with Docker). A simple output of
xe vm-param-list uuid=<VM UUID>will do it.
Just checked the
xlconfig posted by @XCP-ng-JustGreat, and I can already answer for some parameters, but I'd like to check if they are already used or not (eg
platform:viridiancan be set to
trueif it's not already the case)
Can you try with a Windows 10 template from the start?
@olivierlambert ok will do it.
@alexanderk @olivierlambert Did a bit more testing by removing one of the four nested-virtualization parameters at a time in the windows.cfg file on pure vanilla Xen hypervisor. Omitting the cpuid setting is the one where the Hyper-V machine bus provider driver fails to load in the guest and, basically, nested Hyper-V breaks. From what I can tell, entering that key/value pair under the platform parameter in the XCP-ng VM definition has no effect after starting from a "stock" Windows 10 VM template.
Since the platform parameter would seem to be the logical place for that value, it looks like a developer needs to look at the code to see whether or not the mechanism for passing cpuid already exists and is not documented, or instead it needs to be implemented. Thanks again to @olivierlambert and the team at Vates for your continued innovation and enhancement of this remarkably useful software!
Okay so it's the only thing we don't have is
cpuidand that make the diff. I'll ask around to see how we could have this in XCP-ng/XAPI (
Thanks for your precious feedback @XCP-ng-JustGreat !
here it is from the start
So after discussing with my favorite Xen expert, here what could be do to get a similar result on the cpuid:
- Get the pool CPU ID:
xe pool-param-get uuid=<pool_uuid> param-name=cpu_info param-key=features_hvm. Should be something like
- To compute the value you want to pass on the VM, you need to clear the hypervisor bit. So the previous string will become now
- See this value for your VM, which will override the default computed featureset for this specific VM:
xe vm-param-set uuid=<VM UUID> platform:featureset=1fcbfbff-77fa3203-2d93fbff-00000523-0000000f-009c07ab-00000000-00000000-00101000-9c000400-00000000-00000000
- Start the VM, and report.
Reference for bit positions in the bitmap: https://github.com/xen-project/xen/blob/master/xen/include/public/arch-x86/cpufeatureset.h
The hypervisor bit is the top one, so you need to apply (val & 0x7fffffff) on it (it might be different in your example).
Note: we do NOT understand why doing this will solve the issue, but at least let's try first.
- Get the pool CPU ID:
i am trying to calculate for my vm...
the cpu id on pool is
i must change the second "team" of 8 digits? I suppose that it is something in hex.
You wrote that the hypervisor bit is the top one. What do you mean?
I should add on 80b82221 the value 0x7fffffff?
@olivierlambert @AlexanderK Wow! Changing the platform:featureset=value as prescribed does indeed enable support for nested Hyper-V on XCP-ng!! This is huge!!! I will now need to begin testing some of the actual Hyper-V-dependent functions in the nested Windows guest. The msinfo32.exe command displays no apparent knowledge that the guest OS is running on a hypervisor. It simply indicates that all four prerequisites for running Hyper-V are enabled. It would appear that this platform modification effectively tells the XCP-ng VM to lie to the nested guest OS: "No, you are not running on a hypervisor." BTW, I still have all of the latest pre-release patches installed that we tested a couple of weeks ago for @stormi . Therefore, the tested Windows VM is also booting with secure boot support by @beshleman along with this additional major breakthrough. Because of nested virtualization's complexity, there will no doubt be additional hurdles we need to jump over to make the desired guest functions work, but we have made tremendous progress in a rather short span of time. Congratulations everybody! If it's possible, we may want to change the title of the post to Nested Virtualization of Windows Hyper-V on XCP-ng as that will provide an easier way for it to be found by others. I can't really adequately express my gratitude to all of you for the amazing level of support! (Pinging some others who have fought with this issue in the past and will no doubt appreciate hearing of its progress: @Noiden @Haribo112 )
@xcp-ng-justgreat Title changed.
Can you help me with the AND and what exactly have you done? Give me an example to understand.
have tried something and issue on device manager is fixed but....
@alexanderk I think you need to run the PowerShell command to get second-level (L2) nested virtualization within Hyper-V. You are now effectively running yet another VM inside of an existing VM (like Russian dolls-nested) so you need to expose the processor hardware virtualization from L1 to L2. See here: https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/nested-virtualization