search

docker / for-mac

Bug reports for Docker Desktop for Mac
https://www.docker.com/products/docker#/mac
2.44k stars 118 forks source link

What makes Docker VMM better than Apple Virtualization Framework? #7464

Open robd003 opened 1 month ago

robd003 commented 1 month ago

Could you guys write a blog post detailing the differences between Apple's Virtualization Framework and the new Docker VMM?

Right now there's very little information about Docker VMM other than "it's beta"

NiklasBr commented 1 month ago

I'm not entirely clear on the distinction/relation between Rosetta/Apple's Virtualization Framework/Docker VMM/QEMU either.

JoshuaLuckers commented 1 month ago

I was looking for the same information. It would be nice of there was a blogpost with some graphs or other info on the performance improvements.

MihaelaStoica commented 1 month ago

Thank you for your interest in Docker VMM! We are preparing a blog post with more info on the performance improvements. Also, we will add more info to the docs.

thienanblog commented 1 month ago

Can't enable it on M1 Pro and MacOS 15.1 even if I restarted Docker.

running engine: waiting for the Docker API: engine linux/libkrun failed to run: running VM: krun: process terminated unexpectedly: exit status 2

doringeman commented 4 weeks ago

Hey @thienanblog, Please upload a diagnostics bundle and quote the ID here, ideally right after you experience the issue. https://docs.docker.com/desktop/troubleshoot/#diagnose-from-the-terminal.

thienanblog commented 3 weeks ago

Hey @thienanblog, Please upload a diagnostics bundle and quote the ID here, ideally right after you experience the issue. https://docs.docker.com/desktop/troubleshoot/#diagnose-from-the-terminal.

Diagnostics ID: CF2147DB-7708-440B-A53D-EB643D79CFA3/20241029074913

Please take a look, I couldn't get it to work with Docker VMM. Could only use Apple Virtualization Framework to get it working again.

markedwards commented 3 weeks ago

Also was not able to use Docker VMM due to a failure starting a rabbitmq:3.13.1-management instance, with the error Cookie file /var/lib/rabbitmq/.erlang.cookie must be accessible by owner only. Works fine with Apple Virtualization Framework with the same image.

Hax7 commented 3 weeks ago

Can't enable it on M1 Pro and MacOS 15.1 even if I restarted Docker.

running engine: waiting for the Docker API: engine linux/libkrun failed to run: running VM: krun: process terminated unexpectedly: exit status 2

Increasing memory resources from 2GB to 4GB fixed this for me

thienanblog commented 3 weeks ago

Can't enable it on M1 Pro and MacOS 15.1 even if I restarted Docker. running engine: waiting for the Docker API: engine linux/libkrun failed to run: running VM: krun: process terminated unexpectedly: exit status 2

Increasing memory resources from 2GB to 4GB fixed this for me

Wow, thanks! It worked! But i can't use MySQL Container anymore with Docker VMM so I have to revert back to Apple Virtualization Framework again.

Lenitr commented 3 weeks ago

Can't enable it on M1 Pro and MacOS 15.1 even if I restarted Docker. running engine: waiting for the Docker API: engine linux/libkrun failed to run: running VM: krun: process terminated unexpectedly: exit status 2

Increasing memory resources from 2GB to 4GB fixed this for me

Wow, thanks! It worked! But i can't use MySQL Container anymore with Docker VMM so I have to revert back to Apple Virtualization Framework again.

I'm running into the same thing, the Mysql container crashes after booting with this error

