DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.

DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
This marks Stage 2 of VNF support.
Stage 1 focused on VNF Appliance Integration. You can find a detailed deep-dive on that topic here: 🔗 VNF Appliance Integration Deep Dive
CloudStack now supports a dedicated VNF Template type (distinct from regular VM templates) that allows configuration of NICs, management information, access methods, etc.
The “VNF Appliance” concept—deploying a VNF VM in guest network(s) as a network-function device instead of relying purely on the virtual router (VR) built into CloudStack.
The UI/UX for VNF covers template registration, NIC mapping, details of the appliance (access/user etc) and verification steps.
The approach allows users to bring in familiar network functions (firewall, NAT, load-balancer, VPN, IDS/IPS) in a more flexible software form (VNF) rather than a CloudStack VR.
So the stage for VNF support is already set. The improvements will aim at making it more robust, scalable, manageable, and integrate better into the operator and user workflows.
Later stages might include
Service Function Chaining
Allow users/admins to define ordered chains: e.g., Firewall → IDS → WAN Optimizer.
Auto-generate internal connectivity between VNFs.
High Availability (HA)
Active-standby VNF pairs with automatic failover.
Autoscaling
Threshold-based or metric-based scaling for VNFs (e.g., spawn new firewall if bandwidth > X Gbps).
Monitoring & Alerts
Integrate with Prometheus / CloudStack Telemetry for per-VNF metrics.
NFV Orchestration Integration
Implement ETSI NFV-MANO API compatibility.
Enable external controllers (ONAP, OSM) to trigger VNF deployments.
VNF Marketplace
Curated catalog of certified templates (open-source + commercial).
Tagging & version control for VNF templates.
Two architectures are introduced
Data flow
Data flow
1. Unified Management for Multiple VNF Vendors
Manage different VNF appliances (Fortinet, Palo Alto, F5, VyOS, HAProxy, etc.) via a single CloudStack API and UI.
Each vendor’s specifics (SSH commands, REST APIs, etc.) are handled by adapters or brokers.
Reduces operator complexity — no need to learn each VNF’s proprietary interface.
2. Lifecycle Management (Full automation)
Automates all lifecycle stages:
Deploy
Configure / Update
Upgrade
Rollback
Monitor / Health
Replaces ad-hoc scripts with a consistent framework.
Makes VNFs “first-class citizens” in CloudStack — just like VMs, Networks, or Volumes.
3. Pluggable Architecture (Extensibility)
Vendors or integrators can easily add a new VNF Plugin without modifying core CloudStack.
Supports both:
Direct adapters (CloudStack ↔ VNF)
Broker adapters (CloudStack ↔ VNF Broker ↔ VNF)
Keeps CloudStack clean while allowing vendor flexibility.
4. API and GUI Integration
VNFs can be controlled via CloudStack API, UI, or automation tools (Terraform, Ansible).
Operators get consistent UX:
Apply configuration
View current state and health
Upgrade firmware/images
Rollback or reapply configs
5. Supports Hybrid Management (Direct or Brokered)
VNF templates are ready
to be added.
| Milestone | Planned date | Actual date | |
|---|---|---|---|
| 1 | Start development | ||
| 2 | main Development is done | ||
| 3 | dev testing is done | ||
| 4 | add marvin/unit test | ||
| 5 | Final dev review | ||
| 6 | pass over to QA | ||
| 7 | QA testing is done |