Hyper-V VMM based on Microsoft OpenVMM on Proxmox

[bitranox]

we have fully integrated openvmm into proxmox - as You can see here, its fully Hyper-V, no qemu, also works on linux with hyper-v.
it runs in userspace and is a type 2 hypervisor.
We support MANA and Mellanox network adapters and much more, to make it painless to lift (or downgrade?) machines from azure.
We also plan to support vmware NIC and storage adapters out of the box, to make it super easy to transfer machines from vmware without using/installing any special/additional drivers.
No virtio drivers are needed at all. it supports vbs, multi-q NIC and storage controllers

the only thing holding us back to release is, that HVCI needs a KVM Kernel Patch, either in the proxmox kernel version or the underlying linux kernel.
For machines without hvci it runs fine on unpatched proxmox kernels.
It still needs a little love and polishing, but everything works, like HA, snapshots, live-backup, 4K VNC, dynamic VRAM allocation, TPM and so much more.
interested parties are welcome to contact me.

 

[jeyhun]

I checked the Proxmox kernel configuration used for the 7.0.6 build:

pve-kernel-build/pve-kernel/config-7.0.6-amd64.org
CONFIG_HYPERV=y
CONFIG_HYPERVISOR_GUEST=y
CONFIG_MSHV_ROOT=m
# CONFIG_HYPERV_VTL_MODE is not set
So basic Hyper-V support is already enabled in the PVE kernel. CONFIG_MSHV_ROOT=m is also present; this is the Linux support for running as a Hyper-V root partition, while CONFIG_HYPERV_VTL_MODE is not enabled.

 

[bitranox]

Jey, thanks for reaching out - but maybe You got something wrong here. There is no technical problem, we have created the KVM Patch, E2E Testing for HVCI - so everything is working fine. But in order to release it, that patch needs to go into the PVE Version of KVM or into Linux Mainline Kernel - because no bigger company in the world would like to use an obscure patched Kernel. Though the problem is smaller then it looks - because using HVCI (a hypervisor on top of a hypervisor) is performance wise not the best setup in the world.
This fork of the microsoft hypervisor is also running fine without that patch, it just will just not support HVCI - so we might release it without that patch, and if it gains traction either Proxmox or Linux will eventually accept that patch - probably with the support of microsoft. I reached out to John Starks at microsoft to help - but they are tremendously busy, so that will take time.

Your configuration hints are not the point. openvmm is a type2 hypervisor, and the windows guest HVCI is routing synthetic interrupts to level 0 - and those need to be reflected to level 1 where openvmm sits - so You need a patch for that, no way around that.

 

[bitranox]

But thank You for the hints, we will re-check that again, since our test machines are on kernel 7.0.2

 

[jeyhun]

Got it, thanks for clarifying — I misunderstood the blocker.

Since the patch and E2E HVCI testing are already working, why not release an experimental pre-patched PVE ISO + GitHub repo with the KVM-HVCI patch and build instructions?

 

[bitranox]

still needs some polishing and installer - but we will release eventually ...

 

[bitranox]

and You dont even need a pre-patched iso - only kvm needs patching

 

[robertlukan]

I think it would be worth putting this into public even without HVCI support for now. Not everyone needs it(for now).

I agree, not many people would be willing to run custom kernel, so support from MS is needed so they can push those patches into upstream kernel.

It would be interesting to see some performance comparisons.

A very good use case would be moving VMs from MS cloud without reinstalling drivers(at least not storage as that is the most painful part).

BTW, great job!

 

[bitranox]

I just got the message from John Starks (the head of the openvmm project) that the patch was discussed on the linux plumbers conference - so there are chances ...

 

[bitranox]

A very good use case would be moving VMs from MS cloud without reinstalling drivers(at least not storage as that is the most painful part).

my friend, I integrated MANA and Mellanox NIC, exactly having that in mind.

 

[bitranox]

It would be interesting to see some performance comparisons.

performance is absolutely the same. with some differences, because we support multi-queueing on NICs and Storage Adapters. I guess the biggest advantage is getting rid of the virtio drivers, to use the native microsoft functions for ballooning etc. - also the network stack seems to be more mature then the virtio siblings.