GuestOS=WinhyperV

[FredericBlair]

We have found 2 tweaks that can help us boot and operate WinHyperV machines in VMWare.

Solution #1

• tweak the VMX, adding these 4 lines:

mce.enable = TRUE

hypervisor.cpuid.v0 = FALSE
featMask.vm.hv.capable = “Min:1″
vhv.enable = TRUE

Solution 2:

Change the Guestos value to Winhyperv"

Our problem is that, whenever we change a machine from Template to VM or from VM to Template, the value within the .vmx (or .vmtx) changes automatically to Guestos=Other again.

This makes us unable to deploy many VMs from a template and we need to edit each of the VMX files before being able to boot the machines.

Is there any way of keeping the value of the GuestOS to WinhyperV.

PS: We also made a test in 5.5 using the newer 'windowsHyperVGuest' as GuestOS and it still does the same thing.

Whenever we deploy a VM from a template, the GuestOS value is resetted.

[lamw]

Very odd that the guestOS is not kept when converted to a template ... I've also confirmed the same behavior running on the latest 5.5 build. I'll file a bug on this

[FredericBlair]

Thank you very much for this.

I still need to finish my tests, but I was told by a collegue that the same behavior happens when we clone and/or vmotion(shutdown) machines from one host to another.

I will also test from same host to same host as well to try and include all the information in the actual bug report.

[FredericBlair]

I confirm.

I have a shutdown machine with the correct GuestOS entered.

If I clone this machine on the same host, the value of the GuestOS is resetted to "other" on the cloned machine.

I only have one host in 5.5 to make my tests, so I cannot test the vmotion but when I had tested it in 5.1, I had the same issue with vmotion

Hope this helps to make a very complete bug report.

Have a nice holiday

PS: Is there a way I can have access to this bug report so I can follow it and see if there is a fix and what version it will be adressed?

[lamw]

Thanks for all the information. I've just filed the bug, but unfortunately the bug tracking system is internal to VMware. Given Nested Virtualization is not officially supported, it'll be best effort on when engineering will be able to get to this. If it gets resolved, I'll post back details. Perhaps Jim may also chime in as he's one of our Nested Virtualization Gurus

[admin]

This is probably fallout from Hyper-V being an unsupported guestOS type.  Normally, I would encourage people to use the correct guestOS type, but since that doesn't work for you, I would set the guestOS to match the management OS.  Then, I believe all you need from your initial list are:

vhv.enable = TRUE

hypervisor.cpuid.v0 = FALSE

[TommyFreddy]

This may help ...

Hyper-V Integration Services Requires a Newer Version of Windows Vista

Take care!

[sideshowtob]

I also found if you used guestOS = "winhyperv" it causes the 5.5 web client to crash with "An internal error has occurred - Error #1009" when you tired to edit the VM settings.

Switching back to guestOS = "windows8srv-64" and then using the 4 lines in the OP's post resolves this.

[FredericBlair · Accepted solution]

So the combo that worked was the 2 lines from jmattson and the sideshowtob guestos

vhv.enable = TRUE

hypervisor.cpuid.v0 = FALSE

guestOS = "windows8srv-64"

Using this, I was able to clone, migrate and do everything without having my .vmx file altered!
Thank you very much guys for this, I really appreciate it

[sideshowtob]

Glad I (we) could help.