Note this “disclaimer” in the guide:<p>> In recent years, development efforts in the OpenVMM project have primarily focused on OpenHCL (AKA: OpenVMM as a paravisor).<p>> As a result, not a lot of "polish" has gone into making the experience of running OpenVMM in traditional host contexts particularly "pleasant".<p>> This lack of polish manifests in several ways, including but not limited to: […]<p>> • <i>No API or feature-set stability guarantees whatsoever.</i><p><a href="https://github.com/microsoft/openvmm/blob/main/Guide/src/user_guide/openvmm.md#disclaimer">https://github.com/microsoft/openvmm/blob/main/Guide/src/use...</a>
Thank God this VMM is written in Rust, otherwise I would be very skeptical. I don't care about features or purpose or technical advantages, give me Rust or give me death.
Cargo.lock has 8750 lines. Is that normal for something like this?<p>For comparison, QEMU basically just needs glibc, glib and zlib for basic functionality.
How does this relate/compare to CloudHypervisor, another Rust based VMM that has been around for couple of years<p><a href="https://github.com/cloud-hypervisor/cloud-hypervisor">https://github.com/cloud-hypervisor/cloud-hypervisor</a>
Slides from Linux Plumbers talk about OpenHCL: <a href="https://lpc.events/event/18/contributions/1956/attachments/1642/3391/linux%20plumbers%20bof.pdf" rel="nofollow">https://lpc.events/event/18/contributions/1956/attachments/1...</a>
Half the user guide is empty.<p>I want to understand what communication channel(s) it has from guest to host. It's not clear from the cut-and-paste support described in the VNC section of the manual, how this works and what other functionality might be supported.
Rust was something i thought was a cute little language years ago, much like i thought python was. I didn't pay attention for like 2 years and it feels likes it's everywhere and everything.<p>Time to learn.