Linux emulator fails on macOS M1 even with x64 virtualization

[chriskuech]

Understandably, you do not support M1 chips and it is questionable if supporting M1 chips is worth prioritizing; however, somehow the container fails on M1 even when using x64 virtualization, as demonstrated in #17.

At a minimum, can we have the container work with x64 emulation?

[knames]

same issue here, not able to connect. I followed the guide to export the cert, turned off firewall/defender and everything else I could think of.

[andycookiebit]

Hi @markjbrown

I'm reading this thread with interest, however I'd like to see the emulator being able to run within a Docker container. Our automated tests use Docker to build the Environment. Needing to use a VM is a step too far and backwards these days.

When considering your next semester, please consider releasing the emulator as a docker image. From there, I expect many developers would get fast access and be able to work with the Cosmos DB.

I'm left to wonder what alternative to use locally. Postgres? Mongo?

We have devs on M1/M2 Macs, Intel Macs, Windows and Linux.

[theramzay]

Yep, buy Parallels and then having an entire virtual machine just for Cosmos DB is VERY annoying. Docker is just what we all need.

[CSharpFiasco]

Is there a timeline for this, I think it'd be very useful. Thanks!

[robertmrobo]

This is very very important Microsoft. Please.

[comc]

Given the 2023 Developer's Survey from StackOverflow indicates 33% of professional developers use MacOS, support for the newer Apple silicon should be a much higher priority for Azure tooling. I've encountered so many Azure tools that lack this support, it's infuriating developing in this ecosystem.

[mpatnode]

So after realizing I couldn't run Microsoft Server in VMWare Fusion on my M2, I started down the Cosmos Docker path and wound up here. It's almost like Microsoft and/or Apple don't really want to developers to work cross platform. How odd.

[nvanexan]

Any update on this?

[theramzay]

Apple has released the m3 lineup, but we are still without the support of Apple Silicon here, even though docker x86_64 translation to arm64 via Rosetta 2. Sad, just very sad, it shows us how Microsoft supports developers who have tried to invest in Azure cloud 😢

[christian-estrella]

Yep, buy Parallels and then having an entire virtual machine just for Cosmos DB is VERY annoying. Docker is just what we all need.

Use the SSH port-forwarding tunnel, it works fine.

You only need install OpenSSH Server from Optional Features on Windows, run the service and then create the tunnel from Mac:

ssh -L 8081:127.0.0.1:8081 your-user@the-windows-ip

Don't forget change the network connection as Bridge.

Note: When you enter to 127.0.0.1:8081/_explorer/index.html... download the certificate and install it, if not your Chrome or the default browser will show up a warning.

[pseudoramble]

Just a pointer for anyone attempting to use the VM workaround - I discovered today that version 2.14.12 appears to not bind to an open network interface anymore, and only localhost. I don't know why this is the case, but it very well could be the cause of people's connectivity issues here. It certainly was mine!

I downgraded to 2.14.9 by finding a link to the package in the Chocolatey repo, uninstalling the latest version and installing 2.14.9 instead. Here's a direct link to the MSI installer. This resolved my connectivity issues immediately. So that may help people get unstuck here too.

[aadamsx]

I'm doing development for azure and as apart of that I'm using Cosmos. I just got my bill and with only one database and a few containers I'm up to $200 for the month -- just for testing! Outrageous prices! I have to emulate Cosmos for local development or I'll need to use something like Mongodb. I'm on a M1 mac. So the steps to get this working as I've seen it here are (since docker is not an option):

1. Install Parallels for Macos
2. Install Windows on Parallels
3. Install Emulator on Windows
4. Install OpenSSH Server from Optional Features on Windows
5. Change the network connection as Bridge
6. Use SSH port-forwarding tunnel, so the emulator on widows is accessiable to the host Macos
7. When you enter to 127.0.0.1:8081/_explorer/index.html... download the certificate and install it

Is this it? What am I missing?

