Virtual Appliances and Cloud-Delivered Management: FTDv, FMCv and cdFMC

Overview

The virtual appliances run the same Secure Firewall software as the hardware and take the same FMC policy model, within each platform’s own capabilities and limits. What changes is everything the hardware used to decide for you: how big the box is, which throughput you are entitled to, how it gets its first address, and, with cdFMC, whether the manager is yours at all. Get those wrong and the symptoms look like software faults: a firewall capped below the link it sits on, an appliance that “deployed successfully” and boots unconfigured, a cloud migration whose event history stays behind on the old manager.

Secure Firewall Platform Architecture: Threat Defense, FMC and the Snort/LINA Split introduced FTDv, FMCv and cdFMC as options. This lesson is about operating them.

Scale & Limits: Two Licence Axes and a Sizing Table

The two virtual appliances are licensed on different axes, and each axis is tied to how big you make the VM:

On VMware, each licence assumes a VM size (public clouds map tiers to their own supported instance types instead):

The FTDv sizes come from the FTDv on VMware guide, the FMCv sizes from the FMCv on VMware guide. Read the VMware table as a sizing calculator that works in both directions:

• Throughput first: the tier you need sets the vCPU and memory. A tier licensed onto a smaller VM is a ceiling the VM cannot reach.
• Fleet first: the device count sets the FMCv licence. Moving between the 2-, 10- and 25-device licences does not change the minimum VM; only FMCv300 does, and it is a different class of machine — built for fleets, not labs.

Three rules from the FMC 10.0 licensing chapter round it out:

• A new Smart-Licensed FTDv starts at FTDv50. On an FMC-managed FTDv, you change it in FMC: Administration › Licenses › Smart Licenses › Edit Performance Tier.
• Of the customer-managed FMCs, only the virtual one is licensed for itself. A physical FMC “does not require a license for its own use”; FMCv’s platform licence “correlates with the number of devices it can manage.”
• Don’t trim FMCv below its defaults. The FMCv guide is blunt: “Do not decrease the default settings, as they are the minimum required to run the system software.” It also names a hard floor under that: below 28 GB, upgrades to 6.6.0 and later fail.

FTDv runs on more than the two hypervisors this course uses. The Threat Defense Virtual 10.0 getting started guide has a deployment chapter for VMware, KVM, Hyper-V, Cisco HyperFlex, Nutanix and OpenStack, and for AWS, Azure, OCI, GCP and Alibaba Cloud.

The FTDv limit that shapes every design is its interface count. On VMware and KVM it has ten virtual NICs: one management, one diagnostic, and eight data interfaces. Every design in this module has to fit a routed, a passive and an inline deployment inside those eight.

Design Choice: The Deployment Template Decides Who Does First Boot

FMCv for VMware ships as an OVF package (Open Virtualization Format): a descriptor file that tells the hypervisor how to build the VM, next to the disk image. There are two descriptors for the same disk, and the choice between them decides whether the appliance configures itself.

Enlarge figure: Two columns compare the FMCv OVF templates. The VI template is deployed through vCenter; hostname, address and password are OVF properties, so the properties are delivered and the appliance boots configured, with setup done at deploy time — but without vCenter the properties never arrive, while the deploy tool still reports success. The ESXi template works on a standalone ESXi host or under vCenter with no setup properties at deploy time, so nothing is delivered and setup happens on the console: first login runs the EULA, password and network steps, and the console is what you script, not the deploy. It works with or without vCenter. A footer says: on a standalone host, check the console, and never trust the deploy tool's success line.

• VI template (for vSphere Infrastructure, meaning vCenter) — Cisco says it “enables complete initial setup during installation.” The hostname, address and admin password are properties you fill in at deploy time, and vCenter hands them to the guest.
• ESXi template — for a standalone ESXi host, or under vCenter. It carries no setup properties; the appliance configures itself on first boot, from the console.

The trap is using the VI template without vCenter. Some deploy tools accept its properties, report success, and leave you with an appliance that boots with none of them.

First boot is also slow: FMCv initialises its databases before it offers a login. Budget for it rather than debugging it.

Terminology: Cloud-Delivered FMC

Cloud-delivered FMC is FMC as a service, inside Security Cloud Control. Per Cisco’s cdFMC overview, Cisco’s operations team deploys and maintains it and updates it as features ship. You get FMC-style policy management, within cdFMC’s own supported-feature list, and you stop running the server it lives on.

