vz: use DiskImageCachingModeCached (rumored to fix disk corruption on ARM)

[AkihiroSuda]

Switch away from DiskImageCachingModeAutomatic to DiskImageCachingModeCached, as this is rumored to fix disk corruption on ARM

• Apple Virtual machine keeps setting itself as read-only utmapp/UTM#4840 (comment)
• Apple Virtual machine keeps setting itself as read-only utmapp/UTM#4840 (comment)

Expected to fix issue #1957 (for vz)

[AkihiroSuda]

Merging, for ease of testing

[hasan4791]

Seems to be working good so far. Will monitor for a week atleast. 👍🏽
Template being used is "podman-rootful".

[rpkoller]

I've got notice of this issue in there #1957 . I am using Colima and since the release of Colima 0.6.0 i ran into VMs that got corrupted all of a sudden. At first my suspicion was the root cause was in the changes for 0.6.0 but yesterday i'Ve started to test in plain Lima and today I ran into the same issue. After finding this issue i've updated to HEAD as well. I am already testing for a few hours now and no issues so far. Will also keep testing the coming days. But this looks promising so far. Cuz under Lima the error sometimes happened after starting a single project in a completely newly generated instance. But since the upgrade to head it looks good. I am using the template "Docker". Thank you for spotting this!

Update: I am using the HEAD version extensively for the last four days and not ran into a single issue. With the changes in this PR everything works like a charm.

[EdwardMoyse]

As noted on #1957 this seems to be helping me - no corruptions w/ vz VM since I moved to HEAD (and it was happening hourly before).

[balajiv113]

@AkihiroSuda I believe this change will have disk io performance issues.

We will see a reduced disk io performance

[balajiv113]

Should we think of providing a option to switch over to older model for those who prefers performance over stability ?

[AkihiroSuda]

I guess nobody wants disk corruption?

[balajiv113]

If am not wrong this corruption is happening only on ARM. This change will now degrade performance for intel users as well.

[balajiv113]

We can go ahead. If someone complaints on performance we can re-evaluate at that point.

[rpkoller]

I've done some performance testing based on the following puppeteer script https://github.com/ddev/ddev-puppeteer created by @rfay for testing the actual performance of the different docker providers (orbstack, docker desktop, rancher desktop and colima) with DDEV for the following blog post https://ddev.com/blog/docker-performance-2023/. Based on the protocol I've tested with Lima 0.18.0 as well as HEAD-a8c703b on my m1pro with 32gb of ram. I've tested with a profile with 4 cpus and 8gb ram and 20gb of diskspace assigned.

Colima 0.6.6 - Lima 0.18.0 - Mutagen enabled
installtime: 20.025s

Colima 0.6.6 - Lima 0.18.0 - Mutagen NOT enabled
installtime: 31.543s

Colima 0.6.6 - Lima HEAD-a8c703b - Mutagen enabled
installtime: 19.520s

Colima 0.6.6 - Lima HEAD-a8c703b - Mutagen NOT enabled
installtime: 31.047s

from my none developer point of view i think there is no performance malus with this PR, it is even slightly faster. But overall it there is no significant difference at all anyway. just thought the results might be relevant and of interest in the context of this issue.

[balajiv113]

@rpkoller Thanks for verifying this.

We should be good in that case 👍