UTM
UTM copied to clipboard
"Run without saving changes" still modifies VM components, making it hard to recall if the VM had been modified or not
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
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.
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?