"Run without saving changes" still modifies VM components, making it hard to recall if the VM had been modified or not

[jamesmortensen]

Describe the issue

The "Run without saving changes" feature is great for situations where we want to inspect the contents of a VM without making changes. When using QEMU, I use the -snapshot argument, and I assumed UTM is utilizing it as well.

One way I can tell if I've made changes to a VM or not is whether or not the file and folder modification dates have changed. With QEMU, literally nothing gets touched, so the folder timestamp remains the same.

But with UTM, I can see the following items were changed:

• view.plist
• Nothing appeared to be changed in the Images folder, but the timestamp of the folder was bumped nonetheless.

In order to keep straight which VM's have been modified, it would be helpful for the "Run without saving changes" option to behave more like QEMU and not make any changes to any of the underlying resources.

Configuration

• UTM Version: 3.2.3 (Sorry, I generally try to stay up to date. I checked 3.2.4 release notes and no mention of this fix.)
• macOS Version: 12.4
• Mac Chip (M1):

Details:

VM I hadn't touched since Jul 17 2021:

$ ls -ltr
drwxr-xr-x@ 5 james  staff  160 Jul 17  2021 Ubuntu 20.04.2 LTS.utm

After starting the VM with the "Run without saving changes" option, I see this:

$ ls -ltr
drwxr-xr-x@ 5 james  staff  160 Aug 24 10:06 Ubuntu 20.04.2 LTS.utm

and within the VM UTM folder:

$ l
total 16
-rw-r--r--@ 1 james  staff  2284 Jul 17  2021 config.plist
drwxr-xr-x@ 4 james  staff   128 Aug 24 09:48 Images
-rw-r--r--@ 1 james  staff   593 Aug 24 10:06 view.plist

and the Images folder:

$ l
total 13281160
-rw-r--r--@ 1 james  staff  6799622144 Jul 17  2021 disk-0.qcow2
-rw-r--r--@ 1 james  staff      329216 May 13 11:15 efi_vars.fd

Nothing obvious was changed in here. The qcow2 drive is still unmodified. I'm not sure why efi_vars has May 13th as the date but it seems to also not have been modified.

QEMU, however, appears to respect the data folders timestamps and does not modify anything, so it's super clear later on that the VM had not been modified:

$ ps aux|grep qemu
james            18762 146.8  1.5 414493680 244160 s001  R+   10:34AM  91:35.51 qemu-system-aarch64 -M virt -accel hvf -cpu host -snapshot -smp 4 -m 4G -vga std -device ramfb -device qemu-xhci -device usb-kbd -device usb-tablet -rtc base=localtime,clock=host -drive if=pflash,format=raw,file=FreeBSD-13.1-arm64/efi.img,readonly=on -drive if=pflash,format=raw,file=FreeBSD-13.1-arm64/varstore.img -drive file=FreeBSD-13.1-arm64/FreeBSD-13.1-RELEASE-arm64-aarch64.qcow2,if=none,id=boot,cache=writethrough -device nvme,drive=boot,serial=boot -device intel-hda -device hda-duplex -netdev user,id=mynet0 -device rtl8139,netdev=mynet0
james            20299   0.0  0.0 408628368   1632 s000  S+   11:13AM   0:00.00 grep qemu
james@home ~/Downloads/FreeBSD-13.1-arm64
$ l
total 21501320
-rw-r--r--  1 james  staff      2097152 Sep 11  2021 QEMU_EFI.fd
-rw-r--r--  1 james  staff     67108864 Jun 22 21:18 efi.img
-rw-r--r--  1 james  staff          739 Jun 22 21:23 freebsd-vm.sh
-rw-r--r--  1 james  staff     67108864 Jun 22 21:23 varstore.img
-rw-r--r--  1 james  staff  11003691008 Jun 22 22:00 FreeBSD-13.1-RELEASE-arm64-aarch64.qcow2
james@home ~/Downloads/FreeBSD-13.1-arm64

$ l Downloads/
drwxr-xr-x   8 james  staff        256 Jun 22 23:28 FreeBSD-13.1-arm64

[osy]

I'm not sure what exactly is happening to the Images timestamp but view.plist is going to be gone in the next UTM 4.x so that shouldn't be a problem anymore.

[jamesmortensen]

Yeah, considering nothing in Images is modified, it is odd that the folder tinestamp is updated. I may be able to play with this more and see if I can figure out what's happening. Also, if the view.plist is going away then that might solve the problem?