Shared VM Storage is Available in Orka 1.6

Beginning with the Orka 1.6.0 release, shared VM storage will be available on all Mac VMs in Orka. This means that all VMs will have in-network access to shared storage, which is intended to support artifact caching between build stages, Xcode installers, and other self-hosted build requirements that call for secure, but easily accessible storage from within your CI/CD workflow designed to run on certified Apple hardware.

Orka’s shared storage solution consists of a Kubernetes shared volume that can be manually mounted onto a given Mac VM or auto-mounted at system boot. This is possible because the terminal command that mounts the shared storage is executed from within the Mac VM itself.

Primary and Secondary Storage Solutions

By default, Orka VMs will have access to a Kubernetes volume that lives on the primary network file system (NFS) storage export for your Orka environment’s underlying Kubernetes cluster. This means that shared storage data will live alongside stored VM images and ISOs, which can be a limiting factor for teams with large amounts of one or both.

For teams that require additional storage capacity, it is recommended that a secondary, dedicated storage export be provisioned that will house your shared storage data only.

Mounting Shared Storage from within a VM

In order to mount and access the shared storage at /Volumes/orka within a VM, run:

sudo mount_9p orka

Automount Shared Storage at VM Startup

To automate the above process such that it will run at machine boot, create the file /Library/LaunchDaemons/com.mount9p.plist and paste the following into the body:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>Label</key>
 <string>com.mount9p.plist</string>
 <key>RunAtLoad</key>
 <true/>
 <key>StandardErrorPath</key>
 <string>/tmp/stderr.log</string>
 <key>StandardOutPath</key>
 <string>/tmp/stdout.log</string>
 <key>EnvironmentVariables</key>
 <dict>
   <key>PATH</key>
   <string><![CDATA[/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin]]></string>
 </dict>
 <key>ProgramArguments</key>
 <array>
   <string>mount_9p</string>
   <string>orka</string>
 </array>
</dict>
</plist>

Once you have created the above file, you’ll need to change the permissions on it by running:

sudo chown root:wheel /Library/LaunchDaemons/com.mount9p.plist
sudo chmod 600 /Library/LaunchDaemons/com.mount9p.plist

Finally, reboot the virtual machine for changes to take effect, and then save or commit the VM image for future use.

NOTE: With Big Sur, it is also necessary to manually mount the share with sudo mount_9p orka as described in the previous section once after going through the above steps. The share will then be automounted on all subsequent system boots.

TL;DR

In-network, shared storage will be available for all Mac VMs running in Orka 1.6.0. This will simplify macOS and iOS CI/CD workflows that call for caching build artifacts and self-hosting build requirements, such as Xcode installers. In its default mode, shared storage data will live alongside stored VM images and ISOs; however, a secondary, dedicated, shared storage solution can be provisioned.

Want to learn more about Orka? Check out all of the great things in our latest release in our Orka 1.6.0 release notes. Do you have any great ideas for future Orka features? If so, let us know through the Orka Ideas Portal. And if you are not a current Orka user, you can give Orka a try with a free two-hour Orka demo environment.