2024-10-31 15:51:56 2024-10-31T14:51:56.436341Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2024-10-31 15:51:57 2024-10-31T14:51:57.102953Z 1 [ERROR] [MY-013183] [InnoDB] Assertion failure: os0file.cc:2909:ret == 0 thread 46912736060992
2024-10-31 15:51:57 InnoDB: We intentionally generate a memory trap.
2024-10-31 15:51:57 InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
2024-10-31 15:51:57 InnoDB: If you get repeated assertion failures or crashes, even
2024-10-31 15:51:57 InnoDB: immediately after the mysqld startup, there may be
2024-10-31 15:51:57 InnoDB: corruption in the InnoDB tablespace. Please refer to
2024-10-31 15:51:57 InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
2024-10-31 15:51:57 InnoDB: about forcing recovery.
2024-10-31 15:51:57 2024-10-31T14:51:57Z UTC - mysqld got signal 6 ;
2024-10-31 15:51:57 Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
2024-10-31 15:51:57 BuildID[sha1]=511ab47ad6d5dfd73d58eea5860b1c9c9a97ce07
2024-10-31 15:51:57 Thread pointer: 0x61176d0
2024-10-31 15:51:57 Attempting backtrace. You can use the following information to find out
2024-10-31 15:51:57 where mysqld died. If you see no messages after this, something went
2024-10-31 15:51:57 terribly wrong...
2024-10-31 15:51:57 stack_bottom = 2aaab8f7db50 thread_stack 0x100000
2024-10-31 15:51:57 /usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x41) [0x15af021]
2024-10-31 15:51:57 /usr/sbin/mysqld(print_fatal_signal(int)+0x2af) [0xbe81df]
2024-10-31 15:51:57 /usr/sbin/mysqld(my_server_abort()+0x6d) [0xbe837d]
2024-10-31 15:51:57 /usr/sbin/mysqld(my_abort()+0xe) [0x15a4e5e]
2024-10-31 15:51:57 /usr/sbin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x16f) [0x177ab1f]
2024-10-31 15:51:57 /usr/sbin/mysqld() [0x16b6b88]
2024-10-31 15:51:57 /usr/sbin/mysqld(os_file_delete_if_exists_func(char const*, bool*)+0xf8) [0x16c1c58]
2024-10-31 15:51:57 /usr/sbin/mysqld() [0x1db7088]
2024-10-31 15:51:57 /usr/sbin/mysqld(log_remove_unused_files(Log_files_context const&)+0x255) [0x16908e5]
2024-10-31 15:51:57 /usr/sbin/mysqld(log_sys_init(bool, unsigned long, unsigned long&)+0xfeb) [0x16a28db]
2024-10-31 15:51:57 /usr/sbin/mysqld(srv_start(bool)+0xac6) [0x173b726]
2024-10-31 15:51:57 /usr/sbin/mysqld() [0x15f4392]
2024-10-31 15:51:57 /usr/sbin/mysqld(dd::bootstrap::DDSE_dict_init(THD*, dict_init_mode_t, unsigned int)+0xd7) [0x1444ad7]
2024-10-31 15:51:57 /usr/sbin/mysqld(dd::upgrade_57::do_pre_checks_and_initialize_dd(THD*)+0x22c) [0x15933dc]
2024-10-31 15:51:57 /usr/sbin/mysqld() [0xc8b03a]
2024-10-31 15:51:57 /usr/sbin/mysqld() [0x1b8aba2]
2024-10-31 15:51:57 /lib64/libc.so.6(+0x89c12) [0x2aaaabc7cc12]
2024-10-31 15:51:57 /lib64/libc.so.6(clone+0x44) [0x2aaaabd00f54]
2024-10-31 15:51:57 
2024-10-31 15:51:57 Trying to get some variables.
2024-10-31 15:51:57 Some pointers may be invalid and cause the dump to abort.
2024-10-31 15:51:57 Query (0): Connection ID (thread ID): 1
2024-10-31 15:51:57 Status: NOT_KILLED

I've even tried rebuilding the entire image, same result unfortunately. On Apple Virtualization Framework + Rosetta it works fine.

I'm running a M1 macbook with Sequoia 15.0.1 (24A348)

Edit: Not sure if it could be relevant, but I'm forcing the AMD64 platform in docker compose

platform: linux/amd64
bubenkoff commented 3 weeks ago

How do I enable the Docker VMM Image? It's disabled for some reason. Intel mac on the latest osx.

simonberger commented 3 weeks ago

Compared it to apples virtualization on a symfony project showing both, a great improvement and a big slowdown.

  1. Benchmark running phpstan was roughly 20% faster with VMM
  2. Benchmarking a subset of unit and api tests running with codeception was ~25% slower (!)

Update: Slowdown was caused by a Mysql amd86 image. The emulation of VMM is 4x weaker in this case. Using a custom arm64 build image brought the test speed on level of the apple virtualization framework as well, but not faster.

