Blank Strix Halo to clustered AI node, in one boot

Get the image

What you need

Installing

1. Write the ISO to a USB stick

   Any straight image writer will do — the ISO is directly bootable.

   # Linux / macOS — replace /dev/sdX with your stick, and check it twice
   sudo dd if=nodeweaver-netboot-installer-v12.5.0_a017-strixhalo.iso \
           of=/dev/sdX bs=4M status=progress conv=fsync

   On Windows, Rufus or balenaEtcher in plain image mode.

2. Boot the Strix Halo from it

   Take the machine into its boot menu and select the USB device. Two firmware settings matter on these boxes:

   • Virtualisation and IOMMU enabled — the stack runs its inference server in a VM with the iGPU passed through to it.
   • Headless, so no display output claims the iGPU before the VM can.

3. Let the installer run

   It fetches what it needs, installs NodeWeaver to the internal disk, and reboots into the node. From here on nothing is interactive.

4. Wait for the stack to build itself

   On first boot the node deploys the AI stack on its own. Most of that wall-clock is model download — roughly 51.5 GiB — so it is bounded by your link speed rather than by the machine.

What gets deployed, without being asked

The installer carries a bootstrap parameter that triggers a zero-touch deployment of the NodeWeaver AI stack. Four components come up as one coordinated service, each in its own VM, all owned by the admin user:

The three models

All three stay loaded simultaneously, so escalating from a cheap answer to an expensive one costs a routing decision rather than a model load.

Both large models get the full 262144-token context they were trained for, with a q8_0 KV cache and two server slots so two conversations do not block each other.

The agent knows the cluster it runs on

The hermes role is not a bare chat client. It arrives already knowing where it is and what it is attached to:

• NodeWeaver knowledge, built in. It ships with a NodeWeaver skill and a local copy of the documentation wiki, so it can answer questions about the platform without reaching for the internet.
• Wired to the cluster through MCP. The mcp role is registered as a tool server, so the agent can inspect and administer this cluster — list and instantiate VMs, manage images, services and users — using the OpenNebula API rather than shell access to the nodes.
• Wired to the models through the gateway. Its requests go to switchyard, so an easy question is answered by the fast model and a hard one escalates to the thinking model without the agent having to choose.

The full platform documentation those skills are drawn from is at docs.nodeweaver.io.

Access

Everything is created under the admin user, and every password is the same well-known default:

Talking to it — start at the VNC consoles

This demo does not publish the roles behind a single cluster URL, and every VM takes its address from DHCP. So the VM consoles are where you find out where everything is. Log in to the NodeWeaver web interface, open each stack VM and click its console: each one states its own current address and the URLs it serves.

  NodeWeaver AI Stack  --  llamacpp
  ---------------------------------------------------------------
  This VM          10.0.0.41

  Inference API    http://10.0.0.41:8080/v1
  Chat UI          http://10.0.0.41:8081/
  Agent endpoint   http://10.0.0.41:8082/v1

  Log in as root to manage this VM.
  ---------------------------------------------------------------

The address on that banner is read at the moment the console draws it, so it stays correct across a DHCP renewal. Each role shows its own:

The agent is a terminal application. Take its address from the hermes console, then:

ssh root@<hermes-address>    # password: edgecloud
hermes

It is a real cluster node, not an appliance

What the installer produces is an ordinary NodeWeaver node that happens to arrive with an AI stack on it. Nothing about the demo deployment makes it a special case:

• Add more nodes and it becomes a cluster. Install additional machines the same way and they form a single NodeWeaver cluster with shared distributed storage, one leader and automatic failover — the AI stack's VMs are then ordinary workloads that can move between hosts.
• Run anything else alongside it. The node is a full hypervisor with its own datastore and marketplace; the AI stack is simply the first service on it.
• The stack updates itself. Each role tracks a release channel and re-converges when that moves, so the deployment does not freeze at the version it was installed with.

Peers are best added on the same DHCP network, since that is what this build assumes.

If something does not come up

• Give it time on first boot. The stack cannot be healthy before ~51.5 GiB of models have been downloaded.
• Check the VM consoles. A role that has not finished still shows its address there, which is what you need in order to go and look at why.
• Check DHCP actually issued a lease. Zero-touch means there is no prompt to fall back on if a VM never gets an address.
• Confirm virtualisation and IOMMU are enabled in firmware. Without them the inference VM cannot receive the iGPU.
• The inference VM reboots itself once early in the build, on purpose, when it raises the GTT ceiling. That is expected, not a fault.