QEMU and SAP Dev Edition via UTM for MacBook M1 (and newer M-chips)
Nowadays Apple MacBooks (and iPads) are based on the Apple M1 chip, which has an arm64 (a.k.a. aarch64) processor architecture. It seems that since 2021 Apple is phasing out its Intel-based MacBooks (i.e. those which run on amd64 (a.k.a. x86_64) processor architecture).
SAP offers two kinds of free SAP systems for use by the SAP Community. We will look at the older one of these, called SAP NetWeaver Developer Edition, which is obtainable here:
[The other free SAP system is (or rather, was) called “ABAP Trial”, delivered as a Docker image: https://hub.docker.com/_/sap-abap-trial …But currently (March 2023) this image is in “disabled” state for more than a year, so this option is not actually an option at all as things stand].
Now the SAP NetWeaver Dev Edition runs solely on amd64 architectures, and all the tutorials and blogs showing how to install it assume that the host machine and/or guest VM (Virtual Machine) has amd64 processor architecture. This blog might be the first tutorial which shows how to install and run SAP NetWeaver Dev Edition on arm64 architecture, using a technique called emulation. Specifically we will use the emulation capabilities of the excellent UTM app.
There are good tutorials offered by SAP showing how to setup SAP NetWeaver Developer Edition on an openSUSE Leap VM using e.g. VMware Workstation Player or Oracle VirtualBox, myself I used this tutorial as a reference:
If you are new to the topic, the SAP tutorial is worth reading through so you can get the main ideas of how SAP NetWeaver Dev Edition gets installed. Despite the title referring to VirtualBox, the SAP tutorial in question uses VMware Workstation Player on Windows. In this blog, we are using instead an emulator called UTM, with the host machine being an M1 MacBook.
Before we get started, the usual disclaimer: I don’t run a Helpdesk and don’t work for SAP, Apple, or UTM, so you might well need BYODS (Bring Your Own Debugging Skills) if things get tricky. However if you see any mistakes in the explanations of this blog, feel free to propose improvements via the Comments section, I will look at those. And with that, let’s get started…
UTM – a Hypervisor-Emulator
Although it is possible to try using Apple’s implementation of QEMU yourself, that can get quite complicated. (It’s sometimes possible to use QEMU to start scripts and preface function calls etc, e.g. using “qemu-x86_64” commands… but this would be a lot of work, and maybe not even possible for calls inside already compiled C/C++ code such as the SAP installation media contains). Luckily for M1 MacBook users, there is a product called UTM which does pretty much all the hard work of emulation on our behalf, so that we can run an OS itself in emulated mode, and then trust the OS<->QEMU communications to work out. Here is the UTM website for their Hypervisor-Emulator:
As the UTM people say in their product description:
“Under the hood of UTM is QEMU, a decades old, free and open source emulation software that is widely used and actively maintained. While QEMU is powerful, it can be difficult to set up and configure with its plethora of command line options and flags. UTM is designed to give users the flexibility of QEMU without the steep learning curve that comes with it.”
Worth reading the manual also:
Up to you if you use the free version downloadable .dmg from the website, or the non-free version available in the App Store…only difference is App Store version offers automatic updates – happy to support open-source development so I got the App Store version . In any case, you install UTM using one of these paths. [It might be you need Administrator rights to your MacBook in order for UTM to be set up, I cannot remember now. If so, then if it is your own home MacBook, no problem; if it belongs to some other entity e.g. an organisation you work for, then you might need to ask for Administrator rights].
Install emulated amd64 openSUSE Leap 15 VM
Next thing we need is an openSUSE Leap 15 distro for the x86_64 (amd64) architecture. Although other Linux distros are also usable, openSUSE is convenient as it is the Linux distro that SAP themselves use when building and testing SAP NetWeaver Dev Edition; also, the installation runs quicker on openSUSE than on e.g. Ubuntu.
You can get the .iso file needed from:
Choose Leap, choose Download of the latest stable release (15.3 in March 2022, might be different by the time you read this), and choose the x86_64 architecture and offline ISO:
[Update January 2023: If you are using a version of Leap 15.4 or later, then you might well need to consult this other blog I wrote, about adjustments for getting a higher kernel version of Linux to work well wrt. SAP Dev Edition installation:
Note that although SUSE are offering Leap on arm64 architecture – and I have tested that such a version runs fine on the UTM Hypervisor (well, you might want to choose Console Only during the install phase, and then switch to Full Graphics mode after installation) – still the thing is, that we need the x86_64 version, because that is the only architecture the SAP NetWeaver Dev Edition runs on at the time of writing. So, download the x86_64 Offline Image .iso file.
Open the UTM app. Choose the ‘+’-button to start creating a VM. Choose Emulate -> Linux -> Boot ISO image -> Browse … import your .iso for openSUSE x86_64:
Click forwards to the Hardware section. We keep the Architecture to be the suggested x86_64, and I kept the suggested System “PC” as I assume it is suitable. Increase the RAM to 8192 MB, and I suggest increasing the number of cores to 4:
For Storage, although the SAP tutorial recommends 100GB of hard disk storage, I put 120GB as enough space on the host. Skip past the Shared Directory screen, we will use the scp command to move stuff from host machine to guest VM. Give your VM a name, for example “opensuse-leap-15-amd-01” and Save the VM to create it.
Edit the Settings – right-click on the VM in the left-hand menu and choose “Edit..”. Note that you can only go to the Settings when the VM is not up and running.
In the Settings, under Display section, change Emulated Display Card to “bochs-display” and uncheck “Resize display to windows size automatically” (as openSUSE does not have such guest agent tools available in March 2022). And Save. The bochs-display is good because it allows display of the UTM-Console for the “tty”, in addition to the traditional SSH access to server VMs.
If you like, you can change the Interface Type of the main drive (the one called “data.qcow2”, not the CD/DVD drive) to a “newer” type, for example I chose “NVMe” instead of “IDE”. Although in real life, NVMe (around since 2011) is much more modern than IDE (ATA) (around since the 1980s), however here we are dealing with software representations not actual hardware, so I didn’t notice any performance difference between drives depending on their (virtual) Interface Type.
I decided that it is easier to let UTM provide the VM with an IPv4 address on its default NAT network (called “Shared Network” in the Settings), which in my case is 192.168.64.0/24, as this is nice and easy for the installation of OS phase. Later we will reconfigure the VM from inside openSUSE, to use a static IP. So for now, no UTM Settings for Networking should be changed. [BTW I’m assuming that your host machine has an Internet connection, that’s convenient so that we can ensure we get all the stuff we need from online repos and that the packages can be kept up to date. Maybe the exercise can be done without any Internet connection, but I haven’t tested that].
Now we press the Play-icon to start the VM. It should find the installer DVD (the .iso file) and then you choose “Installation”.
The warmup is quite slow, so be patient.
Choose your keyboard layout. I suggest keeping the language as English (US) since unfortunately they do not offer English (SCO) as an option, and also because diverging from the default language could have negative consequences later (we will need to ensure that in localectl we have the right LANG setting and so on). So that’s why I recommend keeping the default language.
Say “yes” to Online repos and choose the ones you like, I kept the default suggestions. IMHO it’s good practice to keep the packages up to date.
Next we will choose for System Role “Server”. Although I like the various GUI Desktop variants, for our use case, where due to emulation the VM runs slower, then we want to minimise the effects on performance that a Desktop GUI brings. So “Server” it is.
The disk layout proposal that the Installer makes, will use Btrfs for the largest partition. We need to change that for installing SAP later. So choose Expert Partitioner -> Current Proposal, find the largest partition (which may be sda2), and press Edit..
Change partition to Ext4:
Choose your time zone. I usually go to Other Settings and Synchronise Now, just to be sure that the time is right and the config gets saved.
Then create a user, and password, and make sure “Use this password for system administrator” is checked (just more convenient).
Summary screen.. Remember to set/check: Firewall to disabled, SSH service to enabled. Although usually (in real life situations) we would keep the FIrewall enabled, still for the installation of SAP later it might be better to leave the firewall disabled on our toy VM, so that when the SAP installer is testing for its favourite ports, those are open. Up to you. If setting Firewall enabled, later you need to open at least port 3200 in the Firewall (potentially also ports 3300, 44300, 8000 depending on whether you intend to use RFCs, Fiori, Webgui etc), not difficult but not shown in this blog either; also for Firewall enablers, in this Summary screen make sure that the SSH port is set to open, as SSH access is very useful, especially if you need to e.g. copy-paste logs from install and so on.
Optionally, you can also go to the Booting section from Summary screen, and in Kernel Parameters remove the option “quiet” that is provided as default:
So I like to see that if something is happening, stdout is showing something, as those seconds or minutes of blank screen always worry me “is something broken?”. By removing the “quiet” option, you get more screen output. Up to you.
So back at the Summary screen, from there you can start the Installation proper… this might take about an hour, or more… the Installer gives you some “time remaining estimates”, usually at the start they are overestimates, so for this case it took about 45 minutes… [Update March 2023: 30 minutes, with 8 cores and 12GB RAM]…
Once the installation is done, you reboot the VM from the popup prompt. After rebooting, the option “Boot from hard disk” should be available. Choose that. If you switched “quiet” off from Kernel Parameters, you see something like this:
Then you get some kind of “loading console” screen:
… and finally, the login console appears:
So now you can login using the user you created during the installation process.
It’s better for servers to have static IPs; even though in practice Hypervisors tend to re-assign the same DHCP address to the same DHCP clients as a rule of thumb, still this is not the same certainty as static IP provides.
Since (for my UTM installation) the DHCP starts with 192.168.64.2 and counts upwards, our static IPs can be in the same 192.168.64.0/24 subnet, and we can define them, say, starting with 192.168.64.151 and counting upwards. But before we assign a static IP address, let’s find out what are the addresses of the default gateway and of the DNS server on the UTM “Shared Network”.
[Note: if you are using Bridged Networking, so that your VM gets its main IP address from e.g. the Router in your home, then it is better not to configure a static IP inside the VM as shown below, instead you can login to your Router as admin, and reserve an IP address for the VM, typically using the VM’s MAC address as identifier (use “ip link” to see the MAC address), though other Routers may recognise the hostname also. Home wi-fi routers can get confused if a VM “inside” an existing node on its network, advertises to the wi-fi router that it demands such and such a static IP, so that i why I used the workaround of direct Router admin config].
So to find the default gateway, for that we use:
So it’s 192.168.64.1 in our case (which is also by the way the MacBook host machine’s address on the UTM-network).
To find the DNS server, let’s just do a dig of some actual internet address, any old one will do:
So there you go, the DNS server is also in effect the host machine, at 192.168.64.1
Now we can do some reconfiguring of our network settings. The tool we need here is called Yast..
System -> Network Settings -> Overview.
Tab down to Edit then <Enter>, or use <option>+’i’, to enter Network Card Setup:
By checking the “Statically Assigned IP Address”-radiobutton we thereby also uncheck the “Dynamic Address”-radiobutton. Then specify the Static IPv4 Address and the Subnet Mask.
IP Address: 192.168.64.151
Subnet Mask: /24
Hostname: I suggest keeping this particular field empty:
“Optionally, you can enter a fully qualified Hostname for this address, which will be written to the /etc/hosts configuration file.”
[If you decide to fill in this Network Card Setup -> Hostname field, then later when manually modifying /etc/hosts, use the automatically created line for the static IP and just add the FQDN to it].
So anyway, we have:
Then “Next” returns us to the Overview tab. Move to the Hostname/DNS tab and here we set
Static Hostname: vhcalnplci
Set Hostname via DHCP: no
Main DNS server (Name Server 1):192.168.64.1
Optionally we can set auxiliary DNS servers, e.g. I set Name Server 2 to be Google DNS server 220.127.116.11 as a backup, just in case:
Now move to the Routing tab. We see there are no routes statically added as yet, so press Add, then since it is the first route to be added, the “Default route” checkbox should be pre-checked on, if not then check it to be on. Add the default gateway IP to “Gateway”, no need to limit by Device as it applies to all NICs. Then OK:
Then OK to save the settings. And after that quit Yast.
Next thing to do is modify hosts file, so that it contains a line mapping the static IP address to vhcalnplci and to the fully qualified hostname vhcalnplci.dummy.nodomain – so, using our favourite text editor, which is nano:
sudo nano /etc/hosts
Add the line (or modify any existing line beginning with the static IP) to get:
192.168.64.151 vhcalnplci vhcalnplci.dummy.nodomain
Ctrl+O, Ctrl+X to save and quit.
There are less dramatic ways maybe to get the VM to start using the new Network Settings, but since this is our own toy VM so we can just reboot the VM and see if everything works out as planned… First we can shutdown:
sudo shutdown -h now
… and then in VM Settings add the networking info to the Notes, and Save.
Also in Settings, you might want to move the CD/DVD Drive down to 3rd place in the order of drives (careful – after “Move Down” from top rack, the first button changes to “Move Up” and the “Move Down” button moves to the right) – so doing this then puts the main hard drive at the top of the drive order, and it is this ordering which determines the order the VM looks for drives when booting up. And Save.
Now let’s boot up the VM, and check that our network config changes worked…
One more check, can we ssh into the VM from MacBook:
Yep, all good. Now a detour to get some installation media from SAP…
Get the SAP installation media and unrar
So the installation media is currently here:
You need to login to download stuff, so for that you need a so-called P-user, which is like an SAP Community ID for Private individuals (i.e. not linked to an SAP Customer or Partner number as the S-users are) – go to https://account.sap.com and register there for a P-user.
It’s a bit time-consuming as those are large .rar files mostly, and each one has a popup to confirm window. Make sure also to download the license.rar file.
I recommend unrarring on the MacBook. So for that, you need The Unarchiver:
Freeware, and very good as well. So then you right-click on part1 and Open with.. The Unarchiver, then it unrars all the parts and you get the installation directory with all files and subdirectories.
Also you should unrar the license.rar, and check if it is still valid from the info.txt file that comes with it. (Though in 2022 there was still a typo in the license header-comment and in the info.txt file – in April 2022, the license is still valid until 31.03.2023, i.e. in the future from time of writing, not in the past as the info.txt file claims).
So if the license is valid, rename it to SYBASE_ASE_TD.lic – but, unlike what the info.txt says (as you cannot put it into a directory that doesn’t even exist yet) instead do as follows: copy and paste the SYBASE_ASE_TD.lic to subdirectory TD752SP04/server/TAR/x86_64/ (where TD752SP04 is the top directory of the unrarred files).
More VM preparation
Ok, back in the VM install some things, First maybe refresh and update
sudo zypper refresh
sudo zypper update
We need uuidd for SAP installation:
sudo zypper in uuidd
Something we need to remember after each reboot (until installation of SAP Dev Edition is done), before running the install.sh script, is:
sudo systemctl start uuidd
And check it is running:
sudo systemctl status uuidd
sudo service –status-all | grep uuidd
Check which libaio is installed:
rpm -qa | grep libaio
So libaio1 was found, Though to be on the safe side we can install it anyway (if already there and latest version it wouldn’t be reinstalled). Also we will need csh (the SAP <sid>adm user uses csh) so nowadays that works by installing tcsh (which csh is symbolically linked to; actually csh as link and tcsh binary itself are already pre-installed)..
sudo zypper in libaio1 tcsh
Ok, highest available versions of those had already been installed.
Check the hostname:
If the static hostname is not vhcalnplci, then we can set it to be so:
sudo hostnamectl set-hostname vhcalnplci
Since I already extracted (unrarred using The Unarchiver app) on MacBook, so it’s convenient to just scp all those files from host directory TD752SP04 into the openSUSE VM and create a new directory /home/marmot/TD752SP04 to contain all the stuff:
scp -r ./TD752SP04 firstname.lastname@example.org:/home/marmot/TD752SP04
(Using the “-r” flag ensures recursive content-transfer through the subdirectories etc).
We can use the excellent utility called tree to check we got the stuff across ok, enough to check, say, three levels down (“-L 3”):
sudo zypper in tree
tree -L 3 TD752SP04/
Let’s check the kernel version, so we can know if we need to follow the advice in my blog for kernels of 5.4.x or higher:
Ok we have 5.3.18-150300.59.54-default, which is less than 5.4.x, so we don’t need to adjust our installer bash script.
UPDATE: March 2023: newer releases of openSUSE have a higher kernel version, so you will need to follow the script-change advice of the other blog – here is a shortcut to the Appendix, just follow the copy-paste-replace advice using the snippet:
We also need to check from localectl that LANG=en_US.UTF-8
If not, we can set it:
sudo localectl set-locale LANG=en_US.UTF-8
We need to set the install.sh file to executable:
chmod +x install.sh
Should now be executable.
[At this point we may want to take a snapshot of our VM, in case the installation goes badly. Actually UTM doesn’t seem to have snapshots… but we could clone the VM. If you don’t want to be bothered with making clones, then if an install.sh run fails, you can do an easy “reset” by deleting all the relevant installed material of the failed run:
sudo rm -rf /sapmnt /sybase /usr/sap
After that you can then do a new install.sh run].
Remember to check the status of the uuidd service:
sudo systemctl status uuidd
To start the service if needed:
sudo systemctl start uuidd
Then become the root user:
Move to the directory containing install.sh:
Start the installation script:
ESC-key and/or hit ‘q’ a couple of times, or if that fails try Ctrl+C, to stop reading all the stuff (or scroll through all 167 lines), then when asked you need to accept the license by typing:
Then you need to define what will become the password of the npladm OS user, so create some good password and enter it twice as prompted. Then the installation of the SAP system begins… it took about 45 minutes in my tests… if the installation fails, there will be error messages directing you to check the logs. In that case good luck with debugging and config changes; if the installation succeeds, you will see something like this:
Checking syb Database
Database is running
Starting Startup Agent sapstartsrv
Instance Service on host vhcalnplci started
starting SAP Instance ASCS01
Startup-Log is written to /home/npladm/startsap_ASCS01.log
/usr/sap/NPL/ASCS01/exe/sapcontrol -prot NI_HTTP -nr 01 -function Start
Instance on host vhcalnplci started
Starting Startup Agent sapstartsrv
Instance Service on host vhcalnplci started
starting SAP Instance D00
Startup-Log is written to /home/npladm/startsap_D00.log
/usr/sap/NPL/D00/exe/sapcontrol -prot NI_HTTP -nr 00 -function Start
Instance on host vhcalnplci started
Installation of NPL successful
So there we have it, that’s an x86_64 emulated SAP system installed (and running) on an M1 arm64 host machine.
Let’s do some checks… since the SAP system has SID “NPL”, so the main OS user is called npladm, we need to become that user to do npl-admin stuff…
marmot@vhcalnplci:~> su -l npladm
vhcalnplci:npladm 2> sapcontrol -nr 00 -function GetProcessList
name, description, dispstatus, textstatus, starttime, elapsedtime, pid
disp+work, Dispatcher, GREEN, Running, 2022 03 30 21:53:35, 0:05:22, 789
igswd_mt, IGS Watchdog, GREEN, Running, 2022 03 30 21:53:35, 0:05:22, 790
gwrd, Gateway, GREEN, Running, 2022 03 30 21:53:38, 0:05:19, 894
icman, ICM, GREEN, Running, 2022 03 30 21:53:38, 0:05:19, 895
SAPGUI Logon to NPL and get License Key
To get much use out of SAP NetWeaver Dev Edition, you will need a SAPGUI client. Check the SAP Community pages for advice on getting those… the unrarred directory itself has SAPGUI client installation media for Windows, MacBook, and Linux, though at least for MacBook the offered client is a bit out of date. But good luck if you want to try and install that one. Alternatively MacBook users could check the long rambling advice of one blog I wrote about the topic:
If/when you have a working SAPGUI client for MacBook, next step is to set up a new Connection Item, using the IPv4 address and the knowledge that since the main AS instance has instance-number 00, so the SAPGUI port is 3200 i.e. 32nn, where nn=instance-number:
[If you have openSUSE Firewall enabled, then remember you need to explicitly allow the port 3200 to be open, e.g. using Yast].
Then logon to SAP – follow the SAP instructions, using client 000, user SAP* and provided password (see readme.html in TD752SP04 directory for up to date passwords).
In the tcode box near the top-left of the screen, enter the tcode SLICENSE and hit <Enter>. From there you can copy the Hardware Key. Then go to:
Scroll to find: “NPL – SAP NetWeaver 7.x (Sybase ASE)” line and check the radiobutton. Scroll down to section “Personal Data & Info”, enter relevant data including Hardware Key, check the box agreeing to License Agreement, then press “Generate”, to download the license as a text file to your local machine, probably it is called “NPL.txt”.
Then back in your SAPGUI screen, first delete any existing temporary licenses (important for some reason to do this step before installing a new license). Highlight license, Edit -> Delete license.
The order matters… first delete the 2 temporary licenses, and only then install the permanent (well, valid for 3 months) license you got from the website. Once those are deleted, go to Edit -> Install License. You might need to go up to nearer the root folder then descend again to get to your Downloads folder where the NPL.txt license sits. (When uploading (“Install License”) the license file NPL.txt, you might need to give SAPGUI the right to access some folder(s)).
Then you can log off as the SAP* user from SAP (the SAP* user is only for “special activities”).
Developer-user can now logon…
Now logon to client 001, as user DEVELOPER; the list of SAP userIDs and their default passwords is in “readme.html” in the installation directory TD752SP04:
So yes, here we are then, logged on to SAP, which thinks it is running on x86_64 architecture, though we know it is actually being powered by the host M1 MacBook:
We can make the obligatory – well, optional, gratuitous – custom Abap program to remind ourselves that once upon a time we too knew how to program computers… tcode is SE38 or /nSE38 if you are away from the landing screen. Not going to show here how to create and write an Abap program, but anyway here is ZTESTMARMOT001 as source code and at runtime:
Well maybe it’s not the best code ever, essentially half of it can never be executed, but the point is you can do most Abap and Basis activities and experiments using this SAP NetWeaver Dev Edition.
Now we can log off SAP. Then as the OS npladm user we can shutdown the SAP system:
Once the SAP system has shut down, you can drop out of npladm to being plain old marmot paws again:
And then you can shut the VM down using sudo powers as normal
sudo shutdown -h now
Next time you need to use NPL…boot the VM; login as marmot; become npladm; start NPL:
su -l npladm
Might take about five minutes or so to be properly up and running.
To check all the important SAP processes are healthy, use (as npladm):
sapcontrol -nr 00 -function GetProcessList
If they don’t all look right, e.g. couple of YELLOW status processes, try waiting for a minute or two and checking again.
If that still doesn’t work, try stopping SAP and then starting SAP again
When all the SAP processes are in GREEN status, you can logon to NPL via SAPGUI.
Thanks for this, looks great.
And I apologise: I used the wrong cover sheet for the guide.
Just for everyone's reference, there are two. The texts refer to VMWare and Oracle Virtual Box; just the cover sheet is wrong:
I'll fix the cover sheet asap.
Thanks and best wishes,
Those guides of yours are very good, I have often relied on them for reference (as I cannot always remember all the steps I did myself after a few weeks).
Always good to know, thanks.
I've updated the cover sheet. Thanks for letting me know.
Good work! Very helpful. Many Thanks
That helped me to overcome the issue "Assertion failed: Unable to gnerate a new password for databse login 'sa' ... " by renaming and copying SYBASE_ASE_TD.lic in /server/TAR/x86_64/ .
could you please see this problem? Any point for us?
I wrote my "armchair analysis" and a possible (though untested) solution to your issue, as an answer to that linked thread just now. Got many other things to do for the next few months so I'm not intending to actually try and install HANA Express on an M1 Mac myself, but good luck with it.
Not sure if this could be the problem to your solution. But I was able to install Hana express edition using the processor flag setup from this blog post.
which flag do you mean?
Or it could be simpler (guessing...) that Albat just needs to choose "Emulate" instead of "Virtualise" when creating a new VM... difficult to say as no detailed description of what was done to get the error but to me it looks like the solution is mostly about choosing to emulate x86_64 architecture for the VM, thus avoiding the error where HANA installer realises that a VM needs to have sse4.2 which is an x86_64 thing.
So in UTM, from "Create a VM" you get to the following popup, where you should choose "Emulate":
...which as it says on the tin, is slower but allows you to run VMs with architectures that are not the same as the host (M1 is an arm64 chip).
Thank you so much. It works for me. I am able to install ABAP dev in M2 with UTM. Used Suse leap 15.4 and followed your script modification blog. It worked wonderfully.
Good to hear the blog's advice also works for installing on an M2 machine.
Decided to add a brief update to this blog based on your comment about using Leap 15.4 (basically, linking to the script modification blog).