[christian-estrella]

I'm doing development for azure and as apart of that I'm using Cosmos. I just got my bill and with only one database and a few containers I'm up to $200 for the month -- just for testing! Outrageous prices! I have to emulate Cosmos for local development or I'll need to use something like Mongodb. I'm on a M1 mac. So the steps to get this working as I've seen it here are (since docker is not an option):

1. Install Parallels for Macos
2. Install Windows on Parallels
3. Install Emulator on Windows
4. Install OpenSSH Server from Optional Features on Windows
5. Change the network connection as Bridge
6. Use SSH port-forwarding tunnel, so the emulator on widows is accessiable to the host Macos
7. When you enter to 127.0.0.1:8081/_explorer/index.html... download the certificate and install it

Is this it? What am I missing?

Sorry @aadamsx but this is not working anymore, I don't know why, maybe Windows's firewall rule? I tried to fix in different ways without exit, the database connect successfully but I can't save data on it. Well, at the moment I'm working under Windows using Parallels and works fine.

[aadamsx]

Sorry @aadamsx but this is not working anymore, I don't know why, maybe Windows's firewall rule? I tried to fix in different ways without exit, the database connect successfully but I can't save data on it. Well, at the moment I'm working under Windows using Parallels and works fine.

Thanks. And you say you got this working by working within Windows? So you have to set up your azure functions or whatever functions are interacting with Cosmos within windows for this to work?

[aadamsx]

Looks like I'm going to have to install Mongo: brew install mongodb-community@7.0 and work with this as an approximation of cosmos. Is this what everyone is doing to get around this?

Of course the queries are different if you use the NoSQL interface for Cosmos instead of Mongo:

https://learn.microsoft.com/en-us/azure/cosmos-db/mongodb/tutorial-query https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/query/subquery

[alsiola]

Looks like I'm going to have to install Mongo: brew install mongodb-community@7.0 and work with this as an approximation of cosmos. Is this what everyone is doing to get around this?

Of course the queries are different if you use the NoSQL interface for Cosmos instead of Mongo:

https://learn.microsoft.com/en-us/azure/cosmos-db/mongodb/tutorial-query https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/query/subquery

Most of us have just moved on to other databases at this point...

[christian-estrella]

Sorry @aadamsx but this is not working anymore, I don't know why, maybe Windows's firewall rule? I tried to fix in different ways without exit, the database connect successfully but I can't save data on it. Well, at the moment I'm working under Windows using Parallels and works fine.

Thanks. And you say you got this working by working within Windows? So you have to set up your azure functions or whatever functions are interacting with Cosmos within windows for this to work?

Exactly, I'm working with Parallels for now using Visual Studio Community, but also I'm thinking to migrate to mongodb. On Windows with Parallels cosmos db emulator works well, I can save data and retrieve it so I think the problem is something related to NetworkAllowAccess.

[aadamsx]

Okay, I spun up a mongodb instance on railway.app ($5 a month plan to start). Migrated my data over from Cosmos to the new Mongo instance. Changed the connection strings on my Azure Functions, and everything seems to be working fine -- seemless and smooth transition so far. Once they figure this Arm64 transition for Cosmos, I'm willing to migrate back.

[Jan-Jasek]

@markjbrown I suspect that the April-October semester is most likely over, but this issue also did not make its way to the current one?

[markjbrown]

Hi folks. First, I want to apologize, again. We know this is not a great experience for you. Also, apologies for not responding here sooner. I needed some time to gather information on the current state of all this so I could provide a more concise and accurate update.

As I indicated over a year ago, we were looking to add this to our roadmap. I'd like to share an update on that work and also share a bit on the internals of our emulator to provide some transparency on what's involved.

