AVF VM: removable storage switches to read-only after relaunch of UTM

[galaxy4public]

Describe the issue
On a virtualised VM, my home disk is attached as a removable drive. Everything works fine up until I shutdown the VM and quit UTM. Once UTM is restarted, the removable disk in VM's settings becomes "read-only" and if you try to remove the checkbox and "Save", UTM reports that it does not have permission to do so. The only work around I found so far is to remove the removable drive from VM and instantly re-add it back as read-write.

Configuration

• UTM Version: 4.1.6 (75)
• macOS Version: 13.3
• Mac Chip (Intel, M1, ...): M2

[narukeu]

I tried to the operation you described, but I didn't find that the removable disk can also have the "read-only" option. I use the latest version of UTM. Did you import the removable disk image as the "internal" hard drive?

If not, you need to check whether there is any program occupying your disk image, making the operation unavailable. Because I found Apple virtualization framework may still "occupy" my virtual disk image , although the virtual machine is shut down.

[galaxy4public]

I am not sure what you are referring to. By the nature of "removable" drives, you cannot "import" them. When you add a new drive and click on the "removable" checkbox, the "Import" button is replaced by "Browse". This issue is about UTM's metadata -- UTM marks a read/write removable drive in VM's settings as read-only on shutdown (or something around this). It has nothing to do with the content of the drive itself or with whatever is using it. As I described in the issue, it is fixable by just removing and re-adding the drive in the VM's settings screen, but it is inconvenient.

[narukeu]

When I add a removable disk device in UTM, the device really cannot be set as "read-only". Because there is no such option.

[galaxy4public]

You are working with Qemu, this issue is for AVF (Apple Virtualisation Framework)

[narukeu]

Sorry, I didn't see it was AVF before.

I tried you action again and found that after restarting UTM , the removable device also becomes read-only and the OS cannot write to the device, I'm sure this is a bug.

[narukeu]

Hello,
When I created an Armbian virtual machine (based on QEMU) today, I found that the operating system cannot write to the virtual disk. I thought it was a problem with the virtual disk, but after my research I think it's not a bug as you said, rather than a corrupted virtual disk image, and containerized UTM applications can't access files outside the container. As a result of modification, it does not have this permission to modify files outside the container.

Therefore, the virtual machine will force the virtual disk mirroring option to "read-only" after it is reopened.

[narukeu]

#4574 also mentioned this problem, and after my test, allowing UTM to have full disk permissions in macOS settings also does not enable UTM to change external virtual disks.

The question you mentioned also bothers me.

[galaxy4public]

Hello, When I created an Armbian virtual machine (based on QEMU) today

@narukeu , please do not bring Qemu issues here. The way how UTM handles these technologies (AVF and Qemu) is very different. In case of AVF (this issue), there is a bug and the attached disk image is becoming read-only in spite of the user configuration.

[osy]

This is the intended behaviour. There is no way to “convert” a removable drive to a “real” drive and vice versa. However, it’s quite easy to remove the drive and create a new one.

[galaxy4public]

@osy , I honestly do not understand your reasoning. This issue is not about "converting" (whatever it means), but the strange behaviour: a user defines a VM and adds a removable drive to it (think of a virtual USB) which is writable. The VM successfully starts and works with the defined device. You can also shutdown the VM and then start it again -- the removable drive behaves as expected. Now, if you shutdown UTM and start it again, suddenly the VM configuration changes and the user-defined devices becomes "read-only". This is definitely not a good user experience since there is no real reason why the application applies an unrequested change.

It would be understandable if, for example, the only configuration that was supported was read-only removable drives, but it is not. The read-write ones are perfectly fine, it is just that UTM cannot handle preserving the state, it seems.

Could you please elaborate a bit more on the topic, so there is no confusion, please?

[galaxy4public]

I've re-read you comment and it seems you are implying that Apple has some limitations on re-using previously attached read-write removable devices after full shutdown or something like that (I am guessing here). Even if this is the case, this issue is not about the underlying technology, but UTM's user experience. UTM maintains a VM configuration file (and it is more extensive than what's AVF requires since UTM also supports Qemu). Now, it seems to me, that to facilitate better user experience some logic could be added to UTM to automatically re-provision any read-write removable drives defined in the VM configuration, so it would be transparent to the user.

I have not looked deep enough to determine whether it is indeed Apple's limitation, but from the observations described above (starting/stoping a VM with a read-write removable attached is fine and the only moment when it becomes read-only is when UTM is stopped and started again) it seems not to be an Apple limitation, but UTM's.

[galaxy4public]

Also, the use case, I think, many would find lucrative is to be able to attach a shared volume to several VMs (like in my case, I am attaching the same home drive as a removable to multiple VMs so I get the same user environment across different Linux VMs I am running), this is super convenient and has multitude of nice positive traits to it (e.g. the volume I am attaching to my VMs is a network block device delivered over iSCSI.

[galaxy4public]

I just did a little test:

1. created an AVF VM
2. stopped UTM (just to be sure the experiment is clean)
3. started UTM
4. Right clicked on the VM, selected Edit, and added a removable drive.
5. stopped UTM (I did not launch VM!)
6. started UTM again
7. Right clicked on the VM, selected Edit, and observed that the drive became "Read-only"

This is definitely an UTM issue since AVF is not even invoked here. Moreover, there is something fishy going on with the whole configuration file state maintenance since, for example, the Fullscreen state of the VM is also not preserved, but this may have never been implemented in the first place :).

[galaxy4public]

For now, I found another workaround that does not require me to delete/re-create the volume:

1. I created a standard volume using UTM (UTM generated UUID based name for it)
2. went into ~/Library/Containers/com.utmapp.UTM/Data/Documents/<VM name>.utm and edited the config.plist by replacing the UUID based name and file name to Home and home.img
3. created a symbolic link to the image I want to be shared across VMs (e.g. ln -s /Volume/somewhere/some/path/image.dmg ~/Library/Containers/com.utmapp.UTM/Data/Documents/<VM name>.utm/Data/home.img)
4. stopped and then started UTM (to ensure the environment is sane for the experiment)
5. launched a VM -- the drive was successfully mounted despite it is a symlink pointing outside the sandbox :)

The only downside is that it is not a removable drive and you cannot easily change it through the UI. Also, this does not solve the bug in UTM which is, I believe, in the logic how UTM reads the config.plist file -- when it stumbles upon a dictionary in under the Drive key which describes the removable drive there is no logic to save or retrieve the ReadOnly key -- UTM just assumes that if it is a drive with no image provided, it is "read-only", which is wrong.

@osy , since I investigated and pinpointed the root cause and it is indeed a bug (or a deficiency :) ) of UTM, could we please re-open the issue, so it will eventually be fixed (e.g. by actually storing and retrieving the ReadOnly key associated with the removable drives for AVF VMs? Thanks!

P.S. Also, you may re-use the trick I described above to add drives outside of the sandbox to VMs via UI (it will require maintaining a symbolic link, however, but this should be quite transparent and the users will be grateful of the option to be able to attach external drives through UI).