Add `podman machine bootc`

[cgwalters]

Feature request description

In the https://github.com/containers/bootc project we are focusing on bootable containers. We reuse podman build (or other container build tools) for this.

We want to have a fast and efficient workflow of booting a container image directly as a virtual machine.

Today, podman machine has cross-platform virt code that works...and only needs a small generalization to support a flow like this:

podman build localhost/testos
podman machine bootc run localhost/testos

By default, this VM would be "lifecycle bound" to the controlling shell invocation; this removes a lot of CLI/infrastructure needs around having external daemons with APIs, start|stop verbs, support for reconfiguration etc.

Behind the scenes, podman machine bootc run would actually run bootc install to-disk to synthesize a disk image or would leverage https://github.com/osbuild/bootc-image-builder

Suggest potential solution

Add code to do the above

Have you considered any alternatives?

Documenting how to use external virt tools is the other big solution, which we will also do...but we can much more easily streamline things by reusing existing podman and podman machine code.

Additional context

No response

[cgwalters]

I have some WIP in https://github.com/cgwalters/podman/commits/machine-exec/

[cgwalters]

OK looking into this...I think this is going to have a fair bit of conflict/overlap with what @baude wants to do for cleaning up the virt stack.

A basic thing this issue wants to do is have a more generic "run a VM" tool that notably:

• Does not use Ignition by default (defaults to injecting a ssh key via systemd creds), but in general we also can assume the user may have also done their own configuration; we'll also want to support cloud-init probably.
• Doesn't expose the podman socket
• Should probably support multiple

And this is going to really want a setup that looks like this:

pkg/virt/ (exposes generic primitives for basic cross-platform virt)
pkg/machine/ (the rest of the stuff that exists today, continuing to use ignition and FCOS)

But having a more generic setup also helps lead towards helping with #21251

@baude thoughts? Happy to do a realtime sync on this too.

[cgwalters]

I'm still thinking about this and looking at things. I took some time to do a deeper dive into https://lima-vm.io/ too.

Positives:

• Lima is actively maintained and used both standalone, but also as a "backend" for projects very similar to podman machine, e.g. https://github.com/runfinch/finch/
• It's in Go so we could vendor it the same way those other projects do
• It is explicitly general, supporting multiple running VMs etc. which would clearly be useful here because it's definitely needed to have two VMs - the podman machine VM and the bootc-VM-under-test at least

Negatives:

• It generally assumes cloud-init (but this isn't fatal, we could likely easily add support for SMBIOS-type stuff bridging to https://systemd.io/CREDENTIALS etc)
• It really wants to add containerd into your guest unless you try hard to disable that
• No one has tried to add it as a package except for NixOS on Linux

Neutrals:

• Its support for virtualization.framework is marked experimental, but that's fine, we could help with that
• It uses 9p on Linux - same as we do here - which really wants to be using virtiofsd (xref this comment)

Uncertainties:

• They mention Windows in passing, but it's not in their docs. I honestly don't really understand the Windows setup we have here or what they may do, and how that intersects with what podman machine does today. Does it help us in any way to try to keep podman-machine as is on Windows but replace the Linux and Mac stuff with Lima? Seems like it may get messy. But maybe it already is messy.
• Does it help or hurt us to try to drive e.g. libkrun support into lima if we choose that path?

[germag]

I'm doing some experiments from the user POV [0]. It currently uses qemu, it supports cloudinit and smbios to inject credentials (but we can also create users and set users passwords).

The idea is to be part of podman, as podman bootcor podman machine bootc, it's not the complete idea just a mockup to see what could and could not work, from the user workflow POV

[0] https://gitlab.com/germag/osc/

[cgwalters]

For reference the latest code here is https://gitlab.com/bootc-org/podman-bootc-cli

[germag]

@cgwalters there is a typo in the url an extra "l" at the end

[cgwalters]

Current trending thought is now away from doing this here, so closing.

(But, we do need to dedup virt code in the medium term...at least on Linux I think podman-machine should consider using libvirt nowadays, which would have made #22920 trivial; see bootc-dev/podman-bootc#36 )