VMs freezing every 10s

[floorish]

My macOS VMs are repeatedly freezing for 2 seconds. I get a spinning beach ball for a moment and after that everything works fine again for about 10 seconds until the next 2s freeze. This happens for every macOS guest (Monterey/Ventura/Sonoma) on a Ventura host.

I've tried setting up the exact same .ipsw with same cpu (4) & mem (6) settings using UTM and the freezing does not occur there.

The freezing is less when the vm is stored on the internal SSD vs external SSD, which might suggest an IO issue. The guest does not seem to write any data, but the host app does write ~200MB every 10 seconds, which matches exactly with the freezes.

In the same UTM vm these writes do not happen, so it looks like this is specific to the VirtualBuddy implementation.
The issue is also less noticeable with VirtualBuddy v1.2.2, that seems to write a smaller amount of data (~50MB).

What exactly is being written to disk and could that be the cause for freezes inside the guest?

VirtualBuddy Version 1.3.2 (107)
Output of iostat -d -w 1 on the host while vm is running:

 KB/t  tps  MB/s
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 8.00    2  0.02
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
10.00    4  0.04
63.37  965 59.71 <-- freeze
63.55 1475 91.54
24.60  802 19.28
 0.00    0  0.00
 6.67    3  0.02
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 6.08   52  0.31
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 6.41  288  1.80
21.04  264  5.42
63.82 1328 82.76 <-- freeze
63.58 1294 80.35
61.59   58  3.47
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
29.78    9  0.26
 9.00    4  0.04
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
62.57 1135 69.38 <-- freeze
63.35  839 51.91
39.32 1356 52.05
 0.00    0  0.00
 4.53   15  0.07
 4.00   17  0.07
 5.00    4  0.02
24.50    8  0.19
 4.87   69  0.33
 4.73   11  0.05
 0.00    0  0.00
55.94 1626 88.85 <-- freeze
63.57 1145 71.08
62.92  191 11.74
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00
 0.00    0  0.00

[insidegui]

The only thing I can think of is the screenshotting process. It's configured to take a screenshot of the VM every 15 seconds for updating the image in the VM gallery.

I haven't seen this cause huge disk writes before. What's the screen resolution for your VM?

There's no hidden flag to disable the screenshotting at the moment, but I can think of several ways we could optimize it in case it's the culprit.

[floorish]

Thanks for the info! Just checked: the .tiff is 168MB so that could indeed be related. The vm resolution is 5120x2880.

Version 1.2.2 writes ~50MB, so significantly less. I'll try to disable the screenshotter and will report back if that helps.

[floorish]

Disabling the screenshotting process indeed fixes the freezes 😄

Few things I noticed:

1. I think the 2s freeze happens mainly due to writing the data on the main thread in VMController.storeScreenshot()

Writing on the background queue significantly reduces the freezes, but there is still a quick hitch in the vm every 15s. I guess that is due to capturing the screenshot itself, but haven't verified that.

2. Due to writing ~200MB every 15s, VirtualBuddy writes 60*60/15 * 0.2 = 48GB per hour — that's a bit much :)

As far as I can see the screenshot is only used for the creation of the thumbnail and as background of the VMScreenshotBackgroundView. The latter uses a background blur anyway — I think replacing the background with the thumbnail instead of the full size screenshot still looks fine. That way you don't have to write the large screenshot, only the thumbnail.

3. Personally I don't really mind real time screenshots — if I understand correctly v1.2.2 only created a screenshot on terminating the vm. If the hiccup due to screenshotting (see point 1) cannot be solved (I'm not sure if you can capture the view.layer on a bg thread), then I'd prefer an option to only create a screenshot on close instead of every 15 seconds.

Cheers!

[insidegui]

I think it'd be fine to only screenshot on first boot and then on termination. This can me made 100% better by leveraging VirtualBuddyGuest, now that it's properly integrated and easy to install. Instead of having the host snapshot the VM view itself (which is kind of a hack), the guest app could send a thumbnail upon initial startup and another one once the machine is about to be terminated.

[floorish]

Sounds perfect! VirtualBuddyGuest also works very well, I'm really enjoying the app overall.