RFE: Native Mac/Windows support

[TomSweeneyRedHat]

It would be ideal to have native mac and windows support to further the adoption of podman in the community. Users do not want to have a Linux VM just to use podman on these platforms. Furthermore, users won't read the entire README to find out that you really only support Linux and not Mac/Windows without a Linux VM.

First posted against podman.io https://github.com/containers/podman.io/issues/315 by @peters95

[mheon]

OS X is technically impossible at present. Kernel features we need are just not there - you can't make anything approximating a container. We're at the mercy of Apple on adding them and for now they seem quite content to not do that.

A native Windows port is possible but would require a massive rearchitecture to run Libpod on non-Unix platforms. For now my temptation is to say that WSL2 has mostly eliminated the need for such efforts on Windows.

On Mon, Nov 23, 2020, 09:57 Tom Sweeney notifications@github.com wrote:

It would be ideal to have native mac and windows support to further the adoption of podman in the community. Users do not want to have a Linux VM just to use podman on these platforms. Furthermore, users won't read the entire README to find out that you really only support Linux and not Mac/Windows without a Linux VM.

First posted against podman.io containers/podman.io#315 https://github.com/containers/podman.io/issues/315 by @peters95 https://github.com/peters95

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/containers/podman/issues/8452, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3AOCBUXBB3MPISCYBIID3SRJZ6FANCNFSM4T7S7OPA .

[rhatdan]

Containers==Linux, Linux==containers. When users want to run containers they are almost always talking about Linux containers. In order to run a Linux Container, you need a Linux Kernel. Thus you need a VM (Or a hidden VM line WSL2).

In my opinion until the fact that Container are Linux changes, running Native, is just people not understanding containers or being fooled by Docker.

Could we or the community make it easier to get Podman on a Mac or Windows box? YES. Could we make it easier to get access to a VM running Podman in server mode? YES (This should be a high priority) Should we make Podman run windows containers? NO, Most users don't have this need. If community wants to add this feature, then we should work with them, but I don't see this as a core requirement.

[afbjorklund]

Some users are looking for a slightly smaller version of CodeReady Containers, but with Podman instead of OpenShift... There was some talk about adding podman-remote support to the default CRC install, but it is currently broken I think.

• https://github.com/code-ready/crc/issues/1097
• https://github.com/code-ready/crc/issues/1611

This would be similar to using Docker Machine or Podman Machine, instead of Minikube (which includes Kubernetes) If you want to use minikube to set up your VM (with CRI-O container runtime), you can access the podman service on it:

$ minikube start --container-runtime=cri-o
$ eval $(minikube podman-env)

---

These are not really "native" installs of podman though. They even bring more baggage with the VM, an orchestrator...

But they are integrated with the "native" hypervisor on each, and they exist as products for Linux, macOS and Windows:

• Minishift

• Minikube

[afbjorklund]

It would be ideal to have native mac and windows support to further the adoption of podman in the community. Users do not want to have a Linux VM just to use podman on these platforms. Furthermore, users won't read the entire README to find out that you really only support Linux and not Mac/Windows without a Linux VM.

@TomSweeneyRedHat : This should probably be a separate project (from the main podman "engine"), that would bundle the current podman (for linux) and podman-remote (host) binaries with the VM image and runner and the VM control commands. And the Mac version and the Win version are probably also two completely separate projects, when it comes to the implementation...

Previously we had the boot2podman.iso image with Virtualbox or QEMU runner and the podman-machine controller. But user would rather have something that was integrated and supported, so that you had a supported OS (Linux distribution) and integrated support for talking to the hypervisor (hypervisor.framework/hyper-v) directly instead of using a separate product to do it.

Currently I am using vagrant and bash for experimentation, since it is easier than the custom OS and the custom Go binary...

Another approach would be to supply a Fedora platform for Mac and Win computers, like https://multipass.run/ does for Ubuntu.

[catap]

@afbjorklund docker for mac use the same trick: it started a linux via OS' virtulization library and runs all containers inside.

[afbjorklund]

docker for mac use the same trick: it started a linux via OS' virtulization library and runs all containers inside.

Yes, this is what is sometimes requested but it is not offered by "podman engine", but an imaginary "podman desktop".

Most likely, "podman for mac" and "podman for windows" are separate projects from this "podman" (for linux) ? And like it says above, maybe running the regular podman from WSL2 is good enough for Windows 10 support

Currently we have "podman remote", which is only the client - and then you have to supply the Linux server yourself.

[afbjorklund]

