Does not work on Mac M1

[meyntony]

docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=<YourStrongPassw0rd#4b4b5c9e-cec8-49c1-8b50-a59e47ba4c63>" -p 56038:1433 --name umbracocloud-local-dev-sql-Modular-56038 -h Modular.umbracocloud-local-dev-sql -d mcr.microsoft.com/mssql/server:2019-latest
docker exec -it umbracocloud-local-dev-sql-Modular-56038 /opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P "<YourStrongPassw0rd#4b4b5c9e-cec8-49c1-8b50-a59e47ba4c63>" -Q "CREATE DATABASE LocalDevUmbracoCloudModular"

The above code works fine on Windows, Ubuntu, Mac with Intel Chip, but not on Mac with the M1 chip.

Is this a known issue?

[iOvergaard]

I am trying out the commands that @meyntony wrote on an M1 Pro (arm64) processor and getting the following warning when spinning up the container:

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

I figure this explains why it would or could give problems.

A possible workaround, following this guide, suggests to use the image mcr.microsoft.com/azure-sql-edge instead which seemingly works on the arm64 arch pretty much by changing the image name and adding some Linux capabilities:

docker run --cap-add SYS_PTRACE -e 'ACCEPT_EULA=1' -e 'MSSQL_SA_PASSWORD=P@ssw0rd' -p 1433:1433 --name sqledge -d mcr.microsoft.com/azure-sql-edge

In terms of running the sqlcmd command afterwards, I am not sure how to do that as it looks like the command resides in another place and I have not looked much into it.

