Ability to test an image localy

[slemeur]

Epic domain

As a user of the bootc extension, I would like to make turnaround and edits while I'm creating a bootable image easy to test.

The goal of this epic, would be to explore the different possibilities that could be used to enable testing a bootable image locally, by running it as a VM. (While we will probably not be able to encompass all the different environments, we should aime to provide a minimal support for this)

Additional context

In the past, we were having a "Launch VM" button, which was useful to better showcase the value of bootc images.

(added by @cdrage) Tasks to be completed for "full" feature:

• [x] Initial POC https://github.com/containers/podman-desktop-extension-bootc/issues/813
• [ ] Persistent virtual machines https://github.com/containers/podman-desktop-extension-bootc/issues/876
• [ ] Windows support https://github.com/containers/podman-desktop-extension-bootc/issues/879
• [ ] Linux support https://github.com/containers/podman-desktop-extension-bootc/issues/878

[cdrage]

I agree and I think this should be done.

We have 2 routes, we can either:

Option 1. native qemu commmands

We can use native qemu commands similar to the hackathon, and output it to a console socket and pick it up with a socket. This was done before for the demo.

Advantages:

• Fast, runs the .qcow2 / .raw natively after building it
• Was done before / POC / works
• Stable-ish than before, requires brew install of qemu / qemu install on Fedora 40
• Works for arm64 and amd64

Disadvantages:

• Only one I can think of is must provide installation doc how to install qemu, but we have to do the same for podman-bootc binary too.

Option 2. podman-bootc CLI

We could also use https://github.com/containers/podman-bootc however, this is still pretty early.

Advantages:

• Single binary
• Same ecosystem / provide upstream support

Disadvantages:

• Must provide image rather than qcow2 / raw / etc.
• Slow, podman-bootc run converts the image, uses bootc-install and then runs it, compared to qemu running it immediately.
• Needs builder support perhaps in order to avoid the above rebuilding? https://github.com/containers/podman-bootc/issues/4
• No cross-arch support vs native qemu: https://github.com/containers/podman-bootc/issues/27
• Have to install binary AND qemu (uses qemu under the hood to deploy containers)

IMHO we should go the qemu route as we already had that working with the POC and then wait until podman-bootc features are implemented upstream?

[cdrage]

https://github.com/user-attachments/assets/ef717940-859c-4b26-9a60-62e94623b563

I created a POC that uses qemu since it integrates well with our library.

I discovered yesterday that qemu has websocket support out of luck, and our terminal library (xterm.js) supports websockets out of pure coincidence.

We can launch the VM and access the terminal all within the podman extension.

[cdrage]

@slemeur @deboer-tim I have updated this epic to include four issues to cover the feature (initial implementation, other OS support, etc.) as per Slack discussions

[deboer-tim]

Moved the first issue / experimental Mac support to 1.5 milestone, and removing 1.5 milestone from this epic as we don't currently have a target.