Interestingly the performance of the Apple Virtualization framework did not benefit at all from the native mysql container. Or viewed the other way around the rosetta emulation did an incredible job there.

Lenitr commented 3 weeks ago

How do I enable the Docker VMM Image? It's disabled for some reason. Intel mac on the latest osx.

From the description of the feature in docker desktop, I think it might be only usable on Apple Silicon macs?

djs55 commented 3 weeks ago

@simonberger thanks for sharing the benchmark results! For the one that was slower, could you share pointers or repro steps? I'd love to reproduce in-house. Thanks!

doringeman commented 3 weeks ago

Can't enable it on M1 Pro and MacOS 15.1 even if I restarted Docker. running engine: waiting for the Docker API: engine linux/libkrun failed to run: running VM: krun: process terminated unexpectedly: exit status 2

Increasing memory resources from 2GB to 4GB fixed this for me

Wow, thanks! It worked! But i can't use MySQL Container anymore with Docker VMM so I have to revert back to Apple Virtualization Framework again.

I'm running into the same thing, the Mysql container crashes after booting with this error

2024-10-31 15:51:56 2024-10-31T14:51:56.436341Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2024-10-31 15:51:57 2024-10-31T14:51:57.102953Z 1 [ERROR] [MY-013183] [InnoDB] Assertion failure: os0file.cc:2909:ret == 0 thread 46912736060992
2024-10-31 15:51:57 InnoDB: We intentionally generate a memory trap.
2024-10-31 15:51:57 InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
2024-10-31 15:51:57 InnoDB: If you get repeated assertion failures or crashes, even
2024-10-31 15:51:57 InnoDB: immediately after the mysqld startup, there may be
2024-10-31 15:51:57 InnoDB: corruption in the InnoDB tablespace. Please refer to
2024-10-31 15:51:57 InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
2024-10-31 15:51:57 InnoDB: about forcing recovery.
2024-10-31 15:51:57 2024-10-31T14:51:57Z UTC - mysqld got signal 6 ;
2024-10-31 15:51:57 Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
2024-10-31 15:51:57 BuildID[sha1]=511ab47ad6d5dfd73d58eea5860b1c9c9a97ce07
2024-10-31 15:51:57 Thread pointer: 0x61176d0
2024-10-31 15:51:57 Attempting backtrace. You can use the following information to find out
2024-10-31 15:51:57 where mysqld died. If you see no messages after this, something went
2024-10-31 15:51:57 terribly wrong...
2024-10-31 15:51:57 stack_bottom = 2aaab8f7db50 thread_stack 0x100000
2024-10-31 15:51:57 /usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x41) [0x15af021]
2024-10-31 15:51:57 /usr/sbin/mysqld(print_fatal_signal(int)+0x2af) [0xbe81df]
2024-10-31 15:51:57 /usr/sbin/mysqld(my_server_abort()+0x6d) [0xbe837d]
2024-10-31 15:51:57 /usr/sbin/mysqld(my_abort()+0xe) [0x15a4e5e]
2024-10-31 15:51:57 /usr/sbin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x16f) [0x177ab1f]
2024-10-31 15:51:57 /usr/sbin/mysqld() [0x16b6b88]
2024-10-31 15:51:57 /usr/sbin/mysqld(os_file_delete_if_exists_func(char const*, bool*)+0xf8) [0x16c1c58]
2024-10-31 15:51:57 /usr/sbin/mysqld() [0x1db7088]
2024-10-31 15:51:57 /usr/sbin/mysqld(log_remove_unused_files(Log_files_context const&)+0x255) [0x16908e5]
2024-10-31 15:51:57 /usr/sbin/mysqld(log_sys_init(bool, unsigned long, unsigned long&)+0xfeb) [0x16a28db]
2024-10-31 15:51:57 /usr/sbin/mysqld(srv_start(bool)+0xac6) [0x173b726]
2024-10-31 15:51:57 /usr/sbin/mysqld() [0x15f4392]
2024-10-31 15:51:57 /usr/sbin/mysqld(dd::bootstrap::DDSE_dict_init(THD*, dict_init_mode_t, unsigned int)+0xd7) [0x1444ad7]
2024-10-31 15:51:57 /usr/sbin/mysqld(dd::upgrade_57::do_pre_checks_and_initialize_dd(THD*)+0x22c) [0x15933dc]
2024-10-31 15:51:57 /usr/sbin/mysqld() [0xc8b03a]
2024-10-31 15:51:57 /usr/sbin/mysqld() [0x1b8aba2]
2024-10-31 15:51:57 /lib64/libc.so.6(+0x89c12) [0x2aaaabc7cc12]
2024-10-31 15:51:57 /lib64/libc.so.6(clone+0x44) [0x2aaaabd00f54]
2024-10-31 15:51:57 
2024-10-31 15:51:57 Trying to get some variables.
2024-10-31 15:51:57 Some pointers may be invalid and cause the dump to abort.
2024-10-31 15:51:57 Query (0): Connection ID (thread ID): 1
2024-10-31 15:51:57 Status: NOT_KILLED