Even so, I am able to connect to the database server using Azure Data Studio (which works on Apple Silicon even though it's not officially supported) and create new databases.

[rjschave]

@iOvergaard,

The sqlcmd utility is not included in the ARM64 version of the SQL Edge container. I pulled another image that contains sqlcmd.

Retreive image w/ sqlcmd tools:
docker pull mcr.microsoft.com/mssql-tools

Assuming the SQL Edge container is running on the same machine and bound to the default port of 1433, you could try something like this:
docker run -it -d --platform linux/amd64 mcr.microsoft.com/mssql-tools /opt/mssql-tools/bin/sqlcmd -S host.docker.internal -U <user_name> -P '<password>' -Q 'SELECT * FROM a_table'

[iOvergaard]

Nice one, @rjschave. Thanks for the info!

[roboticflamingo]

Please add aarch64 and arm64 support (necessary if one is using docker on M1 mac).

[sshquack]

More people are running into this issue and using azure sql edge as a workaround.

Please add support for ARM64 / Apple silicon / M1 to MS SQL Server docker image.

[eriklumme]

👍 'ed this issue. I'm using Azure SQL Edge as a workaround, but the lack of CLR support is an issue, as the database I'm working with uses the FORMAT function heavily.

[xahanix]

M1 support is needed urgently

[disolino]

Since Azure SQL Edge does not support all the features of SQL Server its not an appropriate alternative for everyone. I would highly appreciate if Microsoft would support the M1 soon.

[Justinio99]

If there is no support for MSSQL we as a company will look into other solutions! To me thats a must have.

[mathibla]

M1 support is needed urgently

[Dihenry06]

M1 support is needed urgently

[claresloggett]

This is pretty major, we've just had our dev machines upgraded, and the new Macs mean we are now on M1 chips and cannot develop with MS SQL. I'd assume it will become an issue for more and more people as the old machines age out.

[coolwuu]

M1 support is needed urgently

[coolwuu]

M1 support is needed urgently

[louisektw]

M1 support is needed urgently

[sirmahyar]

M1 support is needed urgently

[tracker1]

I would suggest reducing the "me too" comments and simply thumbs up on the primary post at the top.

I'm not working for MS, but would be surprised if this sees any attention in the near term. Mostly because M1 isn't really a server target for MS SQL Server. And the "edge" version is where any effort for ARM is going. You may be best off requesting better feature parity for that release.

I would also suggest considering PostgreSQL as well, depending on how difficult porting would be for you, but you may run in to similar issues with specific use cases locally. Having gone through several painful database platform migrations in the early 00's it is emphatically not fun and I don't recommend it.

An alternative might be a cloud hosted instance with each dev working on a separate database or sets of databases... not as clean as a fresh docker image, but at least something to move forward. Again, depends on your need/load.

[SuperFola]

There is the solution of running the container inside a VM, such as colima which can interface with docker pretty easily. However, even if the container spins to life for me, is reachable and all, liquibase will take a very long time to send the changelog and SQL commands to the container. What takes a few minutes (even seconds) on a Mac Intel takes forever with colima + Mac M1 somehow. If it spins to life, it will (most of the time for me) crash before sending everything, saying that the change log lock couldn't be acquired. Still investigating.

For those wanting to try this out, I'm using colima start --arch amd --cpu 5 -memory 5 --dns 8.8.8.8 on a Mac M1 Pro. If you have any certificate problem when trying to pull images, this helped me getting it to work: https://stackoverflow.com/a/55260438/13157652.

[yk-jemmic]

M1 support is needed urgently!!!

[sadbuttrue1]

M1 support is needed urgently!!!

[SuperFola]

Please leave thumbs up on the relevant messages instead of polluting the thread and not bringing anything.

[Meligy]

Sorry for spamming, I just want to say that while workaround like colima exist, they have issues. Some are obvious (the degradation of performance emulating x86), some are not so (the emulation, being a hack it can break eventually, like abiosoft/colima#288).

[JohannesHoppe]

Bumping this for visibility.

We pay a ton of money for our Azure and I expect Microsoft to fix a problem on time, only once please. But as usual, disappointment all the way.

[JohannesHoppe]

FYI. You can find some workarounds here, but the whole situation is still just pathetic:
#668 (comment) or here #668 (comment)

[teodoramiteva]

M1 support is needed urgently

[SuperFola]

M1 support is needed urgently

There is a solution, see #734 (comment).

I got it to work correctly by starting only sqlserver inside Colima, and all of my other containers inside Docker Desktop, just by switching the current docker context, pretty easy to do.

[roman-levenets]

@SuperFola could you please share with the example of switching Docker contexts? I want to run my docker compose with SQL server under Colima and other Docker instances as usual under ARM virtualization. Thank you

[darrinholst]

@SuperFola could you please share with the example of switching Docker contexts? I want to run my docker compose with SQL server under Colima and other Docker instances as usual under ARM virtualization. Thank you

DOCKER_CONTEXT=colima docker compose up

It does work, but it's miserably slow. I switched to using an ec2 instance as a remote docker host.

[overengineeredit]

I tried the suggest steps to use colima with container mcr.microsoft.com/mssql/server:2017-latest to no effect. Am still getting the same error as the initially noted one:

/opt/mssql/bin/sqlservr: Invalid mapping of address 0x40094e5000 in reserved address space below 0x400000000000. Possible causes:
1) the process (itself, or via a wrapper) starts-up its own running environment sets the stack size limit to unlimited via syscall setrlimit(2);
2) the process (itself, or via a wrapper) adjusts its own execution domain and flag the system its legacy personality via syscall personality(2);
3) sysadmin deliberately sets the system to run on legacy VA layout mode by adjusting a sysctl knob vm.legacy_va_layout.```

[invaderb]

I tried the suggest steps to use colima with container mcr.microsoft.com/mssql/server:2017-latest to no effect. Am still getting the same error as the initially noted one:

/opt/mssql/bin/sqlservr: Invalid mapping of address 0x40094e5000 in reserved address space below 0x400000000000. Possible causes:

1) the process (itself, or via a wrapper) starts-up its own running environment sets the stack size limit to unlimited via syscall setrlimit(2);

2) the process (itself, or via a wrapper) adjusts its own execution domain and flag the system its legacy personality via syscall personality(2);

3) sysadmin deliberately sets the system to run on legacy VA layout mode by adjusting a sysctl knob vm.legacy_va_layout.```

are you sure your using the Colima runtime?

run "docker context list" and see what it's set too

[sinfergit]

I tried the suggest steps to use colima with container mcr.microsoft.com/mssql/server:2017-latest to no effect. Am still getting the same error as the initially noted one:

/opt/mssql/bin/sqlservr: Invalid mapping of address 0x40094e5000 in reserved address space below 0x400000000000. Possible causes:

