Compute node

A compute node is the execution half of the cloud. Nova Compute receives work selected by the controller’s scheduler. Libvirt starts and supervises guest processes. QEMU supplies virtual hardware; KVM accelerates those guests when the host’s kernel exposes /dev/kvm. Open vSwitch and Neutron agents connect each guest’s virtual port to the provider network and provide DHCP where the network configuration requires it.

It is intentionally not the controller. It holds no Keystone identity database, image catalogue, scheduler database or authoritative network catalogue. Those live on the controller. A compute host must nevertheless reach the controller reliably: it authenticates to Keystone, consumes RabbitMQ work and contacts Glance, Placement and Neutron through the controller address.

Give the host a stable management address and identify a physical interface that may carry provider traffic. The interface becomes an OVS bridge port. If it is also the default-route interface used by SSH, a mistake can disconnect you. A dedicated provider NIC is the calmer arrangement.

The recipes do not publish a minimum RAM, disk or CPU count. Record what the machine has, leave capacity for the host operating system and guest disks, then size flavors from measured spare resources rather than an invented minimum.

# Read-only facts used to plan this host. None of these commands changes networking.
uname -m
free -h
lsblk
ip -o link show
ip route show default
test -e /dev/kvm && echo "KVM device present" || echo "No KVM device: QEMU emulation will be used"

uname -m records the CPU architecture; the current role script does not make an architecture promise or an artificial CPU-feature check. free -h and lsblk show available memory and disks for your capacity plan. The KVM test is the one used by the setup script: presence of /dev/kvm selects kvm; absence selects qemu.

# Replace CONTROLLER_IP with the planned controller address.
ip route get CONTROLLER_IP
curl -s -m 10 -o /dev/null -w '%{http_code}\n' http://CONTROLLER_IP:5000/v3

The route command should name the intended interface and gateway. A successful Keystone reachability probe returns an HTTP response such as 200 or 300; 000, a timeout or a route to an unexpected interface must be fixed before joining the host.

KVM does not create virtual machines by itself. It is a kernel facility used by QEMU so the guest can execute suitable CPU instructions directly on the processor. That is the normal production path when the hardware and firmware make virtualisation available.

QEMU can instead emulate the CPU in software. This lets a guest boot on hosts without /dev/kvm, including many nested or virtualised lab machines, but it is substantially slower. The Saphira setup script probes rather than guessing: forcing virt_type = kvm on a host without the device causes libvirt to reject every guest.

Do not confuse an instance’s requested virtual CPUs with the host’s physical CPUs, and do not promise more memory through flavors than the host can safely supply. Placement and Nova scheduling depend on the resources reported by the compute service; a small test flavor is a safer first proof than a workload-sized one.

# Run as root. This installs the compute role and dependencies, but starts no role configuration by itself.
apk add saphira-openstack-compute

# Start the interactive join procedure.
saphira-openstack-setup-compute

The package brings in Nova, Neutron, libvirt, Open vSwitch, dnsmasq, IP routing tools, iptables and the Saphira OpenStack foundation. The script then writes Nova and Neutron settings, starts the required libvirt daemons, constructs the provider bridge and starts the agents. It preserves existing generated configuration unless you explicitly use --force.

Nova is configured with the controller’s RabbitMQ URL, Keystone authentication, Placement, Glance and Neutron credentials, this host’s first global IPv4 address, a state path and a lock path. The script writes virt_type = kvm only when the KVM device exists; otherwise it writes qemu.

It creates narrow sudoers permissions for Nova’s privsep and rootwrap helpers, then validates them with visudo -c. Neutron receives its filtered neutron-rootwrap helper and narrow privsep permissions. These grants are deliberate boundaries: widening them to unrestricted sudo may hide an error while weakening the host.

For Neutron, the script writes the OVS bridge mapping and systemd drop-ins that start the OVS and DHCP agents with their configuration files. A correct file that the running process never reads still produces empty bridge mappings, so the launch flags matter.

It starts virtlogd, virtnodedevd, virtsecretd and virtqemud; all four are required for a guest lifecycle. It also adds a targeted ProtectControlGroups=no drop-in for the known packaged virtqemud cgroup problem, then creates the OVS bridge and adds the selected NIC.

At the end of a successful join, the script reports the Nova Compute, OVS and DHCP agents as active. It then tells you that final proof must come from the controller, because a locally running service is not yet a schedulable OpenStack host.

# On the compute node: read-only local verification.
saphira-openstack-setup-compute --check
systemctl is-active nova-compute neutron-openvswitch-agent neutron-dhcp-agent
systemctl is-active virtqemud virtlogd virtnodedevd virtsecretd
ovs-vsctl show

