[Feature]: Support Podman Machine provider selection using containers.conf

[arixmkii]

Feature request description

There is already [machine] section in the containers.conf file and ReadCustomConfig method to read it. Extend this section to support optional provider record, with empty value representing default behavior (as it is now). Repace func GetSystemDefaultProvider() machine.Provider with func GetSystemProvider(name string) machine.Provider, where provider name must be passed by the caller and updates all the paths (some of them are already fetching the config, but others will need updates.

This would be needed for support of WLS2 and QEMU on Windows, AppleHV and QEMU on Apple Silicon Macs.

Suggest potential solution

in the scope of #13006 the implementation would look like

func GetSystemProvider(name string) machine.Provider {
	provider := name
	providerOverride, ok := os.LookupEnv("CONTAINERS_MACHINE_PROVIDER")
	if ok {
		provider = providerOverride
	}
	provider = strings.ToUpper(strings.TrimSpace(provider))
	switch provider {
	case "WSL":
		return wsl.GetWSLProvider()
	case "QEMU":
		logrus.Info("QEMU provider is a work in progress https://github.com/containers/podman/issues/13006. Will use default provider.")
		return wsl.GetWSLProvider()
		// return qemu.GetVirtualizationProvider()
	default:
		if (len(provider) > 0) {
			logrus.Warnf("Unuspported provider specified %q. Will use default provider.", provider)
		}
		return wsl.GetWSLProvider()
	}
}

This additionally allows to override the setting using environment variables for testing purposes. It also logs warning, when unexpected value is encountered.

Have you considered any alternatives?

Using it via command line arguments or environment variables only (no config), which would allow more flexibility. But from my experiments it has numerous downsides:

• running multiple machines is not trivial even for the same provider (at least one needs to remember about shared network port space);
• running multiple machines from different providers is even more extreme as now it is not supported to fetch info from all supported vendors and then aggregate them, this tasks looks challenging on its own and probably doesn't justify the effort;
• command line and/or environment variable usage should be supported by third party tools (like Podman Desktop), when they operate with the Podman, but the config approach isolates it to Podman itself.

Additional context

This would encourage that normal usage scenario of a single machine provider per user session. But this matches the current behavior, where only a single provider per platform is supported.

I expected that this to be solved with implementation of AppleHV, but it looks like the implementation is lagging behind because of the lack of resources.

If there is another proposed implementation, which accomplishes the same result, then it is fine to withdraw this proposal and replace with what was already planned (I didn't manage to find it).

[andrewcrook]

This would be really useful I would also suggest the following

This would be needed for support of WLS2 and QEMU on Windows, AppleHV and QEMU on Apple Silicon Macs.

• Providers for Parallels, VMware Fusion and Virtualbox etc would be useful docker-machine or vagrant esq
• Regarding QEMU it would be useful to be able to use its features to emulate different architectures especially Intel/AMD and ARM64 vice versa just like Docker xbuild.
• It would be nice to be able to select different VM images to run Podman within on Windows and Mac obviously there would need to be a guide for the requirements to interface with Podman but this would allow people to select their flavour of Linux etc.

Update

oh yes AppleHV is a framework not a complete VM solution it’s a framework so you would still need a full implementation of it such as Parallels. I suppose you could make one in swift but that’s probably a new project.

[arixmkii]

@andrewcrook Thank you for your input! I suggest you to create a discussion in the dedicated section if there is no one already for these topics. This is because the issue reported here is only about very specific internal API extension and probably will be closed shortly as implemented and your suggestions will get lost.

[rhatdan]

@baude @ashley-cui PTAL

[baude]

I think this is a good idea ... has the work been done in containers common already ?

[arixmkii]

Change is merged into commons main branch containers/common@ead2e7d, but it was after the commons release has been cut for Podman release. I will prepare Podman part after commons will be updated.

[baude]

@rhatdan what say you? do you want to cut a common release or just vendor in a commit for now ?

[arixmkii]

I also hope to finalize changes in this PR containers/common#1131 and get it into next release of commons. If just a bump is possible, then it is probably a more suitable option right now.

[rhatdan]

Sure I would like to get this in.

[arixmkii]

LookPath fix was merged into main in Common repo. Now need to wait for code pull or common release + code pull into Podman repo.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@arixmkii what is happening with this? Common has been updated, but it looks like your PR has stalled.

[arixmkii]

@rhatdan I will re-implement it to incorporate recent changes implemented by @baude for Hyper-V provider and multiple provider support. It is under my radar and I'm finally back to finding at least some capacity for OSS activities. I can move PR to draft if this is necessary.