Design Notes
These essays explain Barn’s state model, guest convergence, image trust, host networking, CLI contracts, and native Mac lifecycle. Design proposals also examine the Pigsty/Vagrant development loop, Windows hosting, and future guest architectures; each proposal states its implementation and validation status.
The native macOS Virtualization.framework subsystem (barn mac) was introduced in Barn 0.9.0; its signed app has shipped in Apple Silicon archives since 0.9.2. See Native macOS VMs, the barn mac Reference, and the Mac release handbook.
Barn 1.2.0 release readiness and acceptance
Release gates, upgrade compatibility, packaging, and physical-host acceptance for Barn 1.2.0.
In-place root growth: recovery and native acceptance
The grow-only resize -D contract, offline and guest expansion, failure recovery, and ext4/XFS native acceptance.
VM specification parameters: commands, short flags, environment, and root disks
A unified CLI, environment, inventory precedence, command scope, and persistence contract for image, architecture, CPU, memory, scale, and root disk size.
Pigsty host setup: fixed names and CA trust
A small, explicit macOS and Linux setup operation for stable Pigsty portal names and the lab's root CA.
Main and command reference review
Git state, version boundaries, command coverage, and validation evidence from the 2026-11-11 Barn review.
Host DNS and domain resolution for Pigsty on Barn
An explicit hosts workflow, Pigsty-owned name semantics, source replacement safeguards, and an optional split-DNS upgrade path for macOS and Linux.
Replacing Vagrant with Barn in Pigsty: resources, names, and migration work
An audit of Pigsty's Vagrant workflow, the vm_scale and local hosts contracts, and an ordered migration plan based on 54 inventory templates.
Beyond amd64 and arm64
How guest architecture selects an emulator, machine, firmware, devices, and acceptance tests in Barn.
Running Barn from Windows
Why a Linux host remains necessary, what WSL2 must prove, and what a native Windows backend would require.
What Barn Can Learn from Vagrant
A proposal for repeatable provisioning, environment records, file transfer, and recovery in Pigsty labs.
From Upstream Images to a Signed Catalog
How Barn separates upstream release metadata, catalog evidence, runtime support, and release acceptance.
Evolving the CLI Without Breaking Its Contracts
What to preserve when separating Barn's command tree, application orchestration, and output handling.
The Lifetime of a Native Mac VM
Why Barn uses named Mac machines, process-owned networks, narrow locks, and explicit recovery evidence.
repo.yaml Is Intent; catalog.json Is Evidence
Why Barn separates human-authored image policy from generated metadata that must match the actual qcow2 artifacts.
A PID Is Not a Virtual Machine
Why Barn combines QMP identity, process evidence, typed invocations, and journals before it signals or deletes anything.
Declarative Does Not Mean Destructive
How Barn uses per-node hashes and explicit operations so missing configuration can never authorize deletion.
Why Every Barn Node Has Two NICs
Why Barn separates management egress from the fixed-address network used by the host, peers, Ansible, and Pigsty.
Why Barn Has No Projects
Why Barn replaced per-directory project state with one owner-scoped deployment driven by one Pigsty inventory.
Barn 1.2.0 release readiness and acceptance
Release gates, upgrade compatibility, packaging, and physical-host acceptance for Barn 1.2.0.
In-place root growth: recovery and native acceptance
The grow-only resize -D contract, offline and guest expansion, failure recovery, and ext4/XFS native acceptance.
VM specification parameters: commands, short flags, environment, and root disks
A unified CLI, environment, inventory precedence, command scope, and persistence contract for image, architecture, CPU, memory, scale, and root disk size.
Pigsty host setup: fixed names and CA trust
A small, explicit macOS and Linux setup operation for stable Pigsty portal names and the lab's root CA.
Main and command reference review
Git state, version boundaries, command coverage, and validation evidence from the 2026-11-11 Barn review.
Host DNS and domain resolution for Pigsty on Barn
An explicit hosts workflow, Pigsty-owned name semantics, source replacement safeguards, and an optional split-DNS upgrade path for macOS and Linux.
Replacing Vagrant with Barn in Pigsty: resources, names, and migration work
An audit of Pigsty's Vagrant workflow, the vm_scale and local hosts contracts, and an ordered migration plan based on 54 inventory templates.
Beyond amd64 and arm64
How guest architecture selects an emulator, machine, firmware, devices, and acceptance tests in Barn.
Running Barn from Windows
Why a Linux host remains necessary, what WSL2 must prove, and what a native Windows backend would require.
What Barn Can Learn from Vagrant
A proposal for repeatable provisioning, environment records, file transfer, and recovery in Pigsty labs.
From Upstream Images to a Signed Catalog
How Barn separates upstream release metadata, catalog evidence, runtime support, and release acceptance.
Evolving the CLI Without Breaking Its Contracts
What to preserve when separating Barn's command tree, application orchestration, and output handling.
The Lifetime of a Native Mac VM
Why Barn uses named Mac machines, process-owned networks, narrow locks, and explicit recovery evidence.
repo.yaml Is Intent; catalog.json Is Evidence
Why Barn separates human-authored image policy from generated metadata that must match the actual qcow2 artifacts.
A PID Is Not a Virtual Machine
Why Barn combines QMP identity, process evidence, typed invocations, and journals before it signals or deletes anything.
Declarative Does Not Mean Destructive
How Barn uses per-node hashes and explicit operations so missing configuration can never authorize deletion.
Why Every Barn Node Has Two NICs
Why Barn separates management egress from the fixed-address network used by the host, peers, Ansible, and Pigsty.
Why Barn Has No Projects
Why Barn replaced per-directory project state with one owner-scoped deployment driven by one Pigsty inventory.
-
Barn 1.2.0 release readiness and acceptance
Status, 2026-11-12: Barn 1.2.0 is published as stable/latest. Its final acceptance is recorded below; the candidate sections preserve the earlier review and its original scope. Final release Tag v1.2.0 points to …
Status, 2026-11-12: Barn 1.2.0 is published as stable/latest. Its final acceptance is recorded below; the candidate sections preserve the earlier review and its original scope. Final release Tag v1.2.0 points to …
-
In-place root growth: recovery and native acceptance
Status (2026-11-11): The unreleased development build implements barn resize -D, with ext4 and XFS acceptance on macOS/arm64 using QEMU/HVF guests. Released 1.1.0 still limits resize to CPU/memory. See VM specification design for input precedence and …
Status (2026-11-11): The unreleased development build implements barn resize -D, with ext4 and XFS acceptance on macOS/arm64 using QEMU/HVF guests. Released 1.1.0 still limits resize to CPU/memory. See VM specification design for input precedence and …
-
VM specification parameters: commands, short flags, environment, and root disks
Image, architecture, CPU, memory, scale, and root disk size form one set of VM specification inputs, with consistent names, value rules, and source tracking. Each command declares which fields it accepts and which changes it can apply; the resolution …
Image, architecture, CPU, memory, scale, and root disk size form one set of VM specification inputs, with consistent names, value rules, and source tracking. Each command declares which fields it accepts and which changes it can apply; the resolution …
-
Pigsty host setup: fixed names and CA trust
Recommend one optional host setup operation: install a fixed set of Pigsty names and trust the lab’s public root CA certificate. Keep one entry address, defaulting to 10.10.10.10, and reuse the same CA across ordinary lab rebuilds. With unchanged …
Recommend one optional host setup operation: install a fixed set of Pigsty names and trust the lab’s public root CA certificate. Keep one entry address, defaulting to 10.10.10.10, and reuse the same CA across ordinary lab rebuilds. With unchanged …
-
Main and command reference review
Reviewed on 2026-11-11. Both repositories were on main, but neither had a clean working tree or matched its fetched remote head. The source checks passed on the reviewed working tree. The documentation now has a complete command reference with …
Reviewed on 2026-11-11. Both repositories were on main, but neither had a clean working tree or matched its fetched remote head. The source checks passed on the reviewed working tree. The documentation now has a complete command reference with …
-
Host DNS and domain resolution for Pigsty on Barn
Note Scope narrowed on 2026-11-11: the first delivery is now fixed core names and Pigsty CA trust. This page retains the broader exporter and resolver research; its general inventory and split-DNS work is optional expansion, not a prerequisite for …
Note Scope narrowed on 2026-11-11: the first delivery is now fixed core names and Pigsty CA trust. This page retains the broader exporter and resolver research; its general inventory and split-DNS work is optional expansion, not a prerequisite for …
-
Replacing Vagrant with Barn in Pigsty: resources, names, and migration work
Pigsty can use one inventory for Barn and Ansible. The migration needs to preserve topology selection, image matrices, resource scaling, fixed addresses, and SSH workflows while replacing the old scripts’ implicit addressing, naming, and destruction …
Pigsty can use one inventory for Barn and Ansible. The migration needs to preserve topology selection, image matrices, resource scaling, fixed addresses, and SSH workflows while replacing the old scripts’ implicit addressing, naming, and destruction …
-
Beyond amd64 and arm64
Barn currently supports amd64 and arm64 Linux guests. QEMU can emulate more architectures, but each additional Barn target needs an image and a complete boot-and-operation contract. This design assessment, reviewed on 2026-11-08, separates the …
Barn currently supports amd64 and arm64 Linux guests. QEMU can emulate more architectures, but each additional Barn target needs an image and a complete boot-and-operation contract. This design assessment, reviewed on 2026-11-08, separates the …
-
Running Barn from Windows
Barn’s current host profiles and release binaries cover macOS and Linux on amd64 and arm64. There is no native Windows Barn release. A Windows user can operate Barn through a Linux host; WSL2 and a nested Linux VM are candidates for bringing that …
Barn’s current host profiles and release binaries cover macOS and Linux on amd64 and arm64. There is no native Windows Barn release. A Windows user can operate Barn through a Linux host; WSL2 and a nested Linux VM are candidates for bringing that …
-
What Barn Can Learn from Vagrant
Barn already creates multi-node Linux labs from Pigsty-compatible inventories, manages their lifecycle, and exposes SSH and structured output. The useful lessons from Vagrant concern what happens between creating a VM and repeating an experiment: run …
Barn already creates multi-node Linux labs from Pigsty-compatible inventories, manages their lifecycle, and exposes SSH and structured output. The useful lessons from Vagrant concern what happens between creating a VM and repeating an experiment: run …
-
From Upstream Images to a Signed Catalog
An image audit answers a narrower question than an image release. It can find a newer upstream file, but Barn may add that file to its signed catalog only after the artifact, runtime profile, and boot path have all been verified. The image reference …
An image audit answers a narrower question than an image release. It can find a newer upstream file, but Barn may add that file to its signed catalog only after the artifact, runtime profile, and boot path have all been verified. The image reference …
-
Evolving the CLI Without Breaking Its Contracts
Barn already uses Cobra. The useful part of the 2026-11-04 CLI proposal is its separation of command syntax, application orchestration, and observable behavior. This essay retains that design, checked against v1.1.0 on 2026-11-09. The package split …
Barn already uses Cobra. The useful part of the 2026-11-04 CLI proposal is its separation of command syntax, application orchestration, and observable behavior. This essay retains that design, checked against v1.1.0 on 2026-11-09. The package split …
-
The Lifetime of a Native Mac VM
barn mac manages named macOS VMs through Apple’s Virtualization.framework, independently of the Linux inventory. Introduced in 0.9.0, it uses the native host app Barn.app, included in Apple Silicon release archives since 0.9.2. This essay distills …
barn mac manages named macOS VMs through Apple’s Virtualization.framework, independently of the Linux inventory. Introduced in 0.9.0, it uses the native host app Barn.app, included in Apple Silicon release archives since 0.9.2. This essay distills …
-
repo.yaml Is Intent; catalog.json Is Evidence
This essay explains the Linux image repository contract in Barn 1.1.0 (macOS guests manage Apple .ipsw restore images and APFS base images separately via barn mac). A static VM image repository needs two kinds of metadata: human policy decisions …
This essay explains the Linux image repository contract in Barn 1.1.0 (macOS guests manage Apple .ipsw restore images and APFS base images separately via barn mac). A static VM image repository needs two kinds of metadata: human policy decisions …
-
A PID Is Not a Virtual Machine
This essay explains Linux runtime process identity and crash recovery in Barn 1.1.0. The separate native Mac lifecycle uses per-machine operation locks and runner protocol 2. A pidfile records a process ID at the moment it was written. Minutes or …
This essay explains Linux runtime process identity and crash recovery in Barn 1.1.0. The separate native Mac lifecycle uses per-machine operation locks and runner protocol 2. A pidfile records a process ID at the moment it was written. Minutes or …
-
Declarative Does Not Mean Destructive
This essay explains the Linux VM convergence model in Barn 1.1.0 (macOS guests are managed independently). A declarative tool compares live state against a configuration file—but in daily development, that file might be temporarily edited for …
This essay explains the Linux VM convergence model in Barn 1.1.0 (macOS guests are managed independently). A declarative tool compares live state against a configuration file—but in daily development, that file might be temporarily edited for …
-
Why Every Barn Node Has Two NICs
This essay explains the Linux lab network architecture in Barn 1.1.0 (macOS guests use independent per-VM vmnet NAT subnets). A Pigsty inventory identifies every database node by a stable IPv4 address: PostgreSQL streaming replication, Patroni/etcd …
This essay explains the Linux lab network architecture in Barn 1.1.0 (macOS guests use independent per-VM vmnet NAT subnets). A Pigsty inventory identifies every database node by a stable IPv4 address: PostgreSQL streaming replication, Patroni/etcd …
-
Why Barn Has No Projects
This essay explains the Linux lab deployment model in Barn 1.1.0 (macOS guests are managed as independent named VMs). Early prototypes of Barn treated every working directory as a separate project: a hidden directory marker identified the project, a …
This essay explains the Linux lab deployment model in Barn 1.1.0 (macOS guests are managed as independent named VMs). Early prototypes of Barn treated every working directory as a separate project: a hidden directory marker identified the project, a …