@TomSweeneyRedHat : you should clarify this issue, if you want a way to do Linux syscalls on Windows and Macintosh operating systems like with (WSL1) Windows Subsystem for Linux or the (BSD) Linuxulator projects. Or if you you just want a slick packaging of Podman + Hypervisor + Image, the way that Docker Desktop is doing it with their remote client and their bundled LinuxKit VM...

Currently you also get all the fun of doing one version for x86, and one version for ARM to support the new "M1" CPU Macs.

[github-actions[bot]]

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

[rhatdan]

@baude is going to start a small project to investigate how we can do better with this, at least on MACs.

[sify21]

Hi, there are windows container images. I don't know how it's implemented, maybe there is a group of microsoft engineers supporting this. docker desktop on windows can run them with hyperv when you "switch to windows containers". It uses vms when you "switch to linux containers".

Containers==Linux, Linux==containers. When users want to run containers they are almost always talking about Linux containers. In order to run a Linux Container, you need a Linux Kernel. Thus you need a VM (Or a hidden VM line WSL2).

In my opinion until the fact that Container are Linux changes, running Native, is just people not understanding containers or being fooled by Docker.

Could we or the community make it easier to get Podman on a Mac or Windows box? YES. Could we make it easier to get access to a VM running Podman in server mode? YES (This should be a high priority) Should we make Podman run windows containers? NO, Most users don't have this need. If community wants to add this feature, then we should work with them, but I don't see this as a core requirement.

[afbjorklund]

Should we make Podman run windows containers? NO, Most users don't have this need.

docker desktop on windows can run them with hyperv

Note that you can run both real containers (process-isolated) and virtual machine containers (hyperv-isolated): https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container

The same is true for Linux containers too, by using something like Kata containers* or runV or similar (KVM). This uses one VM per container (or per pod), traditionally DD used one shared VM for running all containers in.

* https://github.com/kata-containers/documentation/blob/master/design/architecture.md

Theoretically there could also be Mac containers, by using something like the BSD jails.

[afbjorklund]

There is a talk at FOSDEM, about running hypervisor-isolated containers (i.e. VMs) also on macOS:

https://fosdem.org/2021/schedule/event/containers_darwin_containerd/

But I don't know if anyone is working on running darwin containers on darwin, it sounds a bit niche ?

It does have chroot 😛

Hmm, apparently newer versions (10.10) also has something similar to namespaces...

https://www.karltarvas.com/2020/10/25/macos-app-sandboxing-via-sandbox-exec.html

[imperialguy]

@baude is going to start a small project to investigate how we can do better with this, at least on MACs.

Is there a link to this project?

[rhatdan]

Not yet, we start after BugFix/Stabilization of Podman 3.0. Sometime next month.

[github-actions[bot]]

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

[dominic-p]

Just to throw my 2 cents in, I originally hoped that WSL2 would be the solution to this on Windows, but, unfortunately, the performance is unusably slow. This is a known issue, but it's a hard problem and I don't see a solution coming any time soon. If you want to play around with podman on Windows, sure WSL2 works fine. But, if you want to use it for development, it's not really a solution, in my opinion.

For true Windows support there are a few options I see:

1. Investigate how to improve WSL2 performance. Outside of /mnt, the performance shouldn't be that bad, so maybe there are some optimizations that can be done. My experience may also be atypical here. I wasn't able to find much on other people running podman on WSL2 beyond just proof of concept.
2. Develop an easy to use Podman + Hyper V package for Windows that auto-binds working directories, etc. that has decent performance.
3. Figure out how to do native process-isolation type containers on Windows. I understand from the link above that it does exist, but I don't know if the underlying mechanism supports running Linux containers on Windows. For that, I'm pretty sure you still need some kind of VM.

[afbjorklund]

To be clear, you are talking about filesystem performance when sharing files with Windows rather than process performance ? The situation is similar on macOS (i.e. slow filesystem), where Docker have developed their own shared filesystem called osxfs.

The previous Podman Machine used sshfs to keep all the files on the Linux VM and share them with the host while editing... I'm not sure yet what the new Podman Machine (podman machine) will use, since it is very early. But it is using QEMU* for VM.

* https://www.qemu.org/2017/11/22/haxm-usage-windows/

Most likely is using nfs on Mac and Linux, and smb on Windows.

[dominic-p]

Yes, @afbjorklund, I'm mostly seeing issues with filesystem performance, but there are other issues with WSL2 as well. I discussed some of the problems I ran into on this mailing list thread a while back. Maybe the situation has improved since then though. I haven't really played with it since.

[afbjorklund]

