[Action] Considering an alternative upstream for continued improvements on vfkit

[gbraad]

The Upstream for vz has been closing issue and pull requests without constructive criticism and limiting conversations with reason: "too heated", before conversations the PR gets closed.

• start/pause/stop: Readd 'generateHandler' helper Code-Hex/vz#46
• Don't export objcutil.go API Code-Hex/vz#49
• Fix ASAN related issues Code-Hex/vz#52
• vsock: Dup() socket in newVirtioSocketConnection() Code-Hex/vz#53

While several of these might be related, the tone is what concerns us as a dependent project. We have considered to create our own fork for the moment to make sure continued improvements are made.

[gbraad]

Since the upstream developer stated:

"Do not send Pull Requests for major code changes. I am not motivated to review your code. Basically, I write the code." Code-Hex/vz@37646e1

this starts more to look like unequivocally “Open Source, not Open Contribution”.

I have created a fork at https://github.com/machine-drivers/vz to deal with continued development according to our requirements.

It can also take a long time to get a PR accepted. Many people are working out of branch as a result, which is problematic if anyone needs a vulnerability patched.

@gbraad my interests are mostly aligned with how CRC needs VZ to work. Do we have a list of issues that we can start getting logged in your fork?

[cfergeau]

my interests are mostly aligned with how CRC needs VZ to work. Do we have a list of issues that we can start getting logged in your fork?

I've started adding the fixes vfkit needs to https://github.com/cfergeau/vz/tree/edge
They correspond to:

• Code-Hex/vz segfaults when NewFileSerialPortAttachment returns an error Code-Hex/vz#56
• ConnectToPort() needs to Dup() its VirtioSocketConnection Code-Hex/vz#54
• Segmentation fault in some control methods on x86_64 Code-Hex/vz#50
• use after free reported by ASAN Code-Hex/vz#47

An issue I'd really like to see fixed is Code-Hex/vz#43 but I have almost 0 objc knowledge, not sure I'll tackle this one. Apart from that, I have a few basic test cases for macOS10/macOS11 support I need to readd and plug into github actions.

I'm still not 100% sure how well imports of newer Code-Hex/vz changes will work, we'll see :)

[gbraad]

Hi @protosam, the work @paulcacheux did for file sharing, and Samuel Ortiz and @egernst did for Kata-Containers (and the unofficial fork: https://github.com/kata-container/vz/), have been on my radar too. Some of this work took unnecessary effort. The upstream owner actively refused conversations*.

One of the targets is to have a virtualization framework driver that can work for the usecase of podman machine and crc. @bbaude and I would like to see if an kernel can be started from the image itself and if ignition could even be referenced.

Let's discuss more on what we can do

Not: * and in my case even blocked for questioning some of the actions. The existence of forks with fixes that aren't upstream are telling. I hope the maintainer reconsiders.

[cfergeau]

@bbaude and I would like to see if an kernel can be started from the image itself and if ignition could even be referenced.

Hopefully https://developer.apple.com/documentation/virtualization/vzefibootloader?language=objc and https://developer.apple.com/documentation/virtualization/vzefivariablestore?language=objc will allow this, but only macOS 13+