I've even tried rebuilding the entire image, same result unfortunately. On Apple Virtualization Framework + Rosetta it works fine.

I'm running a M1 macbook with Sequoia 15.0.1 (24A348)

Edit: Not sure if it could be relevant, but I'm forcing the AMD64 platform in docker compose

platform: linux/amd64

Hello,

We managed to reproduce this and we're looking into it. Thanks for reporting the issue!

doringeman commented 3 weeks ago

Also was not able to use Docker VMM due to a failure starting a rabbitmq:3.13.1-management instance, with the error Cookie file /var/lib/rabbitmq/.erlang.cookie must be accessible by owner only. Works fine with Apple Virtualization Framework with the same image.

Hello,

I wasn't able to reproduce the issue using the following command:

docker run --rm -it --name rabbitmq -v $(pwd)/rabbitmq_data:/var/lib/rabbitmq rabbitmq:3.13.1-management

Can you share more details? Thanks for reporting the issue!

markedwards commented 3 weeks ago

Also was not able to use Docker VMM due to a failure starting a rabbitmq:3.13.1-management instance, with the error Cookie file /var/lib/rabbitmq/.erlang.cookie must be accessible by owner only. Works fine with Apple Virtualization Framework with the same image.

Hello,

I wasn't able to reproduce the issue using the following command:

docker run --rm -it --name rabbitmq -v $(pwd)/rabbitmq_data:/var/lib/rabbitmq rabbitmq:3.13.1-management

Can you share more details? Thanks for reporting the issue!

Its a container in a docker-compose.yml:

  rabbit:
    environment:
      RABBITMQ_PROTOCOL: amqp
      RABBITMQ_HOST: rabbit
      RABBITMQ_VHOST: /
      RABBITMQ_PORT: 5672
      RABBITMQ_USER: worker
      RABBITMQ_DEFAULT_USER: worker
      RABBITMQ_PASSWORD: worker
      RABBITMQ_DEFAULT_PASS: worker
    image: rabbitmq:3.13.1-management
    command: rabbitmq-server
    volumes:
      - ./rabbitmq/data/:/var/lib/rabbitmq
    ports:
      - "5672:5672"
      - "15672:15672"
simonberger commented 3 weeks ago

@simonberger thanks for sharing the benchmark results! For the one that was slower, could you share pointers or repro steps? I'd love to reproduce in-house. Thanks!

I'll try to track down which tests mainly cause the slowdown and then maybe create a reproduction repository or at least get an idea of the reasons. The project itself cannot be shared.

doringeman commented 3 weeks ago

Hello @thienanblog, @Lenitr,

Here's a custom v4.35.1 build that should fix the issue with MySQL: https://desktop-stage.docker.com/mac/main/arm64/173623/Docker.dmg

Let me know if it works for you!

lhaeger commented 2 weeks ago

Two questions:

doringeman commented 2 weeks ago

Hello @markedwards,

I was able to reproduce the issue and I'm investigating further. In the meantime, a workaround is to remove that file before starting the container, i.e., rabbitmq/data/.erlang.cookie. I'll keep you posted.

doringeman commented 2 weeks ago

Hello @lhaeger,

Two questions:

  • Is Docker VMM supposed to run AMD64 containers on Apple Silicon?

