Apple virtualization path
SlateVM constructs and validates configurations for compute, memory, storage, entropy, graphics, input, networking, shared directories, and OS-specific boot requirements.
Technology
One application. Purpose-built virtualization paths.
SlateVM coordinates persistent VM bundles, native Apple virtualization, a focused Windows runtime, local consoles, networking services, and structured automation as one coherent Mac application.
System architecture
Clear owners from interface to guest.
The SwiftUI application owns the VM library and lifecycle. Human actions flow directly through the app; MCP-compatible clients enter through a local adapter and control hub, then converge on the same stores and runtime owners.
flowchart TB HUMAN["Human operator"] --> UI["SlateVM SwiftUI application"] AGENT["MCP-compatible AI client"] --> MCP["slatevm-mcp adapter"] MCP -->|"local Unix socket"| HUB["SlateControlHub"] UI --> STORE["VMStore · persistent library"] UI --> WM["MacVMWindowManager · lifecycle owner"] HUB --> STORE HUB --> WM STORE --> BUNDLE["Per-VM bundle
configuration · disks · media state"] WM --> ROUTE{"Guest family"} ROUTE -->|"macOS · Linux"| VZ["Apple Virtualization.framework"] ROUTE -->|"Windows 11 ARM"| WIN["WindowsVMController
QEMU + Hypervisor.framework"] UI --> NET["SlateVM networking service"] WM --> NET VZ --> GUEST1["macOS / Linux guest"] WIN --> GUEST2["Windows guest"]
Execution engines
The right backend is selected deliberately.
flowchart LR
CONFIG["Validated VM configuration"] --> FAMILY{"Operating system"}
FAMILY -->|"macOS"| MAC["VZMacPlatformConfiguration
restore image · Mac devices"]
FAMILY -->|"Linux"| LINUX["VZGenericPlatformConfiguration
ISO / cloud-init · virtio devices"]
FAMILY -->|"Windows 11 ARM"| WINDOWS["Pinned QEMU runtime
UEFI · TPM · virtio topology"]
MAC --> VZ["VZVirtualMachine"]
LINUX --> VZ
WINDOWS --> HVF["Hypervisor.framework acceleration"]
VZ --> NATIVE["Framework-native console"]
HVF --> SPICE["Local SPICE console"]
Windows runtime path
SlateVM verifies its runtime components, builds the required QEMU topology, provisions firmware and drives, and gives the resulting guest a dedicated controller and console owner.
Configuration and lifecycle
Create with intent. Refine as requirements change.
SlateVM gathers the parameters each guest needs—identity, operating system and media, CPU, memory, storage, display, network mode, and supported integrations—then validates them against the selected engine and host before creating the VM bundle. Editable settings return to that same persistent record, keeping later changes connected to the VM they govern.
sequenceDiagram participant User participant App as SlateVM application participant Store as VMStore participant Jobs as Creation / job coordinator participant Engine as Selected VM engine User->>App: Provide name, OS/media, CPU, memory, disk, display, network App->>App: Validate configuration and host capability App->>Store: Create per-VM bundle and persist configuration App->>Jobs: Begin OS-specific creation Jobs-->>App: Publish stage-aware progress Jobs->>Engine: Restore, install, or provision Engine-->>App: Runtime state and console App->>Store: Persist installation and hardware state User->>App: Stop and update editable VM settings App->>App: Revalidate the revised configuration App->>Store: Persist updates to the same VM bundle User->>App: Start, diagnose, or remove
Console architecture
Two local display paths, one focused experience.
flowchart TB
WINDOW["SlateVM console window"] --> FAMILY{"Guest backend"}
FAMILY -->|"macOS · Linux"| VZVIEW["VZVirtualMachineView"]
FAMILY -->|"Windows 11 ARM"| OWNER["WindowsConsoleOwner"]
OWNER --> SOCKET["Local Unix-socket SPICE channels"]
SOCKET --> METAL["WindowsMetalView"]
INPUT["Keyboard · pointer · clipboard"] --> VZVIEW
INPUT --> OWNER
VZVIEW --> DISPLAY1["Framework-native guest display"]
METAL --> DISPLAY2["Metal-backed Windows display"]
CAPTURE["Console capture and automation input"] --> VZVIEW
CAPTURE --> OWNER
Networking architecture
Simple by default, capable when topology matters.
Network mode is a per-VM choice: NAT or Bridge. NAT provides the shortest path to guest connectivity, isolated on a private subnet. Bridge puts the guest directly on the LAN with its own address, moving host-network preparation into SlateVM’s dedicated service architecture and keeping elevated responsibilities separate from the sandboxed application experience.
flowchart LR
VM["Per-VM network configuration"] --> CHECK["Readiness and duplicate-MAC checks"]
CHECK --> MODE{"Selected mode"}
MODE -->|"NAT"| NAT["Native VZNAT or socket_vmnet service"]
MODE -->|"Bridge"| SERVICE["SlateVMNetworkingService daemon"]
SERVICE --> BRIDGE["routed_bridge — guest on the LAN"]
NAT --> ENGINE["Resolved adapter for selected VM engine"]
BRIDGE --> ENGINE
ENGINE --> GUEST["Guest network interface"]
NAT mode
The low-friction default keeps the guest on a private subnet with internet access. It runs over Apple’s native VZNAT with no helper, or through the sandboxed socket_vmnet service path when selected (Linux) or required (Windows).
Bridge mode
Puts the guest directly on the LAN with its own address, via the dedicated SlateVMNetworkingService daemon and its routed_bridge component — reachable by other devices and by the host in both directions. Install and uninstall packages give that service lifecycle an explicit operational boundary.
Launch-time readiness
SlateVM checks service readiness, adapter state, and duplicate MAC addresses before handing a resolved network configuration to Apple Virtualization or the Windows runtime.
Guest integration
Shared folders, security-scoped media, guest tools, clipboard channels, consoles, and SSH-based commands connect host workflows to each guest through purpose-built interfaces.
One application-owned control plane
The UI and the agent operate the same machine.
SlateVM does not bolt AI onto a shell wrapper or a second management stack. A person in the SwiftUI app and a compatible AI agent enter the same application-owned control plane, reach the same VM records and lifecycle owners, and observe the same resulting state.
flowchart LR PERSON["Human operator"] --> UI["SlateVM SwiftUI UI"] CLIENT["Compatible MCP client"] -->|"stdio JSON-RPC"| ADAPTER["slatevm-mcp"] ADAPTER -->|"local control socket"| HUB["SlateControlHub"] UI --> STORE["VMStore + lifecycle owners"] HUB --> STORE HUB --> CAP["Host capabilities"] HUB --> LIFE["Create · inspect · start · stop"] HUB --> JOBS["Jobs · progress · diagnostics"] HUB --> CONSOLE["Capture · keyboard · pointer · text"] HUB --> GUEST["Networking · guest commands"] CAP --> STORE LIFE --> STORE JOBS --> STORE CONSOLE --> STORE GUEST --> STORE STORE --> VM["SlateVM-owned VM records and runtimes"]
Provision, then keep working
Creation is the beginning of the workflow. An agent can wait for provisioning, boot the guest, inspect exact lifecycle state, discover networking, and continue operating the VM after installation.
Observe, act, verify
Console capture, OCR, direct serial text for headless Linux, guest input, SSH where provisioned, and diagnostics give an agent multiple ways to understand a machine, act inside it, and verify the result.