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

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

• 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+

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

• Add features needed by podman-machine vfkit#19
• Switch to Code-Hex/vz/v3 vfkit#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.