Building a FortiManager Lab on Proxmox — Part 2: Obtaining the Image, qcow2 Conversion and First Boot

27 April 2026 FortinetFortiManagerProxmoxLabqcow2KVM

Part 1 covered why you’d build this lab, how to size it, and how to prep the Proxmox host. Part 2 is the part where a FortiManager VM actually appears on the host. The mechanics are simple once you’ve done it once but the first time has a few traps — the wrong file from the support portal, the wrong disk format, the wrong NIC type, and the wrong console expectation. This post walks through the conversion, import, and first-boot sequence end-to-end.

Step 1 — Get the right file from the Fortinet support portal

You need a Fortinet support account with FortiManager-VM entitlement (a 30-day trial is fine for a lab; ask Fortinet sales or your partner). The image you want is the KVM build of the FortiManager-VM, not the ESXi build, not the Hyper-V build, and not the “Upgrade” image.

In the support portal: Download → VM Images → Select Product: FortiManager → Select Platform: KVM → New Deployment. The filename will look like:

FMG_VM64_KVM-v7.6.x-buildXXXX-FORTINET.out.kvm.zip

Inside the zip you’ll find:

fortimanager.qcow2          # the system / boot disk — ~2 GB
datadrive.qcow2             # the data drive — ~32 GB, sparse

Both are real qcow2 files. Don’t be tempted to skip datadrive.qcow2 — FortiManager refuses to come up properly without a data partition, and the GUI will throw a “data drive not found” splash and sit there forever.

If your support portal shows a .tar.gz instead of a .zip, that’s the older packaging — same files inside, extract with tar xzf.

Version pinning

Pin a known-good version. As of writing, the FortiManager release I’d lab against is 7.6.2 or later for parity with FortiOS 7.6.x devices under management. If your managed FGTs are still on 7.4 or 7.2, match the FMG to a release that supports them — the FortiManager Compatibility Matrix is the authoritative source. Don’t run an FMG older than the FGTs it manages; the policy package install will fail with cryptic schema errors.

Step 2 — Move the files to the Proxmox host

SCP the zip to the Proxmox host and unpack it on the host itself. There’s no point unpacking locally and then moving 35 GB of qcow2 over the network.

# from your workstation
scp FMG_VM64_KVM-v7.6.2-build1234-FORTINET.out.kvm.zip root@pve01:/root/

# on the Proxmox host
cd /root
mkdir fmg-7.6.2 && cd fmg-7.6.2
unzip ../FMG_VM64_KVM-v7.6.2-build1234-FORTINET.out.kvm.zip
ls -lh

Expected result:

-rw-r--r-- 1 root root 2.1G fortimanager.qcow2
-rw-r--r-- 1 root root  33G datadrive.qcow2

Confirm the qcow2 files are valid before you import them — saves a confusing reboot loop later:

qemu-img info fortimanager.qcow2
qemu-img info datadrive.qcow2
qemu-img check fortimanager.qcow2
qemu-img check datadrive.qcow2

qemu-img check should report No errors were found on the image. for both. If either errors out, the download was corrupted — pull it again rather than trying to repair it.

Step 3 — Create the VM shell in Proxmox

Create the VM without any disks attached yet — you’ll import the qcow2 files in the next step. The VMID I use for the lab FMG is 9001; pick whatever fits your numbering scheme.

qm create 9001 \
   --name fmg-lab-01 \
   --memory 16384 \
   --cores 4 \
   --sockets 1 \
   --cpu host \
   --machine q35 \
   --bios seabios \
   --ostype l26 \
   --scsihw virtio-scsi-single \
   --net0 virtio,bridge=vmbr-mgmt,firewall=0 \
   --net1 virtio,bridge=vmbr-fgd,firewall=0 \
   --serial0 socket \
   --vga serial0

A few of those flags matter more than they look:

  • --cpu host exposes the full host CPU feature set. FortiManager uses AES-NI for FortiGuard signature verification — without it, signature pulls slow down by an order of magnitude. Don’t skip this.
  • --machine q35 gives you a modern PCIe chipset. The default i440fx works but q35 is closer to what FortiManager expects on real hardware and avoids a couple of console quirks.
  • --scsihw virtio-scsi-single is the high-throughput SCSI controller. Do not use IDE or SATA. I’ve seen factory-reset FMG installs sit at 100 % iowait for ten minutes on SATA where VirtIO SCSI completes the same step in under a minute.
  • --serial0 socket --vga serial0 redirects the console to a Proxmox serial socket. FortiManager prints its boot messages to serial; if you leave VGA only, the first 30 seconds of boot output disappears and so do the IP-on-DHCP messages on the very first boot.
  • bridge=vmbr-mgmt and bridge=vmbr-fgd reference the bridges we’ll build in Part 3. If you want to bring the VM up before the bridges exist, swap them temporarily for vmbr0.
  • firewall=0 turns off the Proxmox per-VM firewall. The lab edge FortiGate in Part 4 is the firewall; double-firewalling at the hypervisor is a debugging trap.

The two NICs are deliberate:

  • net0 → management VLAN — where you SSH/HTTPS to the FMG GUI.
  • net1 → FortiGuard egress VLAN — outbound only, sourced through the lab edge FortiGate to the internet.

Splitting these means the lab FMG never has a default route on the same segment as its admin access. That’s a habit worth building.

Step 4 — Import the qcow2 disks

This is the part the post is named after. qm importdisk takes a qcow2 file and attaches it to a VM, converting (or not) into the target storage’s preferred format.

qm importdisk 9001 /root/fmg-7.6.2/fortimanager.qcow2 local-lvm --format qcow2
qm importdisk 9001 /root/fmg-7.6.2/datadrive.qcow2     local-lvm --format qcow2