1) the process (itself, or via a wrapper) starts-up its own running environment sets the stack size limit to unlimited via syscall setrlimit(2);

2) the process (itself, or via a wrapper) adjusts its own execution domain and flag the system its legacy personality via syscall personality(2);

3) sysadmin deliberately sets the system to run on legacy VA layout mode by adjusting a sysctl knob vm.legacy_va_layout.```

are you sure your using the Colima runtime?

run "docker context list" and see what it's set too

I got the same issue and checked the docker context as in the below image. Colima has been selected as it should be.

Any idea as to what could be the reason?

[darrinholst]

I tried the suggest steps to use colima with container mcr.microsoft.com/mssql/server:2017-latest to no effect. Am still getting the same error as the initially noted one:

/opt/mssql/bin/sqlservr: Invalid mapping of address 0x40094e5000 in reserved address space below 0x400000000000. Possible causes:

1) the process (itself, or via a wrapper) starts-up its own running environment sets the stack size limit to unlimited via syscall setrlimit(2);

2) the process (itself, or via a wrapper) adjusts its own execution domain and flag the system its legacy personality via syscall personality(2);

3) sysadmin deliberately sets the system to run on legacy VA layout mode by adjusting a sysctl knob vm.legacy_va_layout.```

are you sure your using the Colima runtime?
run "docker context list" and see what it's set too

I got the same issue and checked the docker context as in the below image. Colima has been selected as it should be.

Any idea as to what could be the reason?

Run colima status to make sure it’s using the new virtualization framework and not qemu still.

[sinfergit]

I tried the suggest steps to use colima with container mcr.microsoft.com/mssql/server:2017-latest to no effect. Am still getting the same error as the initially noted one:

/opt/mssql/bin/sqlservr: Invalid mapping of address 0x40094e5000 in reserved address space below 0x400000000000. Possible causes:

1) the process (itself, or via a wrapper) starts-up its own running environment sets the stack size limit to unlimited via syscall setrlimit(2);

2) the process (itself, or via a wrapper) adjusts its own execution domain and flag the system its legacy personality via syscall personality(2);

