@stgraber, I’m gonna need some help in the agent selection logic. For ISO mounts, the agent is selected in an architecture-dependent way, which is not used for 9p mounts. Could you please have a look?

@stgraber, I’m gonna need some help in the agent selection logic. For ISO mounts, the agent is selected in an architecture-dependent way, which is not used for 9p mounts. Could you please have a look?

Yeah, the reason for that is pretty simple. In the 9p case, we can just share a folder on the host containing all the agent builds (/opt/incus/agent/ in Zabbly packages). That's cheap as it's the same data available for everyone through QEMU's built-in sharing.

For ISOs, now we need to actually generate a .iso for every instance using that. We don't want to waste space as each agent build can be around 20MB, so instead we expect the ISO to only contain the binary the instance needs. We should know the architecture of the instance already (d.architecture) and we can tell the OS through image.os.

Yeah, the reason for that is pretty simple. In the 9p case, we can just share a folder on the host containing all the agent builds (/opt/incus/agent/ in Zabbly packages). That's cheap as it's the same data available for everyone through QEMU's built-in sharing.

Oh I actually missed that incus-agent is a script to call the right agent. In my tests, I just injected the macOS agent binary. I’ll look into it.

Oooh I actually got lost in the agent dance and overlooked that the config and agent shares are actually different!
So there’s a little more work to do, and an additional splitting for the incus-agent script between a Linux-specific one and a Darwin-specific one.
I placed myself in the very convenient case where /Volumes/config/incus-agent is the actual agent binary (and it works fine).

Ok that should be good now, both config and config+agent setups should be supported. I haven’t taken any care to handle CDROM installation, because macOS supports 9p, so not really worth the time I think.