Skip to main content

Deploying the OVA appliance

For an always-on Connector that survives reboots without you having to manage a service yourself, FireMon distributes the Connector as a ready-to-go VMware appliance (OVA). It runs the same Connector application as a background service on a minimal, hardened Ubuntu Linux VM.

Target hypervisor: VMware vSphere / ESXi. The appliance's deploy-time settings (registration code, environment, static IP) are delivered as OVF vApp properties via VMware Tools, which only vSphere/ESXi feed in. Other tools (VirtualBox, Workstation) can import and boot the OVA, but won't pass those properties through — you'd pair it through the console wizard instead and can't auto-pair.

VM specifications

PropertyValue
OSUbuntu 24.04 LTS x86_64
vCPU1
RAM2 GB
Disk10 GB, thin-provisioned
NICone adapter on a network that can reach the internet and the on-prem systems you're integrating with
VMware hardware versionvmx-19 (vSphere 7.0+)

1. Get the OVA

On the same Settings > Connectors page in Connect used to download the native binary, the Download the Connector app step also lists an .ova file — download it.

2. Deploy and configure

  1. In vSphere, Deploy OVF Template, point it at the downloaded .ova, then choose a name, host/cluster, datastore, and the network the appliance should use.

  2. On the Customize template page, fill in the appliance properties. All are optional:

    PropertyPurpose
    Registration CodeA code from Settings > Connectors in Connect. If set, the appliance pairs itself automatically on first boot with no console interaction. Leave it blank to pair from the console wizard instead.
    Connector NameDisplay name in Connect. Defaults to the hostname.
    IP Address / Subnet Mask / Default Gateway / DNS ServersLeave all blank for DHCP. If you set IP Address, the other three become required.
    HostnameOptional system hostname.
    EnvironmentLeave this set to prod. It selects which FireMon Cloud environment the appliance registers with; the other value is a FireMon-internal development environment and a Connector pointed at it won't appear in your account.
  3. Finish the wizard and power on the VM.

If you set both a static IP and a registration code, the appliance comes up fully paired with no console interaction needed. Otherwise, the console wizard on the VM's console (tty1) takes over for whichever part is missing — network configuration, pairing, or both.

3. Pair from the console (if you left the registration code blank)

Open the VM console in vSphere. The FireMon Connector wizard shows the appliance's network status, then a menu. Choose Register connector and enter:

  1. Connector name — defaults to the hostname.
  2. Registration code — a code from Settings > Connectors in Connect.

On success it prints Registration successful! and starts the service.

4. Confirm the appliance is online

Same check as the native binary: Settings > Connectors > Connectors in Connect shows it with a green status dot. On the VM console, the wizard now shows a status menu with View logs, Restart service, Test cloud connectivity, Re-pair connector, and Shell.

One appliance per Connector identity

Don't clone a paired appliance — the clone would share the original's Connector ID and the two would fight over the same work (see Installation). To run a second Connector, deploy another appliance from the OVA and pair it with its own registration code.

The console wizard

Once paired, opening the VM's console shows a status menu:

OptionWhat it does
View logsTail the Connector's local log file
Restart serviceRestart the Connector systemd service
Test cloud connectivityRun DNS + connectivity checks against every FireMon endpoint the appliance needs — see Network Requirements
Re-pair connectorDiscard the appliance's local credentials and pair again with a fresh registration code — use this to move an appliance to a different account, or to recover after its Connector was removed in Connect
ShellDrop to a root shell on the appliance

Restrict who can open the VM console. The appliance ships with no default password and no network login service — SSH is disabled — so the console is its only administrative path, and console access to it is equivalent to physical/root access. That's the same trust boundary as with most virtual appliances: scope the vCenter Console Interaction privilege to the administrators who should be able to reach it, the same way you'd control physical access to a rack-mounted device.

Networking, security, and data handling