Building a FortiManager Lab on Proxmox — Part 1: Lab Goals, Compute Sizing and Proxmox Host Preparation
A FortiManager is one of those devices that’s hard to practise with unless you happen to manage one in production. The GUI looks like a configuration tool, but the real value is in policy packages, ADOMs, FortiGuard distribution, FortiAnalyzer integration, scripting, revision control, and the operational rhythm of central management. None of that is learnable from screenshots.
This series walks end-to-end through building a self-contained FortiManager lab on a Proxmox VE host, sized for serious experimentation rather than a demo. By the end of the series you’ll have:
- A FortiManager VM running on Proxmox from a converted
qcow2image. - Two or three FortiGate VMs registered to it, in separate ADOMs, with policy packages that actually deploy.
- A dedicated lab edge FortiGate in front of the management network, so the lab can pull FortiGuard updates and reach the internet without exposing FortiManager to anything inbound.
- Proxmox networking set up properly — Linux bridges, VLAN-aware bridges, and an isolated management segment — so the lab matches the way you’d build it for real.
Part 1 covers the design, the sizing, and the Proxmox host prep that everything else depends on.
Lab goals — what the FortiManager has to actually do
Before sizing anything, decide what the lab is for. A “FortiManager lab” can mean three very different things:
- Click-around lab. One FMG, one FGT, demonstrate that registration works, screenshot the GUI. Two VMs, 8 GB RAM, done.
- Workflow lab. Multiple ADOMs, policy packages, install previews, scripting, ZTP, FortiGuard distribution, role-based admin profiles, revision diffs. This is what you build to actually learn FortiManager.
- Integration lab. FMG + FAZ + FortiGate cluster + FortiSwitch + FortiAP + an authentication source, plus a FortiGate edge protecting the management plane. This is what the rest of this series targets.
The integration lab is the one worth your time. The click-around lab teaches you nothing the documentation doesn’t already say, and the workflow lab is almost enough but skips the part where you wire FortiManager into a network that has a security boundary in front of it — which is exactly where things get interesting (and where most lab guides hand-wave).
Compute sizing — what FortiManager actually needs
Fortinet’s published minimums for FortiManager-VM are useful as a floor but misleading as a target. The minimum spec runs the appliance, but it doesn’t run a useful lab — log indexing, FortiGuard mirror, and policy-package install previews on multiple devices all want headroom that the minimum spec doesn’t provide.
The numbers below are what’s worked for me on a lab Proxmox host that also runs three to five FortiGate VMs alongside.
FortiManager-VM (the lab target)
| Resource | Lab minimum | What I actually allocate | Why |
|---|---|---|---|
| vCPU | 2 | 4 | Policy install previews and fmg-script execution are CPU-bound. Two vCPUs work but the GUI feels like treacle on a busy ADOM. |
| RAM | 8 GB | 16 GB | FMG aggressively caches policy packages and revision history. 8 GB hits swap on any non-trivial ADOM. |
| Disk (system) | 80 GB | 120 GB | The base image is small; FortiGuard mirror, firmware images, and revision history are what eat the disk. |
| Disk (data, optional) | — | 200 GB | Only needed if you turn on FortiAnalyzer features on the same VM (not recommended) or store many firmware images. |
| NICs | 1 | 2 | One on management VLAN, one on a “FortiGuard / outbound” VLAN behind the lab edge FortiGate. Keeps the security boundary clean. |
| Disk type | SCSI | VirtIO SCSI | Ten times the throughput of IDE/SATA on Proxmox in my testing. Always. |
| Disk format | qcow2 | qcow2 | Allows snapshots; raw doesn’t on file-backed storage. Snapshots before every firmware upgrade saved me twice already. |
FortiGate-VM (per device under management)
| Resource | Per FGT in the lab |
|---|---|
| vCPU | 2 (4 if you’re testing IPS/AV at any traffic volume) |
| RAM | 4 GB (8 GB if SSL inspection is on) |
| Disk | 30 GB qcow2 |
| NICs | 4 minimum — wan, lan, mgmt, and a spare for HA or DMZ |
A reasonable “integration lab” footprint is one FortiManager + one edge FortiGate + two managed FortiGates + headroom. That comes to roughly:
- 4 + 2 + 2 + 2 = 10 vCPU allocated (slightly over-subscribed against an 8-thread host is fine — these are bursty workloads).
- 16 + 4 + 4 + 4 = 28 GB RAM allocated. Don’t over-subscribe RAM; FortiOS hates being swapped.
- ~250 GB SSD for VM disks, plus ISO storage.
Host minimum I’d actually run this on
- CPU: any modern x86-64 with at least 8 threads and
vmx/svmenabled in BIOS. An i5/i7 or Ryzen 5/7 desktop is more than enough; I run a similar lab on a small-form-factor refurb Dell with a 6-core i7. - RAM: 32 GB. 16 GB technically fits with discipline; 32 GB is where you stop having to think about it.
- Storage: a single SATA SSD works, but an NVMe drive transforms the experience. FortiOS cold-boot goes from ~90 seconds to ~25 seconds. ZFS or LVM-thin both fine; ext4 with a single qcow2 directory is also fine for a lab.
- Network: one NIC is enough for the host management. A second NIC is useful if you want to bridge the lab onto a separate physical VLAN for testing real traffic, but it’s optional.
Proxmox version and prerequisites
This series is written against Proxmox VE 8.x (8.2 or later — the SDN UI changed materially in 8.0 and the VLAN-aware bridge defaults changed in 8.1). Most of the FortiManager-specific steps are version-agnostic, but the networking sections assume 8.x semantics.
A clean Proxmox install is the easiest starting point. If you’re reusing an existing host, verify:
pveversion
qm --version
cat /etc/network/interfacesYou’re looking for PVE 8.x, qm available (it always is on a PVE host), and a vmbr0 bridge already configured against your physical NIC. If you’re on PVE 7.x, almost everything in this series still applies but the SDN steps in Part 3 will look different — upgrade to 8.x if you can.
Enable nested virtualisation (recommended)
FortiManager itself doesn’t need nested virt, but if you ever want to run a nested hypervisor inside the lab (FortiGate-VM has hardware-assist hooks that benefit from it on older releases) it’s worth turning on once and forgetting:
# Intel
echo "options kvm-intel nested=Y" > /etc/modprobe.d/kvm-intel.conf
modprobe -r kvm-intel
modprobe kvm-intel
cat /sys/module/kvm_intel/parameters/nested # should print Y or 1
# AMD
echo "options kvm-amd nested=1" > /etc/modprobe.d/kvm-amd.conf
modprobe -r kvm-amd
modprobe kvm-amd
cat /sys/module/kvm_amd/parameters/nestedIf modprobe -r complains that the module is in use, reboot — it’s harmless either way.
Storage layout
For this series I assume:
local(default Proxmox storage, used for ISO uploads and templates) — content types: ISO image, container template, snippets.local-lvmorlocal-zfs(default Proxmox storage for VM disks) — content type: Disk image. This is where qcow2 files for FMG and FGT will live.
If you’ve gone with ext4 and a custom directory:
mkdir -p /var/lib/vz/images/lab
chown root:root /var/lib/vz/images/lab
chmod 0755 /var/lib/vz/images/labThen add it as a Proxmox storage pool via Datacenter → Storage → Add → Directory, content type Disk image, ISO image, ID lab.
Make sure qemu-img is available
It already is on a Proxmox host — that’s what the qcow2 conversion in Part 2 uses — but verify:
which qemu-img
qemu-img --versionYou should see qemu-img version 8.x or later on PVE 8.x.
Time and DNS
A FortiManager that can’t resolve update.fortiguard.net is a paperweight. A FortiManager whose clock has drifted is worse — it’ll fail TLS to the FortiGuard CDN and quietly stop updating. Both apply to the Proxmox host too.
# DNS — on the Proxmox host, not the VM
cat /etc/resolv.conf
# Time
timedatectl status
chronyc tracking # if chrony is installed (default on PVE 8.x)If chronyc tracking shows a leap status of Normal and a stratum of 2 or 3, you’re good. If the host is on a NAT’d home network, point chrony at pool.ntp.org and move on.
What the next parts cover
The remainder of the series, in order:
- Part 2 — Obtaining and building the FortiManager qcow2. Where to get the image, what file you actually want from the support portal, the
qemu-imgconversion, importing it into Proxmox, and first-boot sanity-checks. - Part 3 — Proxmox networking for the lab. Linux bridges vs. VLAN-aware bridges, the segments this lab uses (mgmt, transit, FortiGuard egress, customer VRFs), Proxmox SDN basics, and the
/etc/network/interfacesshape that supports it. - Part 4 — Lab edge FortiGate in front of FortiManager. Build a small FortiGate-VM, drop it on the bridges from Part 3, and configure it to act as the security boundary between the FortiManager management network and the outside world. Includes the firewall policy set, FortiGuard pinhole, and source NAT layout.
- Part 5 — Putting it together. Register two managed FortiGates to the FortiManager via the lab edge, build an ADOM, push a policy package, and verify the install. End state is a fully working integration lab you can snapshot, break, and rebuild.
If you want to skip ahead and just stand up a FortiManager VM with no security around it, Part 2 is enough. If you want a lab that mirrors how this is actually deployed in production — and trains the operational habits that go with it — read all five.
The single-line summary for Part 1: size the host for headroom, use VirtIO SCSI on qcow2, get the time and DNS right on the Proxmox host before you do anything else. Everything in the rest of the series assumes those three things are correct.