Yes, but it's using qemu emulators (https://github.com/tonistiigi/binfmt) instead of Rosetta. Rosetta is faster than qemu but it's only available with Apple Virtualization framework. We'll look into an alternative to qemu for Docker VMM.

  • is there an equivalent to the EXPERIMENTAL_DOCKER_DESKTOP_FORCE_QEMU env variable to force VMM just for a specific container?

There isn't. It sounds like you want only some containers to be run with Docker VMM? Are the others running amd64 images? Or are there more performance related differences? Could you elaborate on what you're aiming to accomplish?

simonberger commented 2 weeks ago

@simonberger thanks for sharing the benchmark results! For the one that was slower, could you share pointers or repro steps? I'd love to reproduce in-house. Thanks!

I'll try to track down which tests mainly cause the slowdown and then maybe create a reproduction repository or at least get an idea of the reasons. The project itself cannot be shared.

@djs55 I profiled two different tests and got some insides. While I am not sure if it is all PDOStatement::execute is 4x slower compared to Apple with VirtioFS. In numbers VMM took 1 second for 1000 calls and 167ms for 202 calls. Both times apple 4x faster. Let me know if you need more. I did not yet look into the performance on Database level outside of PHP which is most likely reproducible there. Just noticing while writing our mysql container is using an intel image so that's probably the reason for the performance decrease?

Update: Switching to an unofficial mysql 5.7 image indeed fixes the performance issues of the VMM run being as fast as the apple one afterwards. The apple run did not benefit of the arm mysql image at all staying at its performance.

@doringeman this is much related to your conversation with @lhaeger the emulation performance currently is in a range that is difficult to accept and more important everyone making the switch need to be aware of that downside. Maybe also list the containers with an amd64 image if any at that point?

solrevdev commented 2 weeks ago

Enabling Docker VMM and restarting gives me the error:

running engine: waiting for the Docker API: engine linux/libkrun failed to run: running VM: krun: process terminated unexpectedly: exit status 2

Diagnostics ID: 3E266B66-0155-49E5-BAF2-9B4F5426FBB9/20241106112637

autaut03 commented 2 weeks ago

Enabling VMM improved filesystem performance. Scanning 15k files using time (find src -type f | wc -l) would usually take ~1.6sec, while with VMM it only takes ~60ms. Also, PHP application cold starts feel quicker.

doringeman commented 2 weeks ago

Hey @solrevdev,

You need to increase VM's memory from 2GB to 4GB. Also mentioned in https://github.com/docker/for-mac/issues/7464#issuecomment-2446688074.

We'll come up soon with a solution to improve this experience.

Lenitr commented 2 weeks ago

Hello @thienanblog, @Lenitr,

Here's a custom v4.35.1 build that should fix the issue with MySQL: https://desktop-stage.docker.com/mac/main/arm64/173623/Docker.dmg

Let me know if it works for you!

Thanks, I've installed this version to test if it works, unfortunately it still throws me the same error as before. I've even tried it without the platform change to AMD64, (so just ARM) (and rebuilding the image for both), but it still shows the same error.

I've even tried it in a fresh project, to ensure it wasn't something with the existing volumes, but same result unfortunately.

doringeman commented 2 weeks ago

@Lenitr, does rm -rf mysql && docker run --rm -it --name mysql -v $(pwd)/mysql:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw --platform=linux/arm64 mysql:9.1.0 work for you with the new version I've shared?

yeldarby commented 2 weeks ago

Any possibility this will unlock using the MPS device in Docker for Mac?

timdang commented 2 weeks ago

Docker VMM doesn't work with the minimum resource allocation. I think the sliders in Docker Desktop should have the minimums adjusted for Docker VMM.

thienanblog commented 2 weeks ago

Hello @thienanblog, @Lenitr,

Here's a custom v4.35.1 build that should fix the issue with MySQL: https://desktop-stage.docker.com/mac/main/arm64/173623/Docker.dmg

Let me know if it works for you!

It still doesn't work! Here is the MySQL error log:

