Skip to content

Conversation

@aaronclarke
Copy link
Contributor

@aaronclarke aaronclarke commented Aug 16, 2024

Implementation for #30 :

The virtualization framework supports having multiple automounted volumes with different readonly vs readwrite statuses, as can be seen described in Apple's documentation for VZVirtioFileSystemDeviceConfiguration

But the current support for --vol only allows for one automounted volume. If two are specified, an error is thrown due to reusing the same VZVirtioFileSystemDeviceConfiguration.macOSGuestAutomountTag tag.

There is a method already in macosvm called addAutomountDirectoryShares:readOnly: which does know how to share describe multiple automounted directories, but it forces them all to have the same value for readOnly, and the code is currently unreachable.

Motivating example:

I want to start my VM with two automounted directories, one that is readonly so that the guest VM can't ruin it, and one that has readwrite capabilities so that the guest VM can write some data back to the host.

~/Desktop/macosvm -g \
--vol ~/Desktop/sharedWithVM/fromHost,ro,automount \
--vol ~/Desktop/sharedWithVM/fromGuest,automount \
macos_14.1/vm.json

Implementation:

I've hacked this together by making macosvm loop over the shares twice:

  1. Loop one: Loop over all shares
    • if share is an automount share and automounting is available, add it to a list of automount shares and continue
    • otherwise do normal share specifications
  2. Loop two:
    • Loop over all discovered automount shares. Batch each directory together into a single VZMultipleDirectoryShare and set that as the share for VZVirtioFileSystemDeviceConfiguration with the VZVirtioFileSystemDeviceConfiguration.macOSGuestAutomountTag tag.

Additionally, while editing this months ago, I had found myself getting lost multiple times when trying to follow the code's conditions and ifdefs because several blocks of the code were indented inconsistently across those boundaries and would look like they were different code blocks in my IDE. So I spent some time re-indenting the blocks that were giving me trouble.
I can undo that if you prefer.

The Virtualization framework support having multiple automounted shares with different readonly vs readwrite statuses. But all of the automount shares have to be specified as part of a single VZVirtioFileSystemDeviceConfiguration.
The current implementation of macosvm doesn't do that, as it would address each automount share individually, which means the first one would be allowed and the second would result in an error.
> validateWithError = Error Domain=VZErrorDomain Code=2 "More than one Virtio File System device uses the tag “com.apple.virtio-fs.automount”." UserInfo={NSLocalizedFailure=Invalid virtual machine configuration., NSLocalizedFailureReason=More than one Virtio File System device uses the tag “com.apple.virtio-fs.automount”.}

There is already a starting point for this with VMInstance.m's "addAutomountDirectoryShares", but it is unused, and would force that every automounted share must have the same readonly vs readwrite status.
So to fix this, I've split up the share configuration logic into two loops.
First loop over all shares. If there are any automount shares, add them to a second list and move on. Otherwise configure the share as normal.
Second loop is just over the automount shares that were found. It batches all of the automount directories into a single VZVirtioFileSystemDeviceConfiguration, which allows them to all be registered without error.
@aaronclarke aaronclarke reopened this Aug 16, 2024
@s-u
Copy link
Owner

s-u commented Aug 17, 2024

@aaronclarke thanks, this is a good idea, but, unfortunately, the PR completely messed up the sources. I had a look at your fork before, but couldn't use it for that reason. Please see if you can provide a clean PR, i.e., with only the changes that are necessary to add the feature, that would be highly appreciated. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants