📡 Orchestrating NFV with OpenStack Tacker and VNFs

Tacker is the part of OpenStack most people never touch unless they are in the telco or NFV world, and it shows — the docs assume you already speak ETSI MANO. Tacker is OpenStack’s VNF Manager and NFV Orchestrator: it onboards VNF packages, instantiates virtual network functions on top of Nova and Heat, and manages their lifecycle. I came to it from the cloud side rather than the telco side, and the hardest part was the vocabulary. This guide is the working path from “what is a VNFD” to a running, debuggable VNF, in plain operator terms.

The vocabulary that unlocks everything

Before any command, three terms. A VNFD (VNF Descriptor) is a TOSCA template describing a function. A VNF package bundles that descriptor with artifacts. Tacker onboards the package, then instantiates VNFs from it, ultimately creating Heat stacks and Nova instances underneath.

openstack vnf package list
openstack vnflcm list
openstack vim list

The VIM (Virtualized Infrastructure Manager) is your OpenStack itself, registered with Tacker. If openstack vim list shows your VIM as REACHABLE, Tacker can talk to Nova/Neutron/Heat. An UNREACHABLE VIM is the root of most “nothing deploys” tickets — fix the VIM auth before anything else.

Register the VIM correctly

Tacker needs credentials to drive the underlying OpenStack. This is the one place credentials live, and it is where deployments silently fail when a password rotates.

openstack vim register --config-file vim-config.yaml --description "main" default-vim
openstack vim show default-vim -f value -c status -c status_reason

The status_reason will tell you if it is an auth failure versus a network failure to the Keystone endpoint. A rotated service password is the classic cause of a VIM that was REACHABLE yesterday and is not today — and because Tacker fails late, you discover it only when an instantiation fails.

Pro Tip: Keep the VIM config’s project scoped narrowly. Tacker will create real Nova instances and Neutron ports, so the account it uses should have exactly the quota and roles it needs and nothing more. This is also why you never let an AI assistant near this file.

Onboard and instantiate a VNF

The lifecycle is two phases: onboard the package, then instantiate. Keeping them mentally separate makes failures easier to place.

openstack vnf package create
openstack vnf package upload --path vnf-package.zip <package-uuid>
openstack vnflcm create <vnfd-id>
openstack vnflcm instantiate <vnf-instance-id> instantiate.json
openstack vnflcm show <vnf-instance-id> -f value -c instantiationState

Onboarding failures are about the package contents — a malformed VNFD or a missing artifact. Instantiation failures are about the infrastructure — quota, image, or network. The instantiationState and the operation occurrence tell you which phase you are in.

Debug a failed instantiation

When instantiation fails, Tacker created (or tried to create) a Heat stack. The fastest path to the real error is to follow that stack, because Heat surfaces the underlying Nova/Neutron failure.

openstack vnflcm op list --vnf-instance <vnf-instance-id>
openstack vnflcm op show <op-occurrence-id> -f value -c error
openstack stack list | grep vnf
openstack stack failures list <stack-id>

The error field on the operation occurrence often names the root cause directly. When it is vague, drop to the Heat stack and run stack failures list — that is where you will see “No valid host found” or “Quota exceeded” in plain language, the same way you would debug any Heat deployment.

Where AI is genuinely useful

TOSCA VNFDs are verbose YAML with a steep schema, and that is exactly the fast-junior work an AI assistant accelerates. I have the model draft a VNFD skeleton from a description — “two VDUs, one management network, one data network, a 4 GB flavor” — and explain TOSCA error messages, which are notoriously cryptic. It turns a half-day of doc-spelunking into an hour.

The hard line: I never give it the VIM config or any OpenStack credentials, and it never instantiates anything. It drafts the descriptor and decodes the error; I validate the YAML, review the resource sizing against real quota, and run the lifecycle commands myself. A generated VNFD that quietly requests a 64-core flavor can exhaust a cell, so the human owns instantiation. The prompt library has YAML-scaffolding prompts, Claude is reliable for explaining TOSCA tracebacks, and the prompt workspace is where I keep the VNFD-builder prompt.

openstack vnf package show <package-uuid> -f json \
  | python3 -c 'import sys,json; print(json.load(sys.stdin)["userDefinedData"])'

VNFFG: chaining functions into a service

A single VNF is rarely the goal in NFV — the value is chaining them, steering traffic through a firewall, then a load balancer, then a cache, in order. Tacker expresses this as a VNF Forwarding Graph, which programs Neutron’s service function chaining under the hood. It is the most powerful and most failure-prone part of Tacker.

openstack vnf graph list
openstack vnf graph show <vnffg-id> -f value -c status
openstack sfc port chain list   # the Neutron layer underneath

A VNFFG that shows ACTIVE in Tacker but does not actually steer traffic is almost always a Neutron SFC problem one layer down — a port pair group that did not form, or a flow classifier that does not match the traffic you expected. As with instantiation, the trick is to stop debugging at the Tacker abstraction and drop to the Neutron sfc commands where the real flow state lives. The forwarding graph is just a generator for SFC objects, and SFC is where chains actually break.

Match VNFD requirements to real capacity

VNFs are frequently demanding — pinned CPUs, huge pages, SR-IOV ports — and a descriptor written by a vendor assumes infrastructure you may not have. An instantiation that fails with No valid host found is usually a VNFD asking for capabilities your compute hosts do not advertise, not a Tacker bug at all.

openstack vnflcm op show <op-occurrence-id> -f value -c error
openstack hypervisor stats show
openstack flavor show <flavor-in-vnfd> -f value -c properties

The flavor properties baked into the VNFD tell you what it demands; the hypervisor stats tell you what you can supply. When they do not match — the VNFD wants hw:cpu_policy=dedicated and your hosts are not configured for pinning — the fix is infrastructure configuration, not the descriptor. I always reconcile these two before blaming Tacker, because the orchestrator is faithfully relaying a request your cloud simply cannot satisfy.

Manage the lifecycle, not just the launch

NFV is about ongoing lifecycle — heal, scale, terminate. Tacker exposes these as LCM operations, and they go through the same op-occurrence machinery you debugged above.

openstack vnflcm heal <vnf-instance-id>
openstack vnflcm scale --type SCALE_OUT --aspect-id worker <vnf-instance-id>
openstack vnflcm terminate <vnf-instance-id>

Each of these spawns an operation occurrence you can track and, when it fails, debug through the underlying Heat stack — so the one debugging skill carries across the whole lifecycle.

Conclusion

Tacker is approachable once you separate the vocabulary (VNFD, package, VIM, VNF) and remember that every instantiation is really a Heat stack you already know how to debug. Register the VIM carefully, keep onboarding and instantiation distinct in your head, and follow failed operations down to the stack. An AI assistant is a strong fast junior for drafting TOSCA descriptors and decoding their cryptic errors — keep the VIM config and all credentials away from it, validate generated YAML and sizing, and run every lifecycle operation yourself. More OpenStack orchestration guides live under the OpenStack category.