We show how to get the free SAP product for developers and administrators - “Abap Platform Trial” - running on Podman: for an Ubuntu Server VM, and for an amd64 (a.k.a. “Intel”) MacBook. For the MacBook case we also show some aspects of Podman Desktop.
Podman is an open-source set of tools for (among other things) managing Linux containers:
https://podman.io/
In its Linux container aspect, it is similar to the Docker tools. This blog isn’t going to discuss Podman vs. Docker, I've got no real interest in those debates, Instead I just wanted to see if Podman can also be used for managing Abap Platform Trial (spoiler: obviously it can, otherwise this blog wouldn’t have been written).
The Abap Platform Trial image releases, as well as SAP’s advice on using Docker to get things up and running, are found on Docker Hub:
https://hub.docker.com/r/sapse/abap-platform-trial
A cupla disclaimer-remarks afore we get started… This blog was written in my spare time, so remember kids, there’s really no Helpdesk if you get stuck, it’s all about BYODS: Bring Your Own Debug Skills. However if you find some errors in the blog itself, feel free to suggest corrections, they’ll be considered. Also, note that I don’t work (directly or indirectly) for either SAP or RedHat (the main contributor to Podman), so have no hotline to these companies, and I don’t represent them in any capacity.
The first prerequisite is that the processor architecture has to be amd64 (a.k.a. “x86_64”). Here we assume that you either: have an amd64-architecture host computer running Ubuntu; or (more likely perhaps, and assumed in our demo) you have the possibility to use a Hypervisor on which you can install and run the amd64-architecture Ubuntu Server as a VM (virtual machine).
According to SAP, the main requirements of the Linux machine are: 4 CPUS, 16 GB of RAM, and 150 GB of disk space available. In my testing, I have found that 4 CPUs is usually enough, but 6 CPUs is much better. Spare what you can while allowing the rest of your computer activities to work.
Also, I have managed to at least start up an existing (successfully created) Abap Platform Trial container with slightly less than 16 GB of RAM assigned to its Linux VM - however this is not something I’d recommend, and may not even work for the container-creation (“podman run”) stage… so 16 GB is a sensible minimum amount; further, once you start using your running container to interact with the system via SAPGUI or via SAP HANA tools, 16 GB is not that great at all and may cause problems, including crashes - so I recommend assigning around 28 GB of RAM to the VM if you can afford to give that much, otherwise give as much as possible but at least 16 GB.
Also I noticed that it’s good to have 150 GB of disk space available under the main (root) partition after you have: installed Ubuntu Server, installed Podman, and pulled the Abap Platform Trial image to your local repo. So to ensure this, my VMs are generally created with a 240 or 250 GB disk. (Yep, I had to start the whole demo installation again with a new VM when writing this blog, due to not having enough disk space at “podman run”-stage; so, if you use a smaller disk than me and cannot get the whole thing working, then it’s worth considering this 250 GB disk idea).
The next step is to install Ubuntu Server. (BTW If you have an Ubuntu Desktop machine or VM, you could install Podman Desktop for Linux, though that is not demonstrated below).
Ubuntu Server can be downloaded from here:
https://ubuntu.com/download/server
A few remarks about the installation workflow…
Choose the default - “English” - as the OS language, as that is the language SAP Abap systems and many other systems tend to work best with. If you like, you can update to the new Installer as suggested on the next screen. Anyway, then you should choose a relevant keyboard layout. Then I choose “Ubuntu Server” rather than “Ubuntu Server (minimised)”, as I cannot be bothered finding out later which utilities I still need to install etc. Don’t check the “third-party drivers” as we don’t need those.
Assuming you are using default NAT networking of your Hypervisor, usually you just choose whatever network interface config and IP address is suggested, it will probably look like this, with some IPv4 address of the private network:
If you need to supply a proxy address to connect to the internet, you can enter it in the relevant screen. Then in the archive mirror screen either accept the suggested server or specify one that you think is better. I usually let Ubuntu Installer test that the mirror is responding, then continue to the next screen. Here, my advice is to uncheck the option to use LVM - why? Well, because in practice LVM slightly reduces the amount of usable disk space, and also, our "one-purpose" VM's sizing is easily controlled usually by you at the Hypervisor level. So you should have the configuration like this:
When you fill in details like username, it’s best to call your server: vhcala4hci … which will match the name of the podman “container as host” later, and potentially save you from strange SAP system bugs even later. If you choose some other server name, well good luck with that, though expect no sympathy from me if it all goes pear-shaped.
Skip the Ubuntu Pro option. But do choose “Install OpenSSH Server” when asked, as it’s very useful to be able to SSH in from a host Terminal. Do not choose any of the “snaps” offered. (Even if we were going to use Docker - which we’re not - but even if we were, IMHO the correct way to install things is almost always to use the apt tool, and avoid using the snaps; I speak here from bitter, sweary experience).
Once Ubuntu Server is installed, we login and can then start configuring a cupla things…
As it is convenient to copy-paste commands into a terminal running on the host computer, so SSH is our friend here; also, it's convenient to SSH in using the hostname rather than the raw IPv4 address, so I modified the host computer (MacBook in my case) hosts file as follows:
Added these lines (obviously you use the relevant IP address of your server, not mine):
And Save and Close (nano/pico users: Ctrl-O, Ctrl-X). This hosts file modification is also very useful later, e.g. when you want to e.g. make a SAPGUI Connection Item that refers to vhcala4hci instead of the raw IPv4 address.
Supposing your main user on Ubuntu Server is called “marmot”, then the command for SSHing from host into Ubuntu would now be:
Now we can start up Ubuntu Server. Then it’s just good housekeeping to update the repos and upgrade the packages to the latest versions, so we do that:
When shown the candidates for daemon restarts, accept the suggested ones by hitting <Enter> (or by tabbing to <Ok> and then <Enter>, if you like using the tab key that much):
Next we should install Podman (a.k.a. “Podman Engine”):
Although you need to run as sudo to install Podman, an interesting thing is that when you actually start using Podman to manage images and containers, generally (and in our case) you don’t need to run as sudo, instead you just run as your ordinary user. See the internet for pedantic debates about sudo vs non-sudo container management.
At this point, it might be worth rebooting our Ubuntu Server so that all the daemons are using the latest version of the libraries.
Once we are logged in again to Ubuntu Server, there is something that is kinda specific to Ubuntu for running SAP systems, which I think we need to do… though I have a theory about why this is needed, it’s a long explanation and not so relevant to the blog purposes, so all I’m saying is that I used these following modifications back in the days when installing a “predecessor” of Abap Platform Trial (called SAP NetWeaver Developer Edition) on Ubuntu, and now I used them in this Abap Platform Trial to successfully get past a failed spin up attempt… so my experience says that it’s really worth implementing this…
So the trick is to adjust the Ubuntu Server’s /etc/hosts file in two ways… We comment out (using the # character at beginning of a line) the self-referential mapping from 127.0.1.1 to the hostname (vhcala4hci). Then we add a new self-referential mapping, from whatever the IP address of the Ubuntu Server is “from the outside looking in”, in my case from 172.16.53.142 to the hostname (vhcala4hci) and an FQDN (vhcala4hci.dummy.nodomain).
Once you have done that, you should have something like these lines in your hosts file:
Note that we will specify the registry (docker.io) as a prefix, so that we don’t need to configure registries in Podman’s configuration files; also note that we are pulling the latest release as of late December 2023, which was “1909_SP01”. You can see the releases here:
https://hub.docker.com/r/sapse/abap-platform-trial/tags
And since we are using Podman, our pull command is:
There’s about 20 GB to download so it may take a wee while...
… and you’ll notice that once the downloading part is done, it looks as if nothing happens for a wee bit longer while - but be patient, nothing has gone wrong: in reality Podman is still working hard in the background, extracting the image from the downloaded archives and then writing the image to disk. If you have another terminal session open, you can check the (slow) progress of Podman, by noting the gradual decrease in Available Space when executing this command every so often:
Eventually, the podman-pull command finishes its work. If you like you can check the image is really now there in the local repo with the command:
Now we are ready to create and run our target container…
The SAP advice on the Abap Platform Trial website shows the Docker command to use, but because we are using Podman, and because nerdvana etcetera, did some home-made adjustments:
used the command “podman” instead of “docker”;
swapped “-it” in for “-i”, as it might be convenient to have a pseudo-TTY available;
added a port-mapping for port 3601, in case the Message Server might be useful e.g. when defining SAPGUI Connection Item config;
added “docker.io/” as a part of the name of the image, so that it matches the image we have stored in our local repo.
And now we utter the magic spell:
and… for me it took quite a few minutes (about 10) to get HDB started, and then a couple more minutes to SUCCEED in getting the whole A4H system up and running:
Once it’s up and running, skip past the Intel MacBook sections of the blog to the sections of the blog called: Configuring the A4H System and Stopping and Starting the container - to make sure you have a valid set of licenses in SLICENSE and know how to stop and start your a4h container, etcetera.
We could probably just install the Podman Engine for command line use, but since there’s a Podman Desktop available and many people like GUI apps, let’s install that anyway - the main site is here:
https://podman-desktop.io/
From there you can go to “Other downloads” to explicitly choose the version that is relevant for macOS and for your architecture - in our case, “Intel” is the correct option.
[Note: there is also the option to use Homebrew (“Brew”), but I decided to go with the DMG file. A word of warning though - if you decide to use DMG / PKG formats to install Podman Desktop and Podman Engine stuff, stick with those formats on your machine, as Podman may break if you decide to “mix and match” with e.g. DMG Podman Desktop and Homebrew Podman Engine. It’s possible to recover from this broken state, but it’s not that easy.]
Anyway you install the Podman Desktop from the DMG by moving the icon into Applications. Double-click on your new app to open it. Then press “Go to Podman Desktop”:
As you see you need to then press “Set up” to let the app do some self-configuration of the Podman extension, so we do that and follow the workflow:
Press “Next” to kick off the installation of the Podman Engine… note that as part of this install you will need to provide your admin password (or Touch ID) as this installation can only be done by a sudoer (admin) user. Once done you are returned to the main workflow, where you have the option to Autostart Podman engine when launching Podman Desktop - I toggle that to “Enabled”, because usually when we will use Podman Desktop, we will want to have the Podman engine running. (If you don’t choose Autostart, then from Podman Desktop you can still manually start the Podman Engine).
Next step in the workflow is to create a Podman Machine, we can check first what a Podman machine is from here:
https://docs.podman.io/en/stable/markdown/podman-machine.1.html
“Podman on MacOS and Windows requires a virtual machine. This is because containers are Linux - containers do not run on any other OS because containers’ core functionality are tied to the Linux kernel. Podman machine must be used to manage MacOS and Windows machines, but can be optionally used on Linux.”
So it’s necessary for us on macOS to create such a useful virtual machine, hit “Next” to do that step. You get a screen that initially should look something like this:
If we were just wanting to do some Hello World tutorials, then the default values would be fine. But we are instead wanting to run Abap Platform Trial, a fairly demanding kinda container:
https://hub.docker.com/r/sapse/abap-platform-trial
“We highly recommend 32GB RAM to run the ABAP Platform Trial image. The following requirements only cover the resources needed for the Docker environment itself.
…
macOS
I cannot quite offer 32 GB RAM to the Podman Machine VM, as the host computer itself only has 32 GB RAM, so I will offer it about 29 GB of RAM.
Then we will offer the 4 CPUs, and about 220 GB disk (slightly less than for the Ubuntu Server case, as the Podman Machine’s underlying Fedora Core OS takes up less room and is optimised for container stuff).
The sliders are a bit annoying as it’s tricky to specify exactly e.g. 28.68 GB of RAM and so on. (Later when I deleted the first machine and created a new one, the option to specify values was available for Podman Machine via Settings -> Resources -> Podman -> Create New). We keep the other options as is. And press Create… takes a minute or so to create the VM, and as in this case I chose to start the new VM when created, it takes another cupla minutes waiting for the status to go from “Podman is starting..” to “Podman is running”, anyway you should eventually get a success message:
In Settings -> Resources tab we see:
The reason the created Podman Machine shows “less” disk size and memory than what we specified, is because in computing there are two ways of deciding how many Megabytes are in a Gigabyte. Leaving the study of that as an exercise for the reader; though if you want a calculator to show you how many Gigabytes would you get for roughly 29000 Megabytes, then try this one:
https://www.gbmb.org/mb-to-gb
Ok let’s stop the Podman Machine, either from Settings or from the MacBook top menu bar Podman icon, or you can use the command:
Now we can close the Podman Desktop. To properly shutdown Podman Desktop, we can also use Quit from the top menu bar Podman options… or, in Settings -> Preferences you can enable “Exit on Close”. Another option in the same Preferences tab is “Start on login”, I switched that off because Podman POCs aren’t something I’m intending to do every day.
Podman Desktop uses Podman (a.k.a. Podman Engine) to do all its hard work, including initialising and starting/stopping Podman Machines. If you like you can teach yourself the equivalent commands, the main documentation is here:
https://docs.podman.io/en/latest/
Any Podman Machines, containers, etc that you created from the command line are also visible in and can be managed from the Podman Desktop app.
With Podman Desktop open and Podman Machine started and running, and with a connection to the Internet (since that is where we the images we want to pull - i.e. download - are stored), go to the Images tab which will be empty. Podman Desktop is offering the “Pull an image” button, and also giving you an example of how to pull an image using the command line (i.e. not using Podman Desktop 😀). Well, let’s follow both options… first we can copy the podman command, open Terminal, and pull the image:
When the image is pulled successfully, it automagically appears in Podman Desktop. It’s less than 100 kB in size so we don’t need to worry about Podman Machine running out of space for our target image from SAP later. We can also list the locally stored images we have, using the command:
Now we see the Image ID, so we can copy-paste that into the image-removal command, then check it has gone:
It’s also now gone from the Podman Desktop list, which is what we expected to happen.
Next, we pull the same image, this time using Podman Desktop… “Pull an image”, just enter the name of the remote image:
Then press “Pull image”, which in the background is just doing what we did in Terminal earlier. So once it says “Done” we can see the image has reappeared in the list of images, good.
Ok that’s enough practice for now, next step is to pull the Abap Platform Trial image. Good to check which versions are available, from here:
https://hub.docker.com/r/sapse/abap-platform-trial/tags
Note the OS/ARCH-attribute which has value “linux/amd64”, which is what we expect. We like to test the latest releases, at POC-time that was “1909_SP01”; depending on your preferred method, you either enter in Podman Desktop pull-workflow:
or you run this Podman command:
(Podman installation on macOS has already preconfigured docker.io (Docker Hub) as a registry to search for images from, so that is why we don’t have to specify the prefix “docker.io/” for the image name. But if you run into “not found” issues just add that prefix, like we did in the Ubuntu Server case). As it’s 20 GB in size, depending on your download speed this may take a few minutes or quite many minutes… and then some minutes go by as the image is extracted and stored in the local repo…Eventually it gets there:
Next, we need to create and run a container based on the image...
As a harmless exercise let’s create and start a new container based on the quay.io/podman/hello image. First make sure the Podman Machine is running, then go to the Images tab, and press the “Run image” button highlighted to the right of the relevant image. That takes us to a screen where various configuration options are available including Port mapping (in the Basic tab): but we are just going to press “Start Container”, which creates and then starts the container; the container itself is only up and running for a second or so and then exits (stops), as we can see in Containers view.
Go to the Logs tab to see the results of running the container:
So that’s all fine, and nice ASCII-artwork. But for our Abap Platform Trial container, we are going to start it from the command line (using Podman Engine). Then we need to know: what parameters do we need? Well, here is the suggestion from SAP’s Abap Platform Trial website:
docker run --stop-timeout 3600 -i --name a4h -h vhcala4hci -p 3200:3200 -p 3300:3300 -p 8443:8443 -p 30213:30213 -p 50000:50000 -p 50001:50001 sapse/abap-platform-trial:1909 -skip-limits-check
Our command will be slightly different though, as it’s going to be suitable for Podman, adds a tty, adds port-mapping 3601, and adds the option agreeing to the SAP license:
So we have the Podman Machine up and running, and we open a Terminal and run the command:
[Or, if you have the “docker.io” prefix as part of the image name in the local repo, then the command is instead:
]
There will likely be some warnings about some values being lower than recommended values, that is why we included “-skip-limits-check” (to treat those as warnings instead of as showstopping errors). Then a message saying “HDB: starting”... this might take 10 minutes or so, then we get some other logs about HDB and then about starting up the Application Servers of the SAP Abap System itself.. assuming all goes well, after some minutes you should get the Great Success message, which looks like so:
BANZAI!! You can check the Podman Machine in Podman Desktop - with our container running it’s already using 60% of the memory, which is about 17 GB, quite a lot more than most containers (and when you actually start using the system, e.g. SAPGUI sessions and generating the Abap programs by tcode surfing etcetera, expect the memory usage to increase):
The container is available on localhost, which already has a mapping in your MacBook’s /etc/hosts file with the line:
We leave that line in peace, definitely do not delete it as it is kinda essential! However, we can safely add a new line (with a new comment line as well) into the /etc/hosts file:
Either of these commands are useful for editing your hosts file:
Now you can go through the sections of the blog called: Configuring the A4H System and Stopping and Starting the container - to make sure you have a valid set of licenses in SLICENSE and know how to stop and start your a4h container, etcetera.
Getting the licenses updated has been simplified somewhat in the Abap Platform Trial compared with its predecessor image (“Abap Trial”), there is some advice from SAP at:
https://hub.docker.com/r/sapse/abap-platform-trial
We will use SAPGUI as the method for updating the licenses. We’re not making this a tutorial on creating new Connection Items in SAPGUI for Java, but if you use the Advanced tab and check the box that allows you to enter a Connection String, then depending whether you modified the host computer’s /etc/hosts that string will be something like one of these examples (the third one is for the case when using Podman on macOS and no hosts file mapping done):
Then we follow this advice from the SAP website:
“Updating the license via SAPGUI (SLICENSE) The ABAP license supplied with the Docker image lasts only three months. Therefore, you should download and import the demo license as follows:
You will need to know the password for the SAP User IDs to logon - if you search down through the same SAP website you find the relevant information:
“User and Passwords
The user name is DEVELOPER. The password is:
This is also predefined (same password) for client 000, client 001: SAP* , DDIC.”
So in my case, using version 1909_SP01, ah need to pick the second of those passwords. Then it’s also helpful to know the URL for “minisap” mentioned, that is here:
https://go.support.sap.com/minisap/#/minisap
So you get the (multi-)license file downloaded, then as user SAP* in client 000, in SLICENSE tcode, upload it to the SAP System. [Step (3.) of the SAP advice above doesn’t mention you need to actually do this uploading yourself, so thought I would mention that here. Then complete Steps (4.) and (5.) from the SAP advice quoted above].
Then you can start doing SAP-level tasks like writing Abap programs (no Developer Key needed), configuring STRUST, creating new users, etcetera:
The first thing to do, is log off from any SAPGUI or other sessions that you have, to avoid losing your work etcetera.
Assuming you created the container including the “--stop-time-out” parameter with reasonable value such as 3600 (seconds, i.e. up to one hour allowed for graceful shutdown), then one way to stop the container is to press Ctrl-C in the same session where you started the container.
Another way to stop the container… if you open another shell session, then the following will work just fine (either of these, as “-t” is just the abbreviated form of parameter “--time”) - these commands tell podman to stop the container “a4h” and give it an hour’s grace before issuing any hard stop:
To see stopped containers from the command line, you can use the following (need “--all” to also list non-running containers):
Then the command to givea you lots of detail about your container named "a4h":
Remember campers: “podman start” starts up an already existing, but stopped, container (while the command we used earlier - “podman run” - first creates the container - magics it into existence - and then also starts it up).
So, we can (re-)start our container with the command:
If the “podman run” attempt fails, or other problems occur, well, unfortunately for you (but fortunately for me) neither my day job nor my free time is about providing tech-support for the SAP Community readers - so it’s really up to you to work out what went wrong and how to fix it. Anyway I would advise checking that you have enough disk space on the VM (keep around 160 GB free before spinning up a container), memory (at least 16 GB), and CPUs (4 is usually ok, 6 is usually better).
Then there is the SAP Abap Platform Trial website itself, which has various Troubleshooting hints - a useful one is to remove any failed - yet still existing - containers called “a4h” before attempting to create a new one… Removing an existing container is easily done in Podman Desktop (use the Delete icon in Containers tab), and also easy to do from the command line: first check for the existence of the target container (use “--all” parameter to list stopped containers also), and then delete it using its name (“a4h” in this case) or its Container ID:
Other than that, you can google for possible answers to your troubles, mostly those searches will point to various threads or blogs in the SAP Community websites (Abap Platform Trial image is not a commercial SAP Product that SAP are selling to customers, so you cannot expect SAP Support to resolve any issues). Podman is open-source, so you can find discussions about Podman-related issues on GitHub, Stack Overflow, and so on. Good luck now!
[ Feel free to skip this section..
There are two advantages IMHO of using a Linux VM for our task. One is that it’s possible to run a Linux VM on most OS variants including macOS and Windows, so this Linux VM solution is more general than an OS-specific solution such as Podman Desktop (or Docker Desktop) for macOS or Windows; further, if you have suitable software for Emulated VMs, then you can run the amd64 Linux VM on e.g. an arm64 host computer - for example, if you have an M-chip MacBook, you can probably use the UTM Emulator-Hypervisor:
https://mac.getutm.app/
See also a couple of blogs that use this approach, this one for an earlier version of Abap Platform Trial (using Docker):
https://blogs.sap.com/2021/12/16/how-to-install-abap-1909-on-mac-m1-apple-silicon/
And this one for a related mini-SAP product (not using container technology - self-promotion warning: I wrote this one):
https://blogs.sap.com/2022/03/31/qemu-and-sap-dev-edition-via-utm-for-macbook-m1/
Note that if you are going to use an emulated amd64 VM, e.g. on an M-chip MacBook, you will want to give your VM as many CPUs as you can afford (while not ruining the performance effect by slowing your host computer too badly), and also if possible give the VM more memory than recommended above - mainly because the emulation of a whole VM means the VM runs really slowly, which can mean that e.g. the "HDB start"-related processes timeout waiting for hdbdaemon, or timeout waiting on the memory needed to supply data to the processes themselves - the only remedy is to hope that with many CPUs and plenty of memory, the VM works fast enough to avoid such timeout issues. Disclaimer - at the time of writing, I don’t currently have access to an M-chip MacBook with enough memory and processing power to actually test this theory for Abap Platform Trial.
For the same “no access to suitable M-chip MacBook” reason, I haven’t considered using e.g. Podman Desktop/Engine for arm64 macOS in this blog. Unlike Docker (since summer 2023), Podman doesn’t yet have a convenient checkbox or config setting letting you use Apple Rosetta, instead Podman sticks to using its own QEMU framework, and that framework may or may not be good enough or configurable enough to run Abap Platform Trial. If someday I get hold of a usable M-chip MacBook, I’ll investigate.
The other advantage of using a Linux distro like Ubuntu, is that Podman (or Docker, etc) is always about Linux containers - even when you run Podman (or Docker, etc) on macOS or Windows, what actually happens is that a Linux VM is created and everything container-wise happens inside that Linux VM. So to me it seems quite an elegant approach to just create our own Linux VM and then run Podman (or Docker, etc) inside that VM “directly” (i.e. we don’t need a Podman Machine running on Linux, even though this could be done). ]
Podman is an open-source set of tools for (among other things) managing Linux containers:
https://podman.io/
In its Linux container aspect, it is similar to the Docker tools. This blog isn’t going to discuss Podman vs. Docker, I've got no real interest in those debates, Instead I just wanted to see if Podman can also be used for managing Abap Platform Trial (spoiler: obviously it can, otherwise this blog wouldn’t have been written).
The Abap Platform Trial image releases, as well as SAP’s advice on using Docker to get things up and running, are found on Docker Hub:
https://hub.docker.com/r/sapse/abap-platform-trial
A cupla disclaimer-remarks afore we get started… This blog was written in my spare time, so remember kids, there’s really no Helpdesk if you get stuck, it’s all about BYODS: Bring Your Own Debug Skills. However if you find some errors in the blog itself, feel free to suggest corrections, they’ll be considered. Also, note that I don’t work (directly or indirectly) for either SAP or RedHat (the main contributor to Podman), so have no hotline to these companies, and I don’t represent them in any capacity.
Ubuntu Server amd64 as the OS for Podman
Hardware or virtual hardware prerequisites
The first prerequisite is that the processor architecture has to be amd64 (a.k.a. “x86_64”). Here we assume that you either: have an amd64-architecture host computer running Ubuntu; or (more likely perhaps, and assumed in our demo) you have the possibility to use a Hypervisor on which you can install and run the amd64-architecture Ubuntu Server as a VM (virtual machine).
According to SAP, the main requirements of the Linux machine are: 4 CPUS, 16 GB of RAM, and 150 GB of disk space available. In my testing, I have found that 4 CPUs is usually enough, but 6 CPUs is much better. Spare what you can while allowing the rest of your computer activities to work.
Also, I have managed to at least start up an existing (successfully created) Abap Platform Trial container with slightly less than 16 GB of RAM assigned to its Linux VM - however this is not something I’d recommend, and may not even work for the container-creation (“podman run”) stage… so 16 GB is a sensible minimum amount; further, once you start using your running container to interact with the system via SAPGUI or via SAP HANA tools, 16 GB is not that great at all and may cause problems, including crashes - so I recommend assigning around 28 GB of RAM to the VM if you can afford to give that much, otherwise give as much as possible but at least 16 GB.
Also I noticed that it’s good to have 150 GB of disk space available under the main (root) partition after you have: installed Ubuntu Server, installed Podman, and pulled the Abap Platform Trial image to your local repo. So to ensure this, my VMs are generally created with a 240 or 250 GB disk. (Yep, I had to start the whole demo installation again with a new VM when writing this blog, due to not having enough disk space at “podman run”-stage; so, if you use a smaller disk than me and cannot get the whole thing working, then it’s worth considering this 250 GB disk idea).
The next step is to install Ubuntu Server. (BTW If you have an Ubuntu Desktop machine or VM, you could install Podman Desktop for Linux, though that is not demonstrated below).
Install Ubuntu Server
Ubuntu Server can be downloaded from here:
https://ubuntu.com/download/server
A few remarks about the installation workflow…
Choose the default - “English” - as the OS language, as that is the language SAP Abap systems and many other systems tend to work best with. If you like, you can update to the new Installer as suggested on the next screen. Anyway, then you should choose a relevant keyboard layout. Then I choose “Ubuntu Server” rather than “Ubuntu Server (minimised)”, as I cannot be bothered finding out later which utilities I still need to install etc. Don’t check the “third-party drivers” as we don’t need those.
Assuming you are using default NAT networking of your Hypervisor, usually you just choose whatever network interface config and IP address is suggested, it will probably look like this, with some IPv4 address of the private network:
If you need to supply a proxy address to connect to the internet, you can enter it in the relevant screen. Then in the archive mirror screen either accept the suggested server or specify one that you think is better. I usually let Ubuntu Installer test that the mirror is responding, then continue to the next screen. Here, my advice is to uncheck the option to use LVM - why? Well, because in practice LVM slightly reduces the amount of usable disk space, and also, our "one-purpose" VM's sizing is easily controlled usually by you at the Hypervisor level. So you should have the configuration like this:
When you fill in details like username, it’s best to call your server: vhcala4hci … which will match the name of the podman “container as host” later, and potentially save you from strange SAP system bugs even later. If you choose some other server name, well good luck with that, though expect no sympathy from me if it all goes pear-shaped.
Skip the Ubuntu Pro option. But do choose “Install OpenSSH Server” when asked, as it’s very useful to be able to SSH in from a host Terminal. Do not choose any of the “snaps” offered. (Even if we were going to use Docker - which we’re not - but even if we were, IMHO the correct way to install things is almost always to use the apt tool, and avoid using the snaps; I speak here from bitter, sweary experience).
Once Ubuntu Server is installed, we login and can then start configuring a cupla things…
SSH into Ubuntu Server
As it is convenient to copy-paste commands into a terminal running on the host computer, so SSH is our friend here; also, it's convenient to SSH in using the hostname rather than the raw IPv4 address, so I modified the host computer (MacBook in my case) hosts file as follows:
sudo nano /etc/hostsAdded these lines (obviously you use the relevant IP address of your server, not mine):
# For the Ubuntu Server that runs Abap Platform Trial:
172.16.53.142 vhcala4hci vhcala4hci.dummy.nodomainAnd Save and Close (nano/pico users: Ctrl-O, Ctrl-X). This hosts file modification is also very useful later, e.g. when you want to e.g. make a SAPGUI Connection Item that refers to vhcala4hci instead of the raw IPv4 address.
Supposing your main user on Ubuntu Server is called “marmot”, then the command for SSHing from host into Ubuntu would now be:
ssh marmot@vhcala4hciConfigure Ubuntu Server and install Podman Engine.
Now we can start up Ubuntu Server. Then it’s just good housekeeping to update the repos and upgrade the packages to the latest versions, so we do that:
sudo apt update
sudo apt upgrade -yWhen shown the candidates for daemon restarts, accept the suggested ones by hitting <Enter> (or by tabbing to <Ok> and then <Enter>, if you like using the tab key that much):
Next we should install Podman (a.k.a. “Podman Engine”):
sudo apt -y install podmanAlthough you need to run as sudo to install Podman, an interesting thing is that when you actually start using Podman to manage images and containers, generally (and in our case) you don’t need to run as sudo, instead you just run as your ordinary user. See the internet for pedantic debates about sudo vs non-sudo container management.
At this point, it might be worth rebooting our Ubuntu Server so that all the daemons are using the latest version of the libraries.
sudo shutdown -r nowOnce we are logged in again to Ubuntu Server, there is something that is kinda specific to Ubuntu for running SAP systems, which I think we need to do… though I have a theory about why this is needed, it’s a long explanation and not so relevant to the blog purposes, so all I’m saying is that I used these following modifications back in the days when installing a “predecessor” of Abap Platform Trial (called SAP NetWeaver Developer Edition) on Ubuntu, and now I used them in this Abap Platform Trial to successfully get past a failed spin up attempt… so my experience says that it’s really worth implementing this…
So the trick is to adjust the Ubuntu Server’s /etc/hosts file in two ways… We comment out (using the # character at beginning of a line) the self-referential mapping from 127.0.1.1 to the hostname (vhcala4hci). Then we add a new self-referential mapping, from whatever the IP address of the Ubuntu Server is “from the outside looking in”, in my case from 172.16.53.142 to the hostname (vhcala4hci) and an FQDN (vhcala4hci.dummy.nodomain).
sudo nano /etc/hostsOnce you have done that, you should have something like these lines in your hosts file:
# Comment out as it confuses SAP:
#127.0.1.1 vhcala4hci
# Then add this self-reference instead:
172.16.53.142 vhcala4hci vhcala4hci.dummy.nodomainPull the Abap Platform Trial image
Note that we will specify the registry (docker.io) as a prefix, so that we don’t need to configure registries in Podman’s configuration files; also note that we are pulling the latest release as of late December 2023, which was “1909_SP01”. You can see the releases here:
https://hub.docker.com/r/sapse/abap-platform-trial/tags
And since we are using Podman, our pull command is:
podman pull docker.io/sapse/abap-platform-trial:1909_SP01There’s about 20 GB to download so it may take a wee while...
… and you’ll notice that once the downloading part is done, it looks as if nothing happens for a wee bit longer while - but be patient, nothing has gone wrong: in reality Podman is still working hard in the background, extracting the image from the downloaded archives and then writing the image to disk. If you have another terminal session open, you can check the (slow) progress of Podman, by noting the gradual decrease in Available Space when executing this command every so often:
df -hEventually, the podman-pull command finishes its work. If you like you can check the image is really now there in the local repo with the command:
podman image listNow we are ready to create and run our target container…
Spin up the container a4h of Abap Platform Trial
The SAP advice on the Abap Platform Trial website shows the Docker command to use, but because we are using Podman, and because nerdvana etcetera, did some home-made adjustments:
used the command “podman” instead of “docker”;
swapped “-it” in for “-i”, as it might be convenient to have a pseudo-TTY available;
added a port-mapping for port 3601, in case the Message Server might be useful e.g. when defining SAPGUI Connection Item config;
added “docker.io/” as a part of the name of the image, so that it matches the image we have stored in our local repo.
And now we utter the magic spell:
podman run --stop-timeout 3600 -it --name a4h -h vhcala4hci -p 3200:3200 -p 3300:3300 -p 3601:3601 -p 8443:8443 -p 30213:30213 -p 50000:50000 -p 50001:50001 docker.io/sapse/abap-platform-trial:1909_SP01 -skip-limits-check -agree-to-sap-licenseand… for me it took quite a few minutes (about 10) to get HDB started, and then a couple more minutes to SUCCEED in getting the whole A4H system up and running:
Once it’s up and running, skip past the Intel MacBook sections of the blog to the sections of the blog called: Configuring the A4H System and Stopping and Starting the container - to make sure you have a valid set of licenses in SLICENSE and know how to stop and start your a4h container, etcetera.
Intel MacBook as the OS for Podman
Install Podman Desktop and create a Podman Machine
We could probably just install the Podman Engine for command line use, but since there’s a Podman Desktop available and many people like GUI apps, let’s install that anyway - the main site is here:
https://podman-desktop.io/
From there you can go to “Other downloads” to explicitly choose the version that is relevant for macOS and for your architecture - in our case, “Intel” is the correct option.
[Note: there is also the option to use Homebrew (“Brew”), but I decided to go with the DMG file. A word of warning though - if you decide to use DMG / PKG formats to install Podman Desktop and Podman Engine stuff, stick with those formats on your machine, as Podman may break if you decide to “mix and match” with e.g. DMG Podman Desktop and Homebrew Podman Engine. It’s possible to recover from this broken state, but it’s not that easy.]
Anyway you install the Podman Desktop from the DMG by moving the icon into Applications. Double-click on your new app to open it. Then press “Go to Podman Desktop”:
As you see you need to then press “Set up” to let the app do some self-configuration of the Podman extension, so we do that and follow the workflow:
Press “Next” to kick off the installation of the Podman Engine… note that as part of this install you will need to provide your admin password (or Touch ID) as this installation can only be done by a sudoer (admin) user. Once done you are returned to the main workflow, where you have the option to Autostart Podman engine when launching Podman Desktop - I toggle that to “Enabled”, because usually when we will use Podman Desktop, we will want to have the Podman engine running. (If you don’t choose Autostart, then from Podman Desktop you can still manually start the Podman Engine).
Next step in the workflow is to create a Podman Machine, we can check first what a Podman machine is from here:
https://docs.podman.io/en/stable/markdown/podman-machine.1.html
“Podman on MacOS and Windows requires a virtual machine. This is because containers are Linux - containers do not run on any other OS because containers’ core functionality are tied to the Linux kernel. Podman machine must be used to manage MacOS and Windows machines, but can be optionally used on Linux.”
So it’s necessary for us on macOS to create such a useful virtual machine, hit “Next” to do that step. You get a screen that initially should look something like this:
If we were just wanting to do some Hello World tutorials, then the default values would be fine. But we are instead wanting to run Abap Platform Trial, a fairly demanding kinda container:
https://hub.docker.com/r/sapse/abap-platform-trial
“We highly recommend 32GB RAM to run the ABAP Platform Trial image. The following requirements only cover the resources needed for the Docker environment itself.
…
macOS
- 4 CPUs for Docker Desktop
- 16GB for Docker Desktop
- 170GB disk for Docker Desktop”
I cannot quite offer 32 GB RAM to the Podman Machine VM, as the host computer itself only has 32 GB RAM, so I will offer it about 29 GB of RAM.
Then we will offer the 4 CPUs, and about 220 GB disk (slightly less than for the Ubuntu Server case, as the Podman Machine’s underlying Fedora Core OS takes up less room and is optimised for container stuff).
The sliders are a bit annoying as it’s tricky to specify exactly e.g. 28.68 GB of RAM and so on. (Later when I deleted the first machine and created a new one, the option to specify values was available for Podman Machine via Settings -> Resources -> Podman -> Create New). We keep the other options as is. And press Create… takes a minute or so to create the VM, and as in this case I chose to start the new VM when created, it takes another cupla minutes waiting for the status to go from “Podman is starting..” to “Podman is running”, anyway you should eventually get a success message:
In Settings -> Resources tab we see:
The reason the created Podman Machine shows “less” disk size and memory than what we specified, is because in computing there are two ways of deciding how many Megabytes are in a Gigabyte. Leaving the study of that as an exercise for the reader; though if you want a calculator to show you how many Gigabytes would you get for roughly 29000 Megabytes, then try this one:
https://www.gbmb.org/mb-to-gb
Ok let’s stop the Podman Machine, either from Settings or from the MacBook top menu bar Podman icon, or you can use the command:
podman machine stopNow we can close the Podman Desktop. To properly shutdown Podman Desktop, we can also use Quit from the top menu bar Podman options… or, in Settings -> Preferences you can enable “Exit on Close”. Another option in the same Preferences tab is “Start on login”, I switched that off because Podman POCs aren’t something I’m intending to do every day.
Command-line for Podman Engine
Podman Desktop uses Podman (a.k.a. Podman Engine) to do all its hard work, including initialising and starting/stopping Podman Machines. If you like you can teach yourself the equivalent commands, the main documentation is here:
https://docs.podman.io/en/latest/
Any Podman Machines, containers, etc that you created from the command line are also visible in and can be managed from the Podman Desktop app.
Pull the Abap Platform Trial image
With Podman Desktop open and Podman Machine started and running, and with a connection to the Internet (since that is where we the images we want to pull - i.e. download - are stored), go to the Images tab which will be empty. Podman Desktop is offering the “Pull an image” button, and also giving you an example of how to pull an image using the command line (i.e. not using Podman Desktop 😀). Well, let’s follow both options… first we can copy the podman command, open Terminal, and pull the image:
podman pull quay.io/podman/helloWhen the image is pulled successfully, it automagically appears in Podman Desktop. It’s less than 100 kB in size so we don’t need to worry about Podman Machine running out of space for our target image from SAP later. We can also list the locally stored images we have, using the command:
podman image listNow we see the Image ID, so we can copy-paste that into the image-removal command, then check it has gone:
podman rmi e2b3db5d4fdf
podman image listIt’s also now gone from the Podman Desktop list, which is what we expected to happen.
Next, we pull the same image, this time using Podman Desktop… “Pull an image”, just enter the name of the remote image:
quay.io/podman/helloThen press “Pull image”, which in the background is just doing what we did in Terminal earlier. So once it says “Done” we can see the image has reappeared in the list of images, good.
Ok that’s enough practice for now, next step is to pull the Abap Platform Trial image. Good to check which versions are available, from here:
https://hub.docker.com/r/sapse/abap-platform-trial/tags
Note the OS/ARCH-attribute which has value “linux/amd64”, which is what we expect. We like to test the latest releases, at POC-time that was “1909_SP01”; depending on your preferred method, you either enter in Podman Desktop pull-workflow:
sapse/abap-platform-trial:1909_SP01
or you run this Podman command:
podman pull sapse/abap-platform-trial:1909_SP01(Podman installation on macOS has already preconfigured docker.io (Docker Hub) as a registry to search for images from, so that is why we don’t have to specify the prefix “docker.io/” for the image name. But if you run into “not found” issues just add that prefix, like we did in the Ubuntu Server case). As it’s 20 GB in size, depending on your download speed this may take a few minutes or quite many minutes… and then some minutes go by as the image is extracted and stored in the local repo…Eventually it gets there:
Next, we need to create and run a container based on the image...
Spin up the a4h Container
As a harmless exercise let’s create and start a new container based on the quay.io/podman/hello image. First make sure the Podman Machine is running, then go to the Images tab, and press the “Run image” button highlighted to the right of the relevant image. That takes us to a screen where various configuration options are available including Port mapping (in the Basic tab): but we are just going to press “Start Container”, which creates and then starts the container; the container itself is only up and running for a second or so and then exits (stops), as we can see in Containers view.
Go to the Logs tab to see the results of running the container:
So that’s all fine, and nice ASCII-artwork. But for our Abap Platform Trial container, we are going to start it from the command line (using Podman Engine). Then we need to know: what parameters do we need? Well, here is the suggestion from SAP’s Abap Platform Trial website:
docker run --stop-timeout 3600 -i --name a4h -h vhcala4hci -p 3200:3200 -p 3300:3300 -p 8443:8443 -p 30213:30213 -p 50000:50000 -p 50001:50001 sapse/abap-platform-trial:1909 -skip-limits-check
Our command will be slightly different though, as it’s going to be suitable for Podman, adds a tty, adds port-mapping 3601, and adds the option agreeing to the SAP license:
So we have the Podman Machine up and running, and we open a Terminal and run the command:
podman run --stop-timeout 3600 -it --name a4h -h vhcala4hci -p 3200:3200 -p 3300:3300 -p 3601:3601 -p 8443:8443 -p 30213:30213 -p 50000:50000 -p 50001:50001 sapse/abap-platform-trial:1909_SP01 -skip-limits-check -agree-to-sap-license[Or, if you have the “docker.io” prefix as part of the image name in the local repo, then the command is instead:
podman run --stop-timeout 3600 -it --name a4h -h vhcala4hci -p 3200:3200 -p 3300:3300 -p 3601:3601 -p 8443:8443 -p 30213:30213 -p 50000:50000 -p 50001:50001 docker.io/sapse/abap-platform-trial:1909_SP01 -skip-limits-check -agree-to-sap-license]
There will likely be some warnings about some values being lower than recommended values, that is why we included “-skip-limits-check” (to treat those as warnings instead of as showstopping errors). Then a message saying “HDB: starting”... this might take 10 minutes or so, then we get some other logs about HDB and then about starting up the Application Servers of the SAP Abap System itself.. assuming all goes well, after some minutes you should get the Great Success message, which looks like so:
BANZAI!! You can check the Podman Machine in Podman Desktop - with our container running it’s already using 60% of the memory, which is about 17 GB, quite a lot more than most containers (and when you actually start using the system, e.g. SAPGUI sessions and generating the Abap programs by tcode surfing etcetera, expect the memory usage to increase):
Add a mapping in MacBook hosts file for your container
The container is available on localhost, which already has a mapping in your MacBook’s /etc/hosts file with the line:
127.0.0.1 localhostWe leave that line in peace, definitely do not delete it as it is kinda essential! However, we can safely add a new line (with a new comment line as well) into the /etc/hosts file:
# A4H on podman:
127.0.0.1 vhcala4hci vhcala4hci.dummy.nodomainEither of these commands are useful for editing your hosts file:
sudo nano /etc/hosts
sudo pico /etc/hostsNow you can go through the sections of the blog called: Configuring the A4H System and Stopping and Starting the container - to make sure you have a valid set of licenses in SLICENSE and know how to stop and start your a4h container, etcetera.
Configuring the A4H System
Getting the licenses updated has been simplified somewhat in the Abap Platform Trial compared with its predecessor image (“Abap Trial”), there is some advice from SAP at:
https://hub.docker.com/r/sapse/abap-platform-trial
We will use SAPGUI as the method for updating the licenses. We’re not making this a tutorial on creating new Connection Items in SAPGUI for Java, but if you use the Advanced tab and check the box that allows you to enter a Connection String, then depending whether you modified the host computer’s /etc/hosts that string will be something like one of these examples (the third one is for the case when using Podman on macOS and no hosts file mapping done):
conn=/H/vhcala4hci/S/3200
conn=/H/<IP-address-of-Ubuntu-Server>/S/3200
conn=/H/localhost/S/3200Then we follow this advice from the SAP website:
“Updating the license via SAPGUI (SLICENSE) The ABAP license supplied with the Docker image lasts only three months. Therefore, you should download and import the demo license as follows:
- Logon to your ABAP system with the user SAP*, client 000, same password as for DEVELOPER (DEVELOPER , client 001, is locked).
- Start transaction SLICENSE; copy the hardware key.
- Get the license from minisap , choosing the system A4H.
- Back in your ABAP System, log off, then log on with the user DEVELOPER, client 001.
- Start SLICENSE again; remove the old invalid licenses. (sap* is not allowed to delete licenses).”
You will need to know the password for the SAP User IDs to logon - if you search down through the same SAP website you find the relevant information:
“User and Passwords
The user name is DEVELOPER. The password is:
- for ABAP Platform Trial 1909, initial shipment Htods70334
- for ABAP Platform Trial 1909, SP01 ABAPtr1909
This is also predefined (same password) for client 000, client 001: SAP* , DDIC.”
So in my case, using version 1909_SP01, ah need to pick the second of those passwords. Then it’s also helpful to know the URL for “minisap” mentioned, that is here:
https://go.support.sap.com/minisap/#/minisap
So you get the (multi-)license file downloaded, then as user SAP* in client 000, in SLICENSE tcode, upload it to the SAP System. [Step (3.) of the SAP advice above doesn’t mention you need to actually do this uploading yourself, so thought I would mention that here. Then complete Steps (4.) and (5.) from the SAP advice quoted above].
Then you can start doing SAP-level tasks like writing Abap programs (no Developer Key needed), configuring STRUST, creating new users, etcetera:
Stopping and starting the container
Stopping
The first thing to do, is log off from any SAPGUI or other sessions that you have, to avoid losing your work etcetera.
Assuming you created the container including the “--stop-time-out” parameter with reasonable value such as 3600 (seconds, i.e. up to one hour allowed for graceful shutdown), then one way to stop the container is to press Ctrl-C in the same session where you started the container.
Another way to stop the container… if you open another shell session, then the following will work just fine (either of these, as “-t” is just the abbreviated form of parameter “--time”) - these commands tell podman to stop the container “a4h” and give it an hour’s grace before issuing any hard stop:
podman stop -t 3600 a4h
podman stop --time 3600 a4hInspecting
To see stopped containers from the command line, you can use the following (need “--all” to also list non-running containers):
podman container list --allThen the command to givea you lots of detail about your container named "a4h":
podman container inspect a4hStarting
Remember campers: “podman start” starts up an already existing, but stopped, container (while the command we used earlier - “podman run” - first creates the container - magics it into existence - and then also starts it up).
So, we can (re-)start our container with the command:
podman start -ai a4h
Troubleshooting
If the “podman run” attempt fails, or other problems occur, well, unfortunately for you (but fortunately for me) neither my day job nor my free time is about providing tech-support for the SAP Community readers - so it’s really up to you to work out what went wrong and how to fix it. Anyway I would advise checking that you have enough disk space on the VM (keep around 160 GB free before spinning up a container), memory (at least 16 GB), and CPUs (4 is usually ok, 6 is usually better).
Then there is the SAP Abap Platform Trial website itself, which has various Troubleshooting hints - a useful one is to remove any failed - yet still existing - containers called “a4h” before attempting to create a new one… Removing an existing container is easily done in Podman Desktop (use the Delete icon in Containers tab), and also easy to do from the command line: first check for the existence of the target container (use “--all” parameter to list stopped containers also), and then delete it using its name (“a4h” in this case) or its Container ID:
podman container list --all
podman rm a4hOther than that, you can google for possible answers to your troubles, mostly those searches will point to various threads or blogs in the SAP Community websites (Abap Platform Trial image is not a commercial SAP Product that SAP are selling to customers, so you cannot expect SAP Support to resolve any issues). Podman is open-source, so you can find discussions about Podman-related issues on GitHub, Stack Overflow, and so on. Good luck now!
Appendix/Opinion - why a Linux VM is a good choice for Podman; plus some remarks for M-chip MacBook users
[ Feel free to skip this section..
There are two advantages IMHO of using a Linux VM for our task. One is that it’s possible to run a Linux VM on most OS variants including macOS and Windows, so this Linux VM solution is more general than an OS-specific solution such as Podman Desktop (or Docker Desktop) for macOS or Windows; further, if you have suitable software for Emulated VMs, then you can run the amd64 Linux VM on e.g. an arm64 host computer - for example, if you have an M-chip MacBook, you can probably use the UTM Emulator-Hypervisor:
https://mac.getutm.app/
See also a couple of blogs that use this approach, this one for an earlier version of Abap Platform Trial (using Docker):
https://blogs.sap.com/2021/12/16/how-to-install-abap-1909-on-mac-m1-apple-silicon/
And this one for a related mini-SAP product (not using container technology - self-promotion warning: I wrote this one):
https://blogs.sap.com/2022/03/31/qemu-and-sap-dev-edition-via-utm-for-macbook-m1/
Note that if you are going to use an emulated amd64 VM, e.g. on an M-chip MacBook, you will want to give your VM as many CPUs as you can afford (while not ruining the performance effect by slowing your host computer too badly), and also if possible give the VM more memory than recommended above - mainly because the emulation of a whole VM means the VM runs really slowly, which can mean that e.g. the "HDB start"-related processes timeout waiting for hdbdaemon, or timeout waiting on the memory needed to supply data to the processes themselves - the only remedy is to hope that with many CPUs and plenty of memory, the VM works fast enough to avoid such timeout issues. Disclaimer - at the time of writing, I don’t currently have access to an M-chip MacBook with enough memory and processing power to actually test this theory for Abap Platform Trial.
For the same “no access to suitable M-chip MacBook” reason, I haven’t considered using e.g. Podman Desktop/Engine for arm64 macOS in this blog. Unlike Docker (since summer 2023), Podman doesn’t yet have a convenient checkbox or config setting letting you use Apple Rosetta, instead Podman sticks to using its own QEMU framework, and that framework may or may not be good enough or configurable enough to run Abap Platform Trial. If someday I get hold of a usable M-chip MacBook, I’ll investigate.
The other advantage of using a Linux distro like Ubuntu, is that Podman (or Docker, etc) is always about Linux containers - even when you run Podman (or Docker, etc) on macOS or Windows, what actually happens is that a Linux VM is created and everything container-wise happens inside that Linux VM. So to me it seems quite an elegant approach to just create our own Linux VM and then run Podman (or Docker, etc) inside that VM “directly” (i.e. we don’t need a Podman Machine running on Linux, even though this could be done). ]
- SAP Managed Tags:
1 Comment