Right, using fuse-overlayfs is slow enough without trying to make it run with vfs... Also it is mostly a problem for rootless podman running on older Linux kernels.

But if you want filesystem performance, you need to use a local volume mount.

[cdbattags]

Some users are looking for a slightly smaller version of CodeReady Containers, but with Podman instead of OpenShift... There was some talk about adding podman-remote support to the default CRC install, but it is currently broken I think.

• code-ready/crc#1097
• code-ready/crc#1611

This would be similar to using Docker Machine or Podman Machine, instead of Minikube (which includes Kubernetes) If you want to use minikube to set up your VM (with CRI-O container runtime), you can access the podman service on it:

$ minikube start --container-runtime=cri-o
$ eval $(minikube podman-env)

These are not really "native" installs of podman though. They even bring more baggage with the VM, an orchestrator...

But they are integrated with the "native" hypervisor on each, and they exist as products for Linux, macOS and Windows:

• Minishift
• Minikube

I just wrote on https://github.com/kubernetes/minikube/issues/8003 about doing such. I'd be curious if it would make better sense to add an optional dependency on macOS podman install for vagrant and virtualbox for doing something like:

• Podman remote clients for macOS and Windows | Enable Sysadmin
• How to replace Docker with Podman on a Mac | Enable Sysadmin

This would at least automate the VM provision process and the users can even bring their own base image to match their cloud configuration one day.

[afbjorklund]

I just wrote on kubernetes/minikube#8003 about doing such. I'd be curious if it would make better sense to add an optional dependency on macOS podman install for vagrant and virtualbox for doing something like:

• Podman remote clients for macOS and Windows | Enable Sysadmin

• How to replace Docker with Podman on a Mac | Enable Sysadmin

This would at least automate the VM provision process and the users can even bring their own base image to match their cloud configuration one day.

Both vagrant-machine and podman-machine are deprecated, in favor of using the new podman machine with CoreOS...

There is of course nothing stopping you to use Vagrant and Virtualbox, but it is not an integrated "Podman Machine" either.

I don't think there is any blog entry for this new QEMU offering, but maybe there will be - once it has been released (3.2.0) ?

$ podman --version
podman version 3.2.0-rc3
$ podman machine --help
Manage a virtual machine

Description:
  Manage a virtual machine. Virtual machines are used to run Podman.

Usage:
  podman machine [command]

Available Commands:
  init        Initialize a virtual machine
  list        List machines
  rm          Remove an existing machine
  ssh         SSH into an existing machine
  start       Start an existing machine
  stop        Stop an existing machine

@cdbattags : see https://podman.io/community/meeting/notes/2021-04-06/#podman-on-mac-preview for a demo

It will install the Fedora CoreOS image from https://getfedora.org/en/coreos?stream=next, running in a QEMU VM.

Then it sets up two podman system connections to this machine, one for the "core" user and one for the "root" user.

[baude]

As Anders has already said, stay tuned. Good things coming!

[cdbattags]

@cdbattags : see https://podman.io/community/meeting/notes/2021-04-06/#podman-on-mac-preview for a demo

It will install the Fedora CoreOS image from https://getfedora.org/en/coreos?stream=next, running in a QEMU VM.

Any way to get access to that recording? And this works on Podman latest or would I have to build a specific branch?

[afbjorklund]

Any way to get access to that recording?

The link is hidden at the top of the page: https://podman.io/community/meeting/notes/2021-04-06/#bluejeans-recording

And this works on Podman latest

As shown it is available in v3.2.0-rc3, there is no special branch. I have not tried it on Mac, I think you want latest QEMU ?

It should work on any qemu version, but if you want hardware support (HVF, similar to KVM on Linux) you want the latest... Doubly so on the new Apple M1 CPU architecture (arm64). Both architectures are working on Linux out of the box though.

Hopefully there will soon be some documentation for this new version, I only have the old version at boot2podman.github.io

[github-actions[bot]]

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

[rhatdan]

@baude What should we do with this issue at this point?

[baude]

technically speaking, we have something people can use ... but it does not do the port mapping yet. That will come in 3.3. I would be fine with closing or keeping open.

[AnthonyPoschen]

If it is getting closed, having something linked that can be followed for email alerts to know when it's released would be great.

[baude]

lets keep it open until 3.3!

[PRNDA]

nice to hear. can't wait.....

[github-actions[bot]]

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

[rhatdan]

Since podman 3.3 rc2 has been cut, I am closing this issue.

[vietvudanh]

I will be replaced my 6 years old Mac then. Too many things do not work at this point.