3) sysadmin deliberately sets the system to run on legacy VA layout mode by adjusting a sysctl knob vm.legacy_va_layout.```

are you sure your using the Colima runtime?
run "docker context list" and see what it's set too

I got the same issue and checked the docker context as in the below image. Colima has been selected as it should be.
Any idea as to what could be the reason?

Run colima status to make sure it’s using the new virtualization framework and not qemu still.

For some reason when I ran colima status it gives me an error saying FATA[0000] colima is not running but when I run the command to start Colima it runs without any issue.
Also I noticed that vmType in Colima Template was as qemu and I manually changed it to vz but still the same error occurs

[invaderb]

@sinfergit @darrinholst did you get any errors when you installed it? I'd suggest clearing everything out and re-installing lima and colima by following the steps above it sounds like something is borked.

[sinfergit]

@sinfergit @darrinholst did you get any errors when you installed it? I'd suggest clearing everything out and re-installing lima and colima by following the steps above it sounds like something is borked.

The only error I got running the script is from here error: pathspec 'support-vz' did not match any file(s) known to git
And when I checked there is no such branch in Colima Git repository and I checked out to main branch.

Did everything from the scratch again and now getting the following error about the colima driver.

[darrinholst]

You shouldn't have to build anything from source anymore. Here is what I just did to clean and reinstall...

brew uninstall --force colima lima
rm -rf ~/.colima ~/.lima
brew install colima
colima template

Change vmType to vz and mountType to virtiofs. I also adjust CPU, disk, and memory here so I don't have to add them to the start command.

colima start
colima status

INFO[0000] colima is running using macOS Virtualization.Framework
INFO[0000] arch: aarch64
INFO[0000] runtime: docker
INFO[0000] mountType: virtiofs
INFO[0000] socket: unix:///Users/darrinholst/.colima/default/docker.sock

docker run --rm -e ACCEPT_EULA=Y mcr.microsoft.com/mssql/server:2019-CU18-ubuntu-20.04

2022-12-31 13:47:53.57 spid24s     Server is listening on [ 'any' <ipv6> 1433].
2022-12-31 13:47:53.58 spid24s     Server is listening on [ 'any' <ipv4> 1433].
2022-12-31 13:47:53.59 Server      Server is listening on [ ::1 <ipv6> 1434].
2022-12-31 13:47:53.59 Server      Server is listening on [ 127.0.0.1 <ipv4> 1434].
2022-12-31 13:47:53.59 Server      Dedicated admin connection support was established for listening locally on port 1434.
2022-12-31 13:47:53.59 spid24s     Server is listening on [ ::1 <ipv6> 1431].
2022-12-31 13:47:53.59 spid24s     Server is listening on [ 127.0.0.1 <ipv4> 1431].
2022-12-31 13:47:53.60 spid24s     SQL Server is now ready for client connections. This is an informational message; no user action is required.

[sinfergit]

You shouldn't have to build anything from source anymore. Here is what I just did to clean and reinstall...

brew uninstall --force colima lima
rm -rf ~/.colima ~/.lima
brew install colima
colima template

Change vmType to vz and mountType to virtiofs. I also adjust CPU, disk, and memory here so I don't have to add them to the start command.

colima start
colima status

INFO[0000] colima is running using macOS Virtualization.Framework
INFO[0000] arch: aarch64
INFO[0000] runtime: docker
INFO[0000] mountType: virtiofs
INFO[0000] socket: unix:///Users/darrinholst/.colima/default/docker.sock

docker run --rm -e ACCEPT_EULA=Y mcr.microsoft.com/mssql/server:2019-CU18-ubuntu-20.04

2022-12-31 13:47:53.57 spid24s     Server is listening on [ 'any' <ipv6> 1433].
2022-12-31 13:47:53.58 spid24s     Server is listening on [ 'any' <ipv4> 1433].
2022-12-31 13:47:53.59 Server      Server is listening on [ ::1 <ipv6> 1434].
2022-12-31 13:47:53.59 Server      Server is listening on [ 127.0.0.1 <ipv4> 1434].
2022-12-31 13:47:53.59 Server      Dedicated admin connection support was established for listening locally on port 1434.
2022-12-31 13:47:53.59 spid24s     Server is listening on [ ::1 <ipv6> 1431].
2022-12-31 13:47:53.59 spid24s     Server is listening on [ 127.0.0.1 <ipv4> 1431].
2022-12-31 13:47:53.60 spid24s     SQL Server is now ready for client connections. This is an informational message; no user action is required.

Thanks a lot @darrinholst now it works. So what was missing was the mountType to be updated to virtiofs.
Thanks for you time 👍

[Meligy]

What's the point of changing Colima defaults for SQL Server? I have been running it successfully for a year without changing anything.

Is it faster or anything?

I also don't share volumes with the host. Is that what's broken by the defaults?

[invaderb]

What's the point of changing Colima defaults for SQL Server? I have been running it successfully for a year without changing anything.

Is it faster or anything?

I also don't share volumes with the host. Is that what's broken by the defaults?

@Meligy the issue specifically steams for m1 macs as there isn't a native mssql container. if your on an Intel Mac or windows there isn't a strong reason to switch.

[Meligy]

@Meligy the issue specifically steams for m1 macs as there isn't a native mssql container

@invaderb, yes. I get that. I have an M1 Max MacbBook Pro 16". And I use colima for that.

Sorry if my question was not clear but I was asking about the reason for customising the colima template vs using colima's defaults, for someone who's already using colima to run SQL Server on Mac.

[darrinholst]

Is it faster or anything?

Yes. Significantly. For some people just getting it to run with qemu emulation on arm64 was good enough. For others the performance was a show stopper.

In my case we’re using it for automated testing against a local database (with the need for the CLR so the azure image was out). It’s the difference between seconds and literally minutes.

[Meligy]

OK. The new settings in colima ARE cool, much faster indeed.

I started by deleting the existing VM then following the cleanup instructions above (my default template was not including the vmType setting without them):

colima delete
brew uninstall --force colima lima
rm -rf ~/.colima ~/.lima
brew install colima

Then I applied the settings to colima template:

vmType: vz
mountType: virtiofs

I forgot to measure the colima start command time difference, it certainly felt faster, but I could see the speeds of starting a custom SQL Server image (for enabling Full Text Search etc.) changing quite a bit.

First, I want to mention how I changed my start command, because it was problematic. I changed it as follows...

From (OLD):

colima start --arch x86_64 --cpu-type kvm64 --cpu 4 --memory 4 --disk 60

To (NEW):

colima start --network-address --cpu 4 --memory 4 --disk 60

Looking at the default comments in the template, I think at least setting cpu-type was reverting my change to QEMU.

And the results were amazing.

Results BEFORE (I cancelled when I sensed nothing changed from usual):

Results AFTER (Look at same-shape arrows for comparison):

The download time of the 784.49MB part ending in f3a3464f went down from 64.3s to 48.8s, but the most amazing time difference was the extraction of the same part, going down from 211.2s to just 12.4s!! Not to mention that also my custom apt-get commands time went from 142.0s to 45.6s.

That's going from minutes to seconds as @darrinholst said!

Thanks for sharing!

And hopefully at some point people won't have to go through all of this.

[jordantshaw]

UPDATE: The new docker-desktop release (v4.16.0) introduces a new Mac beta feature, Rosetta for Linux, which helps performance and stability when running intel bases images. I am now able to run MSSQL docker image on my Mac M1 laptop with no issues yet. Also seems pretty performant, but have not run any benchmarks yet.

It would still be better if microsoft would provide a native ARM image, but this seems to be the best work around for now.

Release Notes:
New Beta feature for MacOS 13, Rosetta for Linux, has been added for faster emulation of Intel-based images on Apple Silicon.

[dzsquared]

Recapping where arm64 (M1/M2) support is currently for SQL Server:

• to run the mssql container, enable Rosetta for emulation in Docker Desktop v4.16 or higher (also requires Ventura) https://devblogs.microsoft.com/azure-sql/development-with-sql-in-containers-on-macos/
  • alternatively, you can setup Colima
  • also alternatively, you can use Azure SQL Edge
• Azure Data Studio has an arm64 macOS build https://github.com/microsoft/azuredatastudio
  • alternatively, you can use the mssql extension in VS Code
• go-sqlcmd cli has native arm64 builds available in brew and for direct download https://docs.microsoft.com/sql/tools/go-sqlcmd-utility

if I've missed anything from the 91 comments in this thread, please feel free to open a new issue on that specific item!

[glerchundi]

@dzsquared thanks for the list! Would you mind adding to that list that macOS Ventura (13) is required? I've gone crazy looking for that checkbox within the Docker Desktop and realised that it wasn't present because I was on 12.

[Meligy]

I don't know about the need for latest Mac, but there's another gotcha to be aware of that I mentioned here: docker/roadmap#384 (comment).

In short: there are 2 beta features in the same tab, the Rosetta emulation and containerd for image pulling and storage. The containerd feature is supposed to be much faster but in my experience it caused an error, and after turning it off, the image pulling and extraction was still fairly fast (71.7s vs 61.3s on colima as mentioned above).

[Jolg42]

Someone confirmed macOS Ventura is required, see docker/roadmap#384 (comment), I'll upgrade soon to get this on my computer.
It's also mentioned in https://devblogs.microsoft.com/azure-sql/development-with-sql-in-containers-on-macos/

In the v4.16 release of Docker Desktop, support for using Rosetta for emulation of x86/amd64 images was introduced as a beta feature, enabling improved performance and stability for running container images built for x86/amd64 on macOS 13 (Ventura).

[tinydogio-joshua]

Are there any plans for an official ARM container? My understanding is that Rosetta will most likely go away at some point. It would be nice to see an official ARM build.

[theramzay]

+1 for native arm build, because Rosetta 2 like Rosetta 1 -- just temporary workaround for 2-4 years.

[mkurz]

Yeah, that would be really great! aarch64 build now 😉

[jclausen]

I can confirm that running the x86_64 SQL Server container under Rosetta is not an ideal solution. Due to the arch emulation, the SQL Server container under load locks up and becomes unresponsive. My M1-using devs report they are constantly having to restart the SQL Server container. They can use it, but it's buggy.

[mkurz]

Yeah it sucks! Give us the real thing 🙏

[dzsquared]

Alright folks - there's a new issue to track for a native aarch container - you're welcome to bring your concrete feedback to the comments - #802