Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/multiple automount #35

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

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