Db2 on Apple Silicon?

A Good Start

Update: September 12, 2024

After updating to MacOS Sonoma 14.6.1 this appears to be once again working!

After updating to 14.6.1 I upgraded my Homebrew packages and then followed all of the steps below once again.

brew update
brew upgrade

Update: March 2024

This capability was broken with MacOS 14.4 (and possibly even 14.3) and continues to be broken with 14.5. I’m not certain yet of the root cause but from what I’ve found from tracing Db2 and examining its error logs, I suspect the shared memory issue in the latest versions of Rosetta discussed in these two posts:

https://github.com/docker/for-mac/issues/7220

Rosetta fail on shared memory in S... | Apple Developer Forums

I recently upgraded from an older MacBook to an Apple Silicon model, an upgrade I’m quite happy about, but there is this one thing that I’ve been wanting to try…

Hopefully, maybe, someday, we’ll get a version of Db2 built natively for Apple Silicon but until then, here’s the best option I’ve found so far.

Can we use the x86_64 Db2 container?

Yes, and yes it is possible to use this on an M1/M2/etc through various translation / emulation environments. Others have described methods which leave a fair bit of performance to be desired, and all of these do come at some cost, but the goal here is to arrive at a usable alternative for the time being.

Some aspects of the method I’ll cover here are experimental, consider yourself warned, but the lure of better performance is enticing so let’s dive in.

Photo by Jen Theodore on Unsplash

Get Homebrew

In order to execute the Db2 Community Edition container on an Apple Silcon host, I’m going to use Lima — a package providing Linux on Mac.

There are other possible solutions but what caught my interest about Lima is the documentation about the (experimental) “Fast Mode 2” where you can take advantage of Apple’s Rosetta translation layer and its potential performance boost over solutions which often use a slower, QEMU based emulation.

If you already have brew available on your command line then jump ahead to the next step. If not, Homebrew in-turn requires the Xcode command line tools to get started. It’s all fairly simple so either just use Homebrew’s new MacOS .pkg installer, or install Homebrew at the command line yourself as directed on the Homebrew site, which is currently just this:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Install Podman

Next we can use brew to install Podman by simply:

brew install podman

If you don’t have brew available on your command line after installing it you may have skipped one step in the fine print, adding Homebrew to your $PATH. With the default zsh you might, for example, add this to your ~/.zshenv:

eval $(/opt/homebrew/bin/brew shellenv)

Install Lima

As the final step of setup, it’s time to install Lima:

brew install lima

Using Lima

We’re going to use a currently experimental method to execute x86_64 based containers, on an ARM VM, on your ARM (M1/M2/M3) hardware, using Rosetta (requires macOS >= 13.0) as the translation environment for the container.

Create and start the Lima instance

Create and run an instance of Lima, we’ll name podman-rootful with a default Podman template so that we can later take advantage of Podman as the container environment. Most importantly here, specify vz as the VM type and that you want to use Rosetta:

limactl create --vm-type vz --rosetta --mount-writable template://podman-rootful
limactl start podman-rootful

Follow the on-screen instructions to connect your Podman client, running natively on your Mac, with Podman inside the Linux VM, and finally just confirm that the two Podman’s are connected:

podman system connection add lima-podman-rootful "unix:///Users/$USER/.lima/podman-rootful/sock/podman.sock"
podman system connection default lima-podman-rootful

podman --remote info

By the time you read this you may be able to skip this step but once that’s complete, log in to the new Lima VM instance…

limactl shell podman-rootful

… and perform a software update to it:

sudo dnf update -y
exit

… then stop and re-start the instance to take advantage of the latest kernel:

limactl stop podman-rootful
limactl start podman-rootful

You’re there! Now get Db2

One additional change from my earlier post, about getting started with the Db2 container on a Linux host, is that this time, now with an extra VM layer between the container and the host OS, I’m going to use Podman to create a storage volume for the Db2 container:

podman volume create db2cont

podman run -it --platform linux/x86_64 \
   --hostname=db2host \
   --name db2server \
   --detach \
   --publish 50000:50000 \
   --privileged=true \
   --volume db2cont:/database \
   --env DB2INSTANCE=db2inst1 \
   --env DB2INST1_PASSWORD=admin \
   --env LICENSE=accept \
   --env DBNAME=mydb \
   icr.io/db2_community/db2

All of those options are explained in that earlier post if you’re interested. You can work with this now. To enter the container and launch a Bash shell as the Db2 instance userid:

podman exec -it db2server bash -c "su - db2inst1"

Voila! You are now executing a bash shell inside the Db2 container called db2server , executing as the Db2 instance owner (db2inst1), inside the Linux VM, on your Apple Silicon Mac!

But… there is a minor problem, a bug that still needs to be solved. Behind the scenes, the first time the container is started, scripts within the container should have been creating and configuring the database as you specified (called MYDB in this example). What you should do is watch the output logs of the container and wait until it’s ready and those scripts have finished, like this:

podman logs -f db2server

Once you see the following messages near the end of the log output, then <CTRL>+c to stop watching and it’s all yours.

(*) All databases are now active. 
(*) Setup has completed.

Unfortunately that doesn’t seem to be working but the good news is that it doesn’t need to stop you. I haven’t investigated why yet but the automatic setup scripts did not run as expected, even though the Db2 instance was created successfully. Why, and what to do about it… we’ll have to leave for another day.

From this point you can create your own database and it’s simple enough to issue commands via the Db2 command line processor (CLP). For example:

> podman exec -it db2server bash -c "su - db2inst1"
Last login: Fri Dec  1 22:37:55 UTC 2023 on pts/1

[db2inst1@db2host ~]$ db2start
12/01/2023 22:38:54     0   0   SQL1063N  DB2START processing was successful.
SQL1063N  DB2START processing was successful.

[db2inst1@db2host ~]$ db2 list db directory
SQL1057W  The system database directory is empty.  SQLSTATE=01606

[db2inst1@db2host ~]$ db2 create db mydb
DB20000I  The CREATE DATABASE command completed successfully.

[db2inst1@db2host ~]$ db2 connect to mydb

   Database Connection Information

 Database server        = DB2/LINUXX8664 11.5.9.0
 SQL authorization ID   = DB2INST1
 Local database alias   = MYDB

[db2inst1@db2host ~]$ db2 create table t1 "(c1 char(1), c2 char(1), c3 char(1))"
DB20000I  The SQL command completed successfully.

[db2inst1@db2host ~]$ db2 insert into t1 values "('I', 'B', 'M')"
DB20000I  The SQL command completed successfully.

[db2inst1@db2host ~]$ db2 select \* from t1

C1 C2 C3
-- -- --
I  B  M 

  1 record(s) selected.

[db2inst1@db2host ~]$ db2 terminate
DB20000I  The TERMINATE command completed successfully.

[db2inst1@db2host ~]$ db2stop
12/01/2023 22:49:17     0   0   SQL1064N  DB2STOP processing was successful.
SQL1064N  DB2STOP processing was successful.

Cleanup

There are just a couple of other essentials to be aware of in this environment. As always, shutting down the running container is as simple as, from outside the container on your Mac command line:

podman stop db2server

The Lima VM does consume some resources while it’s started so that can also be shut down after stopping the container:

limactl stop podman-rootful

For more info about managing the Lima VM, see https://lima-vm.io/docs/reference/limactl/ .

Enjoy!