2024-11-08 10:15:37 2024-11-08 03:15:37+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.4.2-1.el9 started. 2024-11-08 10:15:37 2024-11-08 03:15:37+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql' 2024-11-08 10:15:37 2024-11-08 03:15:37+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.4.2-1.el9 started. 2024-11-08 10:15:37 '/var/lib/mysql/mysql.sock' -> '/var/run/mysqld/mysqld.sock' 2024-11-08 10:15:37 2024-11-08T03:15:37.613606Z 0 [System] [MY-015015] [Server] MySQL Server - start. 2024-11-08 10:15:37 2024-11-08T03:15:37.781200Z 0 [Warning] [MY-010915] [Server] 'NO_ZERO_DATE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be used with strict mode. They will be merged with strict mode in a future release. 2024-11-08 10:15:37 2024-11-08T03:15:37.783178Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.4.2) starting as process 1 2024-11-08 10:15:37 2024-11-08T03:15:37.784131Z 0 [Warning] [MY-013242] [Server] --character-set-server: 'utf8' is currently an alias for the character set UTF8MB3, but will be an alias for UTF8MB4 in a future release. Please consider using UTF8MB4 in order to be unambiguous. 2024-11-08 10:15:37 2024-11-08T03:15:37.785058Z 0 [Warning] [MY-010159] [Server] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive 2024-11-08 10:15:37 2024-11-08T03:15:37.792948Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started. 2024-11-08 10:15:37 2024-11-08T03:15:37.886289Z 1 [ERROR] [MY-013183] [InnoDB] Assertion failure: os0file.cc:2903:ret == -1 == 0 == 0 thread 281472885911296 2024-11-08 10:15:37 InnoDB: We intentionally generate a memory trap. 2024-11-08 10:15:37 InnoDB: Submit a detailed bug report to http://bugs.mysql.com. 2024-11-08 10:15:37 InnoDB: If you get repeated assertion failures or crashes, even 2024-11-08 10:15:37 InnoDB: immediately after the mysqld startup, there may be 2024-11-08 10:15:37 InnoDB: corruption in the InnoDB tablespace. Please refer to 2024-11-08 10:15:37 InnoDB: http://dev.mysql.com/doc/refman/8.4/en/forcing-innodb-recovery.html 2024-11-08 10:15:37 InnoDB: about forcing recovery. 2024-11-08 10:15:37 2024-11-08T03:15:37Z UTC - mysqld got signal 6 ; 2024-11-08 10:15:37 Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware. 2024-11-08 10:15:37 BuildID[sha1]=5f66d0d4617ec07a1aabe0ace693a79cf987adfc 2024-11-08 10:15:37 Thread pointer: 0x3defd8d0 2024-11-08 10:15:37 Attempting backtrace. You can use the following information to find out 2024-11-08 10:15:37 where mysqld died. If you see no messages after this, something went 2024-11-08 10:15:37 terribly wrong... 2024-11-08 10:15:37 stack_bottom = ffff8360e4b0 thread_stack 0x100000 2024-11-08 10:15:37 #0 0xb0a1d7 2024-11-08 10:15:37 #1 0x13f1e03 2024-11-08 10:15:37 #2 0x1577263 2024-11-08 10:15:37 #3 0x1d61e1b 2024-11-08 10:15:37 #4 0x14cd1bf 2024-11-08 10:15:37 #5 0x14f9613 2024-11-08 10:15:37 #6 0x1b8b327 2024-11-08 10:15:37 #7 0x14dc8eb 2024-11-08 10:15:37 #8 0x14df867 2024-11-08 10:15:37 #9 0x156a6f3 2024-11-08 10:15:37 #10 0x143e7b3 2024-11-08 10:15:37 #11 0x12b5983 2024-11-08 10:15:37 #12 0x12c1e2b 2024-11-08 10:15:37 #13 0xba955b 2024-11-08 10:15:37 #14 0x198c94b 2024-11-08 10:15:37 #15 0xffff918216b7 2024-11-08 10:15:37 #16 0xffff9188bc5b 2024-11-08 10:15:37 #17 0xffffffffffffffff 2024-11-08 10:15:37 2024-11-08 10:15:37 Trying to get some variables. 2024-11-08 10:15:37 Some pointers may be invalid and cause the dump to abort. 2024-11-08 10:15:37 Query (0): Connection ID (thread ID): 1 2024-11-08 10:15:37 Status: NOT_KILLED 2024-11-08 10:15:37 2024-11-08 10:15:37 The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains 2024-11-08 10:15:37 information that should help you find out what is causing the crash.

