Add support for snapshots

[JunBys]

I can't seem to find anything about a virtual machine container snapshot manager, which is readily available and available on vmware
This is also very important for my work, which means that I need to create snapshots for different moments of the virtual machine to restore to a certain node location when needed!
You should know what I'm talking about, I didn't explain otherwise

I've also looked through the historical issues and apparently haven't seen anyone making a similar request, would like to ask if this feature is of interest!
I'm new to github so please excuse me if I'm doing something wrong, thanks

[ideologysec]

#3893

[lnxbil]

I'm also missing this feature, yet I know how to do it manually, if you already have homebrew and qemu installed there:

• open the folder in which the virtual machine is (show in finder), right click the VM and show contents, change to Data subfolder. Open that in the Terminal.
• folder is usually something like this ~/Library/Containers/com.utmapp.UTM/Data/Documents/<VM Name>.utm/Data
• look for *.qcow2 files, that is the virtual disk (there may be more than one depending on your VM setup)
• runqemu-img to create and list the snapshot snapshot1

$ qemu-img snapshot F89035CE-DEF9-49D7-97F8-7EC0C2F3F9D9.qcow2 -c snapshot1

$ qemu-img snapshot F89035CE-DEF9-49D7-97F8-7EC0C2F3F9D9.qcow2 -l         
Snapshot list:
ID        TAG               VM SIZE                DATE     VM CLOCK     ICOUNT
1         snapshot1             0 B 2023-11-18 15:31:02 00:00:00.000          0

• do what you want to do with the VM
• revert back

$ qemu-img snapshot F89035CE-DEF9-49D7-97F8-7EC0C2F3F9D9.qcow2 -a snapshot1

[gitsnaf]

My virtual disks have the suffix img.

Creating a snapshot fails with:

WARNING: Image format was not specified for '95E3BDD3-62C7-4CA3-8FE1-BC046EBFC26A.img' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.
qemu-img: Could not create snapshot 'snapshot1': -45 (Operation not supported)

[lnxbil]

The snapshots I described only work with supported image types, e.g. qcow2. You may want to convert them to qcow2 to get all available features.

[gitsnaf]

Hm, after converting to qcow2 UTM doesn't find the image anymore. When I import the image file manually, then UTM tries to start the image but the window stays black. Die operating system inside the VM is not booting anymore.

[lnxbil]

How did you convert it? What does qemu-img info say about both images?

[gitsnaf]

$ qemu-img convert -f raw -O qcow2 95E3BDD3-62C7-4CA3-8FE1-BC046EBFC26A.img 95E3BDD3-62C7-4CA3-8FE1-BC046EBFC26A.qcow2

$ qemu-img info 95E3BDD3-62C7-4CA3-8FE1-BC046EBFC26A.img
image: 95E3BDD3-62C7-4CA3-8FE1-BC046EBFC26A.img
file format: raw
virtual size: 64 GiB (68719476736 bytes)
disk size: 17.9 GiB
Child node '/file':
    filename: 95E3BDD3-62C7-4CA3-8FE1-BC046EBFC26A.img
    protocol type: file
    file length: 64 GiB (68719476736 bytes)
    disk size: 17.9 GiB

$ qemu-img info 95E3BDD3-62C7-4CA3-8FE1-BC046EBFC26A.qcow2
image: 95E3BDD3-62C7-4CA3-8FE1-BC046EBFC26A.qcow2
file format: qcow2
virtual size: 64 GiB (68719476736 bytes)
disk size: 18.1 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false
Child node '/file':
    filename: 95E3BDD3-62C7-4CA3-8FE1-BC046EBFC26A.qcow2
    protocol type: file
    file length: 18.1 GiB (19473760256 bytes)
    disk size: 18.1 GiB

I also don't know how to create a new UTM VM with qcow2 as storage type.

[lnxbil]

Your virtual disk sizes are the same and everything looks like it should work.

I also don't know how to create a new UTM VM with qcow2 as storage type.

I don't know either, my default was qcow2, as I thought it would be and should be with QEMU.

This is my disk-part of the configuration, does it look the same or are there any other values?

	<key>Drive</key>
	<array>
		<dict>
			<key>Identifier</key>
			<string>F89035CE-DEF9-49D7-97F8-7EC0C2F3F9D9</string>
			<key>ImageName</key>
			<string>F89035CE-DEF9-49D7-97F8-7EC0C2F3F9D9.qcow2</string>
			<key>ImageType</key>
			<string>Disk</string>
			<key>Interface</key>
			<string>VirtIO</string>
			<key>InterfaceVersion</key>
			<integer>1</integer>
			<key>ReadOnly</key>
			<false/>
		</dict>
	</array>

[gitsnaf]

That is mine:

<key>Drive</key>
	<array>
		<dict>
			<key>Identifier</key>
			<string>363D013C-D19F-44B7-8079-82EA063BB118</string>
			<key>ImageName</key>
			<string>95E3BDD3-62C7-4CA3-8FE1-BC046EBFC26A.qcow2</string>
			<key>ReadOnly</key>
			<false/>
		</dict>
	</array>

Because of the ID difference I created a new clone from a working vm and then without starting UTM I edited the config.plist und changed only the ending from .img to .qcow2 for the ImageName-Value. But it was not working.
Then I added your lines, that means the keys ImageTyp, Disk and VirtIO. But again it did not work.

[lnxbil]

I just tried to setup a raw diskimage I just downloaded and it gets automatically converted by the GUI to qcow2 and boots up fine. You said you tried to import the image manually? Please copy the original img image outside, rename it to .raw and import the disk via the GUI (add new disk) and see if it also gets converted to qcow2.

Are you on the newest UTM app version?

[gitsnaf]

I did what you said but the file was not converted to to qcow2. UTM just copied the raw-File from the import location to the VM location.

[gitsnaf]

https://docs.getutm.app/settings-qemu/drive/drive/ says:

When importing a drive that is non-removable and not a raw image, the selected image will first be converted to the QCOW2 format.

So we cannot expect a conversion to qcow2 when importing a raw-image.

I'm using UTM 4.3.5. I will check for an update.

Update:
I updated to UTM 4.4.4 but nothing changed. No qcow2-conversion when importing from a raw-file.