Our emulator is an actual mini-Cosmos DB, minus things that don't make sense on your personal machine, such as authentication, replication, etc. The Azure Cosmos DB code base is written in C++ with many dependencies using Windows-native system calls. For the past year as we have been working on porting it, we’ve been able to emulate many Windows-native system calls on Linux using the same PAL (Platform Abstraction Layer) that powers SQL Server on Linux. Unfortunately, PAL does not solve Apple Silicon compatibility. We’ve investigated multiple paths including using Rosetta for x86/amd64 emulation – and what we’ve found is that the effort to get all of Cosmos DB’s dependent Windows-native system calls working is high. This is why things are taking so long.

While we continue to work on this, for some of you, we may have an alternative that might help

1. For existing Azure customers using our RU-based, NoSQL and Mongo API's, we offer a Free Tier. Customers can get one free tier Cosmos account per subscription. This is free forever and comes with 1000 RU/s. You can configure this to keep locked at 1000 RU/s or less using the Cost Control feature in the portal when you create it to ensure it always remains free.
2. For Azure customers who are interested in our MongoDB vCore option, we have announced a [MongoDB vCore Free Tier option] (https://devblogs.microsoft.com/cosmosdb/run-mongo-workloads-for-free-with-azure-cosmos-db-for-mongodb-vcore-free-tier/).
3. For customers without an Azure Subscription and/or who cannot get access to a Free Tier account, we have another alternative for a free RU-based Cosmos account, our Try Cosmos free trial experience. This will give you a completely free Cosmos DB account. The trial only last for 30 days but you can continue to renew it indefinitely in our Try Cosmos portal. To sign up you will need to use a non-AAD account that is not part of any Azure tenant. (basically, an Outlook or Hotmail account).

We have been following the guidance and help you have been giving each other. I love seeing developers helping each other. It makes me proud to be a part of this community and to be associated with you all. Thank you for sharing with each other.

We want to make it easier for other developers to find this knowledge you've shared and share some other guidance we’ve learned. We are working on publishing this guidance you’ve shared as docs and samples on MS Learn to help others and will publish this soon.

I again want to apologize again to those of you who have struggled due to our missing emulator support. We pride ourselves in being a developer-first database with an on our SDK's and developer experience. An emulator is a HUGE part of that experience and we have not lived up to our expectations. We recognize the need to do better and are committed to doing it.

[JLuzz]

We pride ourselves in being a developer-first database with an on our SDK's and developer experience

Why doesn't microsoft develop these products without depending on windows native functionality first?

Seems like a no-brainer

[nvanexan]

@markjbrown thanks for the update. I'm currently working on a project for a Microsoft Azure customer. And on my team, I'm having to use a serverless instance of Cosmos DB vs the emulator precisely because of this issue. This is a bit frustrating as it means I can't develop offline. But more to the point, I just ran into a scenario where I was unable to run integration tests locally because of a configuration change in the code for cosmos re throughput handling, which worked fine in the context of the emulator, but failed when using a serverless instance for the reasons re "shared throughput database creation is not supported for serverless accounts" outlined here. I appreciate the update and the suggested workarounds, but unfortunately it's still not the same as having actual parity in tooling with the rest of my team.

Perhaps I missed it in the update, and I'm sorry if I have, but is there a commitment in terms of timing or planning on the roadmap for resolving this issue? I saw a bunch of workarounds (all using the cloud) and an explanation of why it's difficult, but I saw no information about which semester this is being slated to be tackled. Is there really a commitment here by Microsoft to make this work or is this just going to languish for more years to come? (And I'm sorry to say years, but at this point my M1 Macbook Air is now 3 years old... the M-series Macs aren't exactly new.)

[markjbrown]

hi @nvanexan sorry for the slow reply. catching up.

Serverless accounts do not have any throughput provisioned for them so anything you try to do with a serverless account and throughput will not work. I'm not sure why it appears to work in the emulator as it should not work at all.

I don't have a date to share at this point. This work has been ongoing. I realize this has been a years' long issue. This issue did span COVID. This isn't a major reason for the length of time but for sure didn't help. When I feel like we have something we can share with you all here I will absolutely share it.

PS: Make sure you understand our recommendations with shared database throughput. If you have containers with uneven requests and storage needs, this may not be a good choice to use across every container. Containers with shared database throughput are ok when each of the containers has roughly equal throughput and storage needs. Use dedicated throughput in the same database for containers which have greater needs. This will ensure that those containers scale with predictable performance.

[mfamphlett]

@markjbrown Is this likely to land this year?

[UberAtziri]

This the only thing that preventing me from completely switching my workstation to a mac. I appreciate the effort you guys are putting in. Hope the issue will be resolved sometimes soon

[aadamsx]

This the only thing that preventing me from completely switching my workstation to a mac. I appreciate the effort you guys are putting in. Hope the issue will be resolved sometimes soon

Cynical thought, maybe they don't want people switching to the mac rofl.

[muirandy]

Choose automated tests. Choose an OS and machine that makes you productive. Choose reliability. Choose being able to work offline. Choose fast feedback. Choose products that support you.

[chehsunliu]

We're forced to use an actual Cosmos DB to perform integration testing on CI. The emulator is too slow, unlike DynamoDB local... An extra blob is also used as a mutex to guarantee there is only single CI job involved.

[CSharpFiasco]

I'm very appreciative of this tool and would like to use it on my Mac. Is there a timeline for this issue yet? Thanks again!

[jaredweinfurtner]

Hi folks. First, I want to apologize, again. We know this is not a great experience for you. Also, apologies for not responding here sooner. I needed some time to gather information on the current state of all this so I could provide a more concise and accurate update.

As I indicated over a year ago, we were looking to add this to our roadmap. I'd like to share an update on that work and also share a bit on the internals of our emulator to provide some transparency on what's involved.

Our emulator is an actual mini-Cosmos DB, minus things that don't make sense on your personal machine, such as authentication, replication, etc. The Azure Cosmos DB code base is written in C++ with many dependencies using Windows-native system calls. For the past year as we have been working on porting it, we’ve been able to emulate many Windows-native system calls on Linux using the same PAL (Platform Abstraction Layer) that powers SQL Server on Linux. Unfortunately, PAL does not solve Apple Silicon compatibility. We’ve investigated multiple paths including using Rosetta for x86/amd64 emulation – and what we’ve found is that the effort to get all of Cosmos DB’s dependent Windows-native system calls working is high. This is why things are taking so long.

While we continue to work on this, for some of you, we may have an alternative that might help

1. For existing Azure customers using our RU-based, NoSQL and Mongo API's, we offer a [Free Tier](https://learn.microsoft.com/azure/cosmos-db/free-tier). Customers can get one free tier Cosmos account per subscription. This is free forever and comes with 1000 RU/s. You can configure this to keep locked at 1000 RU/s or less using the Cost Control feature in the portal when you create it to ensure it always remains free.

2. For Azure customers who are interested in our MongoDB vCore option, we have announced a [MongoDB vCore Free Tier option] (https://devblogs.microsoft.com/cosmosdb/run-mongo-workloads-for-free-with-azure-cosmos-db-for-mongodb-vcore-free-tier/).

3. For customers without an Azure Subscription and/or who cannot get access to a Free Tier account, we have another alternative for a free RU-based Cosmos account, our [Try Cosmos](https://cosmos.azure.com/try/) free trial experience. This will give you a completely free Cosmos DB account. The trial only last for 30 days but you can continue to renew it indefinitely in our Try Cosmos portal. To sign up you will need to use a non-AAD account that is not part of any Azure tenant. (basically, an Outlook or Hotmail account).

We have been following the guidance and help you have been giving each other. I love seeing developers helping each other. It makes me proud to be a part of this community and to be associated with you all. Thank you for sharing with each other.

We want to make it easier for other developers to find this knowledge you've shared and share some other guidance we’ve learned. We are working on publishing this guidance you’ve shared as docs and samples on MS Learn to help others and will publish this soon.

I again want to apologize again to those of you who have struggled due to our missing emulator support. We pride ourselves in being a developer-first database with an on our SDK's and developer experience. An emulator is a HUGE part of that experience and we have not lived up to our expectations. We recognize the need to do better and are committed to doing it.

6 months later and still no real solution. developer experience should be one of the highest priorities.

[potatoqualitee]

Would also appreciate progress.

[svause-stryker]

This is kind of extra important in the context of Aspire based development. There is a lot of potential here to run all these containers with the AppHost for development, regression testing, etc.

[wondertalik]

So, Microsoft presented Surface Pro 11 with arm chips. Nice laptops, but for developers this is some kind of trap if cosmo db emulator is not going to work on it.

[dougnob]

Any progress on this? Definitely interested... Thanks.

[pyonk]

Hello, recently I found a workaround for using the CosmosDB Emulator on my M1 MacBook Pro. I use colima with a VM which architecutre is x86_64. There were some issues with the combination of the latest versions, so we have to use the specific versions of colima and an emulator at this time.

1. Install colima@0.6.8

:warning: When I used the latest version(0.6.9), the emulator didn't start. The cause seems to be the VM image, which is updated in the latest version.

❯ curl -o colima@0.6.8 -L https://github.com/abiosoft/colima/releases/download/v0.6.8/colima-Darwin-arm64
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 7759k  100 7759k    0     0   994k      0  0:00:07  0:00:07 --:--:-- 1114k

❯ colima@0.6.8 version
colima version 0.6.8
git commit: 9b0809d0ed9ad3ff1e57c405f27324e6298ca04f

2. Create a VM with --arch option

To emulate x86_64 architecutre, we have to use this option. :warning: I tried with rosetta options, but the emulator didn't run.

❯ colima@0.6.8 start -p x86_64 --arch x86_64

3. Run an emulator tagged mongodb

❯ docker run \
  --publish 8081:8081 \
  --publish 10250-10255:10250-10255 \
  --interactive \
  --tty \
  --env AZURE_COSMOS_EMULATOR_PARTITION_COUNT=1 \
  mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:mongodb
Unable to find image 'mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:mongodb' locally
mongodb: Pulling from cosmosdb/linux/azure-cosmos-emulator
...
Digest: sha256:28188604ad7be14497e1eb19757a6dd161b38dbb0508581b87fcda17879ebc34
Status: Downloaded newer image for mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:mongodb
This is an evaluation version.  There are [121] days left in the evaluation period.
Starting
Started 1/2 partitions
Started 2/2 partitions
Started

:warning: The latest version doesn't work in my environment. The images that I downloaded are the following.

❯ docker images --digests
REPOSITORY                                               TAG       DIGEST                                                                    IMAGE ID       CREATED       SIZE
mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator   latest    sha256:bf9ddf53430701e6d954bdc8cd07ef672f0642a55244e2d4b0b478a633e89d27   b05a7af77243   3 weeks ago   2.35GB
mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator   mongodb   sha256:28188604ad7be14497e1eb19757a6dd161b38dbb0508581b87fcda17879ebc34   94581d68a4f3   7 weeks ago   2.27GB

4. Then, you can access https://localhost:8081/_explorer/index.html :tada:

---

Actually, a month ago, it had worked when I used the latest version of colima and the emulator. And I tried in the new environment, then, I faced some issues and investigated. I don't know why the emulator is tagged "mongodb", but it works in my environment.

I hope this helps you :pray:

[TeddMcAdams]

So, Microsoft presented Surface Pro 11 with arm chips. Nice laptops, but for developers this is some kind of trap if cosmo db emulator is not going to work on it.

Hey that's me! Sitting here on a fancy SP11, have migrated and gotten everything up and running fairly easily from my SP8 and wow. Years later still no ARM64 support for the emulator?

Enough excuses, just get it done.

[wondertalik]

@pyonk on my m3, Mac OS Sonoma 14.5 it does't work

➜  ~ colima@0.6.8 start -p x86_64 --arch x86_64
> [hostagent] Waiting for the essential requirement 1 of 2: "ssh"
> [hostagent] Waiting for the essential requirement 1 of 2: "ssh"
> [hostagent] Waiting for the essential requirement 1 of 2: "ssh"
> [hostagent] Waiting for the essential requirement 1 of 2: "ssh"
> [hostagent] Waiting for the essential requirement 1 of 2: "ssh"
> did not receive an event with the "running" status
FATA[0600] error starting vm: error at 'starting': exit status 1

[pyonk]

@wondertalik Ummm, weird. It actually works on my work computer, which is the same as yours, m3 and Sonoma 14.5 🤔 .

[TeddMcAdams]

I am attempting to follow your footsteps @pyonk, but using Ubuntu running via WSL in Windows 11. Been at it for a week now and still trying to get Colima installed via Brew.

Went down this rabbit hole, which seems to have worked as far as getting Brew running. https://github.com/huyz/brew-for-linux-arm

The Brew guys are pretty funny, this cracks me up.

Warning: Your CPU architecture (arm64) is not supported. We only support x86_64 CPU architectures. You will be unable to use binary packages (bottles). It is expected behaviour that some formulae will fail to build in this unsupported configuration. It is expected behaviour that Homebrew will be buggy and slow. Do not create any issues about this on Homebrew's GitHub repositories. Do not create any issues even if you think this message is unrelated. Any opened issues will be immediately closed without response. Do not ask for help from Homebrew or its maintainers on social media. You may ask for help in Homebrew's discussions but are unlikely to receive a response. Try to figure out the problem yourself and submit a fix as a pull request. We will review it but may or may not accept it.

[mr-panucci]

As well as the ARM64 issue, I'm finding I'm wrestling the Cosmos emulator in Linux on x86 more and more too, with tests failing locally and on build agents and constant 503 responses from the Cosmos emulator. I'm going to make the leap to Mongo DB API for Cosmos and start using Mongo locally and on build agents. Some refactoring but I think it will solve all my issues and be worth it in the long run.

Anyone else gone down this route with any success?

[simon-k]

Any news about an emulator working on Mac?

This is a pretty painfull DevEx for many of us running Mac.

[jkells]

Does anyone have any technical explanation to why this doesn't work, I mean it's an x64 binary running on qemu or roesetta and just terminates, why?

Anyone dug into the error perhaps we could fix it in qemu?

[atomicpages]

Tried on colima 0.7.5 and no dice. Seg fault on a M3 Sonoma 14.6.1 😢

This is an evaluation version.  There are [43] days left in the evaluation period.
Starting
This program has encountered a fatal error and cannot continue running at Sat Aug 31 22:01:26 2024
The following diagnostic information is available:

         Reason: Fatal Signal (0x00000001)
         Signal: SIGABRT - Aborted (6)
          Stack:
                 SP               IP               Function
                 ---------------- ---------------- ----------------
                 000075634a0804a0 00005f31c3858bfa <unknown>
                 000075634a081500 00005f31c38585cf <unknown>
                 000075634a081760 00005f31c3857a61 <unknown>
                 000075634a081780 000075634fcb5090 killpg+0x40
                 000075634a081bd0 000075634fcb500b gsignal+0xcb
                 000075634a081cf0 000075634fc94859 abort+0x12b
                 000075634a081e20 00005f31c37f0332 <unknown>
                 000075634a081ed0 00005f31c3879b14 <unknown>
                 000075634a081ef0 00005f31c38a8f38 <unknown>
                 000075634a081fa0 00005f31c38a8d1a <unknown>
                 000075634a082000 00005f31c37fc1ba <unknown>
                 000075634a082080 00005f31c37fbe0d <unknown>
                 000075634a082160 00005f31c3871361 <unknown>

        Process: 19 - cosmosdb-emulator
         Thread: 117 (application thread 0x1a4)
    Instance Id: d9d387c3-d7a0-4649-9b68-848de6b027a3
       Crash Id: 689bd602-aacb-4bb1-bdd8-2c721432b8fd
    Build stamp: (null)
   Distribution: Ubuntu 20.04.6 LTS
     Processors: 2
   Total Memory: 2058743808 bytes
      Timestamp: Sat Aug 31 22:01:26 2024
     Last errno: -34938881
Last errno text: Unknown error -34938881
*********** PAL PANIC CORE DUMP GENERATION FAILED **********
Unable to locate handle-crash.sh. Error: File: signals.cpp:483 [Status: 0xC0000034 Object name not found errno = 0x2(2) No such file or directory]
*********** PANIC CORE DUMP GENERATION FAILED **********
Attempt to launch handle-crash.sh failed.
Executing: /usr/local/bin/cosmos/handle-crash.sh with parameters
     handle-crash.sh
     /usr/local/bin/cosmos/cosmosdb-emulator
     19
     /usr/local/bin/cosmos
     /tmp/cosmos/appdata/log/

     d9d387c3-d7a0-4649-9b68-848de6b027a3
     689bd602-aacb-4bb1-bdd8-2c721432b8fd

This program has encountered a fatal error and cannot continue running at Sat Aug 31 22:01:26 2024
The following diagnostic information is available:

         Reason: Host Extension RTL_ASSERT (0x00000003)
         Status: STATUS_WAIT_2 (0x00000002)
        Message: !killTheTarget
          Stack:
                 SP               IP               Function
                 ---------------- ---------------- ----------------
                 000075634ddfbdf0 00005f31c3858bfa <unknown>
                 000075634ddfce50 00005f31c38585cf <unknown>
                 000075634ddfd0b0 00005f31c37c2b66 <unknown>
                 000075634ddfd0e0 00005f31c385c0e4 <unknown>
                 000075634ddfe310 00005f31c385b7a9 <unknown>
                 000075634ddfe440 0000756350310609 start_thread+0xd9
                 000075634ddfe500 000075634fd91353 clone+0x43

        Process: 17 - cosmosdb-emulator
         Thread: 18
    Instance Id: d9d387c3-d7a0-4649-9b68-848de6b027a3
       Crash Id: 689bd602-aacb-4bb1-bdd8-2c721432b8fd
    Build stamp: (null)
   Distribution: Ubuntu 20.04.6 LTS
     Processors: 2
   Total Memory: 2058743808 bytes
      Timestamp: Sat Aug 31 22:01:26 2024
     Last errno: 2
Last errno text: No such file or directory
Aborted (core dumped)

[wondertalik]

Hey that's me! Sitting here on a fancy SP11, have migrated and gotten everything up and running fairly easily from my SP8 and wow. Years later still no ARM64 support for the emulator?

@TeddMcAdams fixed in version 2.14.20. It works for me.

[alexjamesbrown]

I don't think this should be closed @sajeetharan Emulator still doesn't work on mac m1/m2/m3 etc...

[theramzay]

It still doesn’t works with/without Rosetta x86_64 in Docker on M1 Pro (arm64). I’ve tested it right now!

[kmandalas]

Can we please have at least a rough estimation when will this finally be available?

[potatoqualitee]

Yes pls. Would love not just an update, but prioritization of this issue. It's been a very long time.

Thank you 🙏🏼

[markjbrown]

Hey folks.

We are working on something that is going to finally resolve this for all users. I can't share the details yet of what we are doing but this will all come out when we preview its release.

Again, my sincere apologies this has taken so long to resolve and THANK YOU for being so patient with us. It means a lot to us and me personally that you have stuck it out with us.

[Nishant-ProRata]

Would be so helpful to have the ETA on this.