If your storage is a plain directory (e.g. lab from Part 1), substitute that as the third argument. After import, qm config 9001 will show the disks as unused0 and unused1 because they’re not attached to a controller yet:

qm config 9001 | grep unused
unused0: local-lvm:vm-9001-disk-0
unused1: local-lvm:vm-9001-disk-1

Attach them as the system disk (scsi0) and the data drive (scsi1):

qm set 9001 --scsi0 local-lvm:vm-9001-disk-0,discard=on,iothread=1,ssd=1
qm set 9001 --scsi1 local-lvm:vm-9001-disk-1,discard=on,iothread=1,ssd=1
qm set 9001 --boot order=scsi0

Flag-by-flag:

  • discard=on lets the guest send TRIM commands through to the underlying SSD. FortiManager doesn’t TRIM aggressively but every little helps on a thinly-provisioned SSD.
  • iothread=1 gives each disk its own QEMU IO thread. Improves concurrency when both disks are busy at the same time, which they are during a FortiGuard pull.
  • ssd=1 flags the disk as SSD-backed to the guest. FortiOS / FMG don’t currently use this for tuning but it’s harmless and future-proof.
  • --boot order=scsi0 makes scsi0 the boot disk explicitly — otherwise SeaBIOS may prefer the data drive if it has a bootable signature for any reason.

Confirm:

qm config 9001

You should see:

boot: order=scsi0
cores: 4
cpu: host
machine: q35
memory: 16384
net0: virtio,bridge=vmbr-mgmt,firewall=0
net1: virtio,bridge=vmbr-fgd,firewall=0
scsi0: local-lvm:vm-9001-disk-0,discard=on,iothread=1,ssd=1
scsi1: local-lvm:vm-9001-disk-1,discard=on,iothread=1,ssd=1
scsihw: virtio-scsi-single
serial0: socket
vga: serial0

That’s the whole conversion done. You did not, in fact, need to convert the qcow2 — qm importdisk recognised the source format and copied it in directly. If you’d downloaded a vmdk (the ESXi build) you’d need qemu-img convert first, which is the other reason this post exists:

Bonus: converting from VMDK if that’s all you have

If for some reason you ended up with the ESXi .vmdk build instead of the KVM build:

qemu-img convert -p -O qcow2 \
    fortimanager.vmdk fortimanager.qcow2

qemu-img convert -p -O qcow2 \
    datadrive.vmdk    datadrive.qcow2

-p shows progress, -O qcow2 sets the output format. Then proceed with qm importdisk as above. The KVM build is preferred — same end state but no conversion step and the bundled init.cfg is shaped for KVM rather than VMware.

Step 5 — First boot

qm start 9001
qm terminal 9001

qm terminal attaches to the serial console. Watch the boot — first run does an initial filesystem build on the data drive, regenerates SSH keys, and then drops to the login prompt:

FortiManager-VM64-KVM login:

Default credentials:

Username: admin
Password: (blank — press Enter)

You’ll be asked to set a password on first login. Set it immediately — there’s no rate limiting on the console and a forgotten admin password on FortiManager is genuinely painful (it requires a console-cable factory reset on physical hardware; on a VM, restoring a snapshot is the only practical way back).

Now address the box. By default the first NIC is on DHCP. If your management VLAN has DHCP, it will already have an address — get system status will show it. If not, set static:

config system interface
    edit "port1"
        set ip 10.20.10.10/24
        set allowaccess ping ssh https
    next
end

config router static
    edit 1
        set device "port1"
        set gateway 10.20.10.1
    next
end

Note the gateway points at the lab edge FortiGate’s management-VLAN address — which doesn’t exist yet (Part 4) but you’re laying the groundwork. For now point it at whatever DHCP gateway is on vmbr-mgmt, or leave it unset and use console only until Part 4.

Disable the second NIC for now or address it on its own subnet:

config system interface
    edit "port2"
        set ip 10.20.20.10/24
        set allowaccess ping
    next
end

port2 is reserved for FortiGuard egress through the lab edge. We’ll route this in Part 4.

Apply the licence file (or run in trial mode)

A 14-day trial is built in — just get system status and confirm License Status: Valid (trial). For a longer-running lab, drop a .lic file via the GUI: System Settings → Dashboard → Licence Information → Upload.

Sanity checks before moving on

get system status
get system performance
get system interface
exec ping 1.1.1.1            # will fail until Part 4 — that's fine
diagnose dvm device list     # empty for now; this is where managed FGTs will appear
diagnose test application updated 1   # FortiGuard service status

The system status output should show:

  • Hostname, serial, version (7.6.x), build, branch.
  • Both partitions (active / backup) populated.
  • Database initialisation complete.

If you see “Database initialization in progress” wait a few minutes and re-run — first boot does take 3-5 minutes to settle on the data drive.

Step 6 — Take a snapshot

The single most useful thing you can do on a freshly-built lab VM is snapshot it before doing anything else.

qm snapshot 9001 fresh-build --description "Post-first-boot, admin password set, no licence applied"

If anything goes wrong in Part 3, 4, or 5 — and on the first attempt at any of these, something will — qm rollback 9001 fresh-build puts you back to a clean slate in under a minute. Snapshots on qcow2 are essentially free; take them liberally.

What’s next

Part 3 is the networking. The current state of the lab has a FortiManager attached to two bridges that may or may not exist yet — Part 3 builds those bridges, plus a third for the FortiGuard egress segment, plus an isolated transit segment for the managed FGTs to register on. If your vmbr-mgmt doesn’t yet exist and you skipped that bridge in qm create, the VM will still boot — it just has no network until Part 3 is finished.

The single-line summary for Part 2: KVM image, qcow2 in / qcow2 out, VirtIO SCSI on q35 with cpu=host, serial console for visibility, snapshot before you touch anything else.