Enlarge figure: Two columns compare where configuration and events land. On-premises FMC or FMCv: you deploy, patch, back up and upgrade it, and devices register to it over TCP 8305; the device talks to your FMC, and both configuration and events land there, on the same appliance, with high availability available on VMware, AWS, Azure, KVM, OCI and HyperFlex, reachable from your management network. Cloud-delivered FMC: Cisco's operations team deploys and upgrades it, and devices reach it outbound on TCP 443 and 8305; the device talks to Security Cloud Control, configuration lands there, and events go to Security Analytics and Logging instead, with no Secure Device Connector needed and migration from on-premises needing version 7.2. A footer says: pick the event destination before the migration, not after.

What a device needs, and what changes:

The connectivity and onboarding rows come from Cisco’s cdFMC onboarding page, which is explicit that no connector is needed for this. The event row is the one that surprises people: cdFMC moves the configuration manager to the cloud, and event analysis becomes a separate service you choose and configure. Resilience is yours with a customer-managed FMCv: its high availability is a pair you build, which the FMCv introduction supports on VMware, AWS, Azure, KVM, OCI and HyperFlex.

Scale & Limits: FTDv in the Public Cloud

The cloud changes how FTDv is bought and grown, not what it is. Cisco’s FTDv auto scale guide for AWS shows the three decisions; the same 10.0 guide has an equivalent auto scale solution for Azure. The table follows AWS:

The last row is why the manager decision comes first in the cloud. Auto scale works because Cisco’s automation registers each new instance with the management center, applies its policy, and deregisters it on scale-in. Device Manager has nothing to register to.

🔬 See It in the Lab: The Licences This Module Has Used

This is read-along. By this lesson the module’s FMC-01 (an FMCv 10.1.0 on the lab’s ESXi host) manages two Threat Defense virtuals: FTD-EDGE-01, which has carried every deployment mode, and FTD-HARNESS, the disposable device the transparent-mode lesson converted. M1 · Lab 1: Stand Up the SNCF Firewall Lab — FTD, FMC and the Traffic Generators walked FMC-01 from power-on to evaluation mode; this is what that evaluation licence looks like with devices on it.

Administration › Licenses › Smart Licenses, with two licence rows expanded:

123

Read it against the two licence axes:

• Marker 1: the FMCv holds a licence for itself. The Firewall Management Center Virtual row lists fmc-01.securitylessons.lab. That is the platform licence a physical FMC never needs.
• Marker 2: Essentials counts both devices. Every registered Threat Defense consumes an Essentials entitlement, so the count is two.
• Marker 3: feature licences are per device. IPS counts one. FTD-EDGE-01 took IPS at registration, ahead of the passive and inline lessons; FTD-HARNESS was registered with Essentials alone. Malware Defense and URL are at zero because no device asked for them.

The tier sits beside the device name: FTDv5 - Tiered. The registration wizard defaults to FTDv50; Onboarding Threat Defense to FMC: Manager Modes, Registration and Initial Setup chose FTDv5 because these FTDv nodes run on the 4 vCPU / 8 GB that tier assumes.

Edit Performance Tier is where that choice changes later:

45

Pick a target tier (marker 4), move devices from Available Devices (marker 5) to Selected Devices, and apply. It works on a fleet in one step, but it changes only the licence. It does not resize the VM: move FTD-EDGE-01 to FTDv50 and the tier promises a throughput its 4 vCPU cannot deliver. The dialog was opened and cancelled here; no tier changed.

The model strings name the virtual platforms. show version on each appliance’s own command line:

> show version
-----------[ fmc-01.securitylessons.lab ]-----------
Model                     : Cisco Secure Firewall Management Center for VMware (66) Version 10.1.0 (Build 160)
UUID                      : d7d05060-b986-11f1-8996-ee80d169eb61
Rules update version      : 2026-08-26-001-vrt
LSP version               : lsp-rel-20260908-1734
VDB version               : 433
----------------------------------------------------

> show version
------------------[ FTD-EDGE-01 ]-------------------
Model                     : Cisco Secure Firewall Threat Defense for KVM (75) Version 10.0.0 (Build 140)
UUID                      : 1da06a12-b9c3-11f1-b7bc-9b4e5d458458
VDB version               : 416
----------------------------------------------------

The FMC says for VMware; the FTDv, a node in Cisco Modeling Labs, says for KVM. The licence page agrees: its device-type column reads Threat Defense for KVM. Two hypervisors, one manager, and nothing in the management or licensing relationship depends on which is which.