Diagnostics ID: CF2147DB-7708-440B-A53D-EB643D79CFA3/20241108031700

doringeman commented 2 weeks ago

Hello @thienanblog, @Lenitr,

Please give this one a go: https://desktop-stage.docker.com/mac/main/arm64/174463/Docker.dmg. I missed something in the previous one, sorry.

autaut03 commented 2 weeks ago

There's a weird issue I noticed after doing docker compose up and down a bunch of times: bind mounted containers would spit out No file descriptors available errors, even though the MacOS default limit is 1mil and even though containers would barely open a couple thousands of files.

The only thing that helped was restarting Docker completely, but doing a couple of (maybe 10-20 times) up/down cycles again quickly results in the same issue. I guess how quickly the issue occurs also depends on how many files containers open when they start.

Lenitr commented 2 weeks ago

Hello @thienanblog, @Lenitr,

Please give this one a go: https://desktop-stage.docker.com/mac/main/arm64/174463/Docker.dmg. I missed something in the previous one, sorry.

Thanks, will give it a go somewhere today or tomorrow, I haven't had chance to check your previous question (the command you shared), is that one still necessary to check with the new version? Or can I just check it with our project image?

azizur commented 2 weeks ago

After turning on the Docker VMM It completely broke my installation. I had to restart my mac then uninstall to recover from this.

lhaeger commented 1 week ago

It sounds like you want only some containers to be run with Docker VMM? Are the others running amd64 images?

Exactly. I have a couple of amd64 containers that are way too slow with qemu, so in order to test or switch to VMM, I'd need to limit that to certain VMs. Or the other way round: force Virtualization Framework for some VMs and use VMM as default.

doringeman commented 1 week ago

After turning on the Docker VMM It completely broke my installation. I had to restart my mac then uninstall to recover from this.

Hey @azizur,

Can you gather and upload diagnostics and quote the ID here? https://docs.docker.com/desktop/troubleshoot-and-support/troubleshoot/#diagnose-from-the-terminal

azizur commented 1 week ago

After turning on the Docker VMM It completely broke my installation. I had to restart my mac then uninstall to recover from this.

Hey @azizur,

Can you gather and upload diagnostics and quote the ID here? https://docs.docker.com/desktop/troubleshoot-and-support/troubleshoot/#diagnose-from-the-terminal

Unfortunately, there is no old logs to share. I used AppCleaner to clean everything.

If this happens again I'll sent it.

Lenitr commented 1 week ago

Hello @thienanblog, @Lenitr,

Please give this one a go: https://desktop-stage.docker.com/mac/main/arm64/174463/Docker.dmg. I missed something in the previous one, sorry.

Hey @doringeman ,

This version works 👍🏼 I can launch the Mysql container as usual now with a forced AMD platform and without. The reason I'm forcing AMD platform is because for some projects we're still using older Mysql versions that don't support ARM platforms (thank you legacy projects), so the quickest solution was to force the platform for all Mysql containers in our stack.

I'll do some more testing, the virtualisation is definitely slower with Qemu compared to Apple virtualisation (certain queries i run go from 25ms on Apple virtualisation with Rosetta, to 150ms with Docker VMM with Qemu for example), but the other containers in the stack can at least benefit from the speedboost of Docker VMM in that case.

We also have some projects that don't use Mysql, so in those cases we can really benefit from the improvements.

It sounds like you want only some containers to be run with Docker VMM? Are the others running amd64 images?

Exactly. I have a couple of amd64 containers that are way too slow with qemu, so in order to test or switch to VMM, I'd need to limit that to certain VMs. Or the other way round: force Virtualization Framework for some VMs and use VMM as default.

This would sound like an interesting option for me too, in case of containers that need emulation it might be better until there's an alternative for Qemu to run those containers on Apple virtualisation instead, but I can imagine that solution is probably not a small fix 😄 (sounds like it relates to docker compose more than docker desktop?)

mschoettle commented 1 week ago

