[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.

• https://github.com/Code-Hex/vz/pull/46
• https://github.com/Code-Hex/vz/pull/49
• https://github.com/Code-Hex/vz/pull/52
• https://github.com/Code-Hex/vz/pull/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." https://github.com/Code-Hex/vz/commit/37646e120f85b7fd99989e7e4b23cf068564b561

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.

[ghost]

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:

• https://github.com/Code-Hex/vz/issues/56
• https://github.com/Code-Hex/vz/issues/54
• https://github.com/Code-Hex/vz/issues/50
• https://github.com/Code-Hex/vz/issues/47

An issue I'd really like to see fixed is https://github.com/Code-Hex/vz/issues/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+

[gbraad]

but only macOS 13+

We can make this a requirement if necessary. The alternative would be to 'extract' the kernel and ramdisk. If not feasible, we might target 13 for podman machine.

[ghost]

With 12.6 being the current Mac version, it seems like using VZEFIVariableStore would exclude supporting quite a many users.

Would packing the ignition file into a .img with ext2 filesystem and using kernel parameters to handle using it be viable? There's examples of packing an ext2 .img in Go over at microsoft/hcsshim. This would avoid needing to extract and repack the kernel and ramdisk.

[ghost]

These seem worth keeping an eye on in relation to this issue, just linking to them as a matter of housekeeping.

• https://github.com/crc-org/vfkit/issues/19
• https://github.com/crc-org/vfkit/issues/14

[gbraad]

@protosam We will be converging more with Podman Machine, like we did with vfkit. This effort will be lead by @cfergeau, so if you have any particular needs around features/requirements, please discuss with him.