Every requested unit should report active. In the OVS output, the chosen bridge should exist and contain the intended physical NIC. Do not infer success from the bridge alone: the agent must report the mapping to Neutron.

# On the controller, after the compute services are active.
nova-manage cell_v2 discover_hosts --verbose

This command introduces newly reporting compute hosts to Nova’s cell mapping. Successful output identifies discovered hosts or reports that no new hosts need discovery. Without this step, scheduling can fail with No valid host even if Nova Compute is running.

Finally, use Horizon’s administrator views to confirm that the hypervisor is up and that this host’s OVS and DHCP Neutron agents are alive. The OVS agent must show the expected physnet1:br-physnet1 mapping (or your explicitly chosen equivalent). These are the controller’s view of the truth.

The Saphira guides deliberately do not depend on a separate OpenStack client package. Use Horizon after controller, compute and agent verification. These are normal OpenStack dashboard operations; the exact fields and available options depend on the deployed Horizon version and policy.

1. Upload an image. In the project’s Compute → Images view, create an image and select the file and its actual disk format. Wait until its status is active before using it. Glance provides this image to Nova; uploading a file does not prove a guest can boot it.
2. Create a small flavor. In the administrator Compute → Flavors view, select a name, virtual CPU count, RAM and disk appropriate for a first test. A flavor is a request to the scheduler; begin small enough that your verified compute host can satisfy it.
3. Create the provider network and subnet. In Project → Network, create a network whose physical-network mapping matches the compute bridge, then create a subnet. Enable DHCP if the guest should obtain an address automatically. A network without a subnet/DHCP configuration can still show an instance as active while the guest has no useful address.
4. Review security groups. Security groups are Neutron port-firewall rules. Add only the ingress protocols and source ranges required for the test; do not open all ports to compensate for a broken route, DHCP service or bridge mapping.
5. Launch the instance. In Project → Compute → Instances, choose the image, flavor, network and intended security group, then launch. Watch its task and power state, then check the assigned address and guest console only after the backend agents are healthy.

ACTIVE is Nova’s result for the build request. It is necessary but incomplete. A booted guest needs a successful libvirt/QEMU process and image boot. A reachable guest also needs a bound Neutron port, a correct bridge mapping, a DHCP lease or static configuration, routes, security-group rules and a listening service.

Verify in layers: first the Nova hypervisor and Neutron agents in Horizon, then the instance task/power state, then its displayed address, then the guest console when noVNC is complete or the specific service you intended to reach. Stop at the first failed layer rather than opening permissive firewall rules or rebuilding the instance repeatedly.

Horizon exposes lifecycle actions for the instance after it exists. Shut Off requests a stopped guest; Start asks Nova to boot it again; Reboot restarts the guest; Rebuild replaces its root disk from an image and is destructive to data on that root disk; Delete removes the instance record and its ephemeral storage. Confirm which disk is ephemeral and make a tested backup before destructive actions.

Persistent Cinder volume attachment must not yet be used as a promised recovery method in this Saphira deployment. Its iSCSI dependency chain is now published, but Cinder has not completed the deployed create/attach/read-back/delete proof. If your guest stores important data on local/ephemeral disks, deletion and rebuild can remove it permanently.

# On the compute node, inspect the relevant service logs.
journalctl -u nova-compute -b --no-pager
journalctl -u neutron-openvswitch-agent -b --no-pager
journalctl -u neutron-dhcp-agent -b --no-pager
journalctl -u virtqemud -b --no-pager

• “No valid host”: confirm the controller discovered the host into a cell and reports the hypervisor as up before changing flavors.
• “Emulator does not support virt type kvm”: the host lacks /dev/kvm; let the setup script select QEMU instead of forcing KVM.
• FailedToDropPrivileges or helper exit 1: inspect the narrow Nova/Neutron sudoers and rootwrap path rather than granting unrestricted sudo.
• Empty bridge mappings or PortBindingFailed: verify the OVS agent’s live mapping and systemd command line, not merely the file on disk.
• No address or DHCP: verify the DHCP agent and Neutron RPC server, then the network/subnet DHCP setting and OVS binding in that order.
• Guest cgroup or virtlogd errors: verify the complete libvirt daemon set and the targeted virtqemud cgroup drop-in.

For symptoms, expected observations and recovery checks in more detail, use the pitfalls book. For persistent-volume status and the reason it is not yet safe to deploy, read the storage guide.