running engine: waiting for the Docker API: engine linux/libkrun failed to run: running VM: krun: process terminated unexpectedly: exit status 2

Also getting this error.

Diagnosis ID: 8EB58138-9757-4CAF-9784-E4F771CF8BCE/20241112160317

doringeman commented 1 week ago

Hey @mschoettle,

You need to increase VM's memory from 2GB to 4GB. Also mentioned in https://github.com/docker/for-mac/issues/7464#issuecomment-2446688074.

We'll come up soon with a solution to improve this experience.

mschoettle commented 1 week ago

Thanks @doringeman. I deliberately decreased this in the past because Docker Desktop was using too much memory. I'll wait for the solution to improve this for now.

thienanblog commented 1 week ago

Hello @thienanblog, @Lenitr,

Please give this one a go: https://desktop-stage.docker.com/mac/main/arm64/174463/Docker.dmg. I missed something in the previous one, sorry.

Hi @doringeman,

It works now! I'll do some more testing.

nicholasruunu commented 1 week ago

Am I the only one having issues deleting files in Symfony projects, getting this error from Composer when running composer install:

In ClassMapGenerator.php line 160:
realpath of /app/src/GraphQL/Query/UniversePerformanceQuery.php failed to resolve, got false

Also phpstan:

Warning: sha1_file(/app/src/GraphQL/Query/UniversePerformanceQuery.php): Failed to open stream: No such file or directory in phar:///tools/.composer/vendor-bin/phpstan/vendor/phpstan/phpstan/phpstan.phar/src/Reflection/BetterReflection/SourceLocator/OptimizedDirectorySourceLocatorFactory.php on line 60

Fixes when switching back to Apple Virtualization.

doringeman commented 6 days ago

Hello everyone,

We released Docker Desktop v4.36.0, which also includes fixes addressing reports from this issue. Thank you for your valuable feedback!

doringeman commented 6 days ago

Hello @nicholasruunu,

I tried to reproduce the issue but was unsuccessful. Can you update to v4.36.0 to see whether it still occurs?

Lenitr commented 6 days ago

Hello everyone,

We released Docker Desktop v4.36.0, which also includes fixes addressing reports from this issue. Thank you for your valuable feedback!

Great 👍🏼 Thanks for the quick fixes, I'll switch back to stable release then

nicholasruunu commented 6 days ago

I tried to reproduce the issue but was unsuccessful. Can you update to v4.36.0 to see whether it still occurs?

Yes, still the same issue, I'll see if I could make some simple reproduction steps. But what I'm doing is renaming a class (and file) locally. Then running composer through docker run --rm -v .:/app composer/composer install

Lenitr commented 6 days ago

Am I the only one having issues deleting files in Symfony projects, getting this error from Composer when running composer install:

In ClassMapGenerator.php line 160:
realpath of /app/src/GraphQL/Query/UniversePerformanceQuery.php failed to resolve, got false

Also phpstan:

Warning: sha1_file(/app/src/GraphQL/Query/UniversePerformanceQuery.php): Failed to open stream: No such file or directory in phar:///tools/.composer/vendor-bin/phpstan/vendor/phpstan/phpstan/phpstan.phar/src/Reflection/BetterReflection/SourceLocator/OptimizedDirectorySourceLocatorFactory.php on line 60

Fixes when switching back to Apple Virtualization.

Just had something similar with a Laravel project, after switching branches in my project. A class no longer existed in the new branch, but for some reason composer still seems to expect it in it's old location when generating the class map. I suspect it might have something to do with the new file caching, since this wasn't an issue on Apple Virtualisation and I was able to resolve the issue with a simple reboot of the container.

nicholasruunu commented 6 days ago

Ok I managed to reproduce the bug pretty simply. Clone this repository (just normal symfony install with webapp and optimize-autoloader: true): https://github.com/nicholasruunu/docker-vvm-bug Jump in the folder and run docker compose up In the same folder run docker run --rm -v .:/app composer/composer install I rename the class src/Controller/TestAController.php in the editor to src/Controller/TestBController.php (class name too, don't know if that matter) Then run docker run --rm -v .:/app composer/composer install again.

In ClassMapGenerator.php line 160:
realpath of /app/src/Controller/TestAController.php failed to resolve, got false