Expert

Increasing available disk space

To increase the available disk space, you simply need to add a new disk to the FortiPoC VM in your hypervisor. FortiPoC will detect it and add it to it’s resource disk volume.

Danger

you CAN’T remove a disk once it’s used by FortiPoC, doing so will prevent FortiPoC to run.

If your hypervisor properlly support disk hot-plug, you simply need to run execute disk extend after adding a disk else you need to reboot the FortiPoC.

You can also increase the size of the FortiPoC disk, on next reboot FortiPoC should detect the change and add available free space to the resource volume.

Local repository

The local repository is a repository available on your FortiPoC VM. It allows you to test new device images.

Copying images

Using the CLI:

  1. you need to enable the local repository with the following CLI command: repo local enable. Once enabled, you don’t need to issue this command anymore.

  2. copy images from your computer to the FortiPoC local repository: scp FGT_interim_from_infosite.out.kvm.zip admin@FORTIPOC_IP:images/

  3. then build the repository information with the following CLI command: repo local build

  4. the new image is now listed in the Repositories/Images on the WebUI

For advanced usage, you can open a shell in the local repository with repo local shell.

Split firmware

Local repository accepts “split directory” as “archive” of firmware. To enable this feature, local repository checksum must be disabled (default for new 1.7 instance, use repo local chksum disable if you have upgraded from 1.5) and the “split directory” must contain a .split file, ex:

images/FGT_VM64_KVM-v5-build0323-FORTINET-custom.out.kvm.zip/fortios.qcow2
                                                            /.split

FortiPoC tries to adjust disk filename in meta according to “split directory” content. Example: for FWB the disk should be image-kvm-64/boot.qcow2 so both of these split directories will work:

images/FWB_KVM-v500-build0856-FORTINET.out.kvm.zip/image-kvm-64/boot.qcow2
images/FWB_KVM-v500-build0856-FORTINET.out.kvm.zip/.split

or:

images/FWB_KVM-v500-build0856-FORTINET.out.kvm.zip/boot.qcow2
images/FWB_KVM-v500-build0856-FORTINET.out.kvm.zip/.split

Device expert settings

libvirt/KVM XML customization

You can now override some of the libvirt/kvm XML nodes using meta new expert settings:

{
  "definition": {
    ...
    "settings" {
      ...
      "expert": {
        EXPERT_SETTINGS
      }
    },
  ...
}

or device’s advanced parameters/expert settings.

The expert settings is used to customize XML at the end of the generation, user are allowed to override ‘os’, ‘features’, ‘cpu’ and ‘cputune’ nodes, look to libvirt domain doc for content of each sub-tree.

The EXPERT_SETTINGS format is:

{
  "cpu": { # the node <cpu>
    "model": # the sub node <model> under <cpu>
      {
        "": "Haswell-noTSX", # the text: <model>Haswell-noTSX</model>
        "fallback": "allow"  # an attribute: <model fallback="allow">Haswell-noTSX</model>
      },
      "vendor": {"": "Intel" }, # <vendor>Intel</vendor> under <cpu>
      "feature": [ # multiple <feature> nodes under <cpu>
        [
          {"name": "vme"}, # matching rule get or create <feature name="vme">
          {"policy": "disable"} # update rule (can also specify text with "" empty key) <feature name="vme" policy="disable">
        ],
        [{"name": "x2apic"}, {"policy": "disable"}] # <feature name="x2apic" policy="disable">
      ]
  }, ...
  "os": ...
}

You can imbricate as many levels as needed.

Access Customization

In the expert settings, you can add access or customize some of them.

Standard accesses

For private, public or disabled access see Security Policy.

You can also customize some HTTP/HTTPS parameters:

  • the default path to open

  • the tooltip credentials

  • the destination port

Example: HTTPS access with a default path as /admin instead of / and with different credentials on port 10443:

{
  "accesses": {
    "HTTPS": {
       "path": "/admin",
       "port": 10443,
       "credentials": {
         "login": "manager",
         "password": "admin123"
       }
     }
  }
}

You can also extend standard accesses with custom entries.

Example: add HTTPS access named ADMIN for the /admin path, keeping default HTTPS access:

{
  "accesses": {
    "ADMIN": {
       "access": "HTTPS",
       "path": "/admin"
     }
  }
}

As now HTTP/HTTPS access is done using reverse proxy, if the device interface is using websocket, you may have to define the web socket path if not already known by FortiPoC, eg:

{
  "accesses": {
    "HTTPS": {
       "ws": [ "/ws/" ]
     }
  }
}

Or you can disable default web socket path with:

{
  "accesses": {
    "HTTPS": {
       "ws": [ ]
     }
  }
}

Custom accesses

Automatic port

You can override the automatic forwarding port for SSH, HTTP and HTTPS, ex:

{
  "accesses": {
    "SSH": {
       "listen_port": 20000
     },
    "HTTP": {
       "listen_port": 20080
     },
    "HTTPS": {
       "listen_port": 20443
     }
  }
}

You DON’T need to add a custom port forwarding rule for this port.

Warning

You must ensure that the selected port is not already used.

HTTP/HTTPS

You can also define new HTTP/HTTPS accesses for custom port forwarding rules.

Warning

the access entry doesn’t provision the port forwarding rule whatever fwd value is set. Add port forwarding rule in the Networks/Advanced Parameters/Ports Redirections in the PoC definition.

In this case you must define the listening port with the listen_port key and the destination port with port.

Example: add a HTTPS access named ADMIN from port 20000 to port 10443:

{
  "accesses": {
    "ADMIN": {
       "port": 10443,
       "listen_port": 20000,
       "access": "HTTPS"
     }
  }
}

Waiting mgmt interface

By default FortiPoC tries 15 times to ping the configured management interface with a 1 second wait between each failed tries.

You can customize these two values in the device expert settings, time is in seconds:

{
  "timeout": {
    "time": 5,
    "tries": 30
  }
}

You can also add an extra explicit sleep time (workaround for #1059237):

{
  "special": {
    "preconfigure": {
      "sleep": 10
    }
  }
}

Default CDROM bus

By default the CDROM bus is an IDE bus, you can switch it in meta firmware:

{
  "bus": {
    "cdrom": "sata"
  }
}

Or you can override in device expert settings:

{
  "cdrom": "sata"
}

Passthrough of devices

Warning

by using this feature you can break you FortiPoC or you hypervisor, including hardware. USE AT YOUR OWN RISK.

For people using a baremetal FortiPoC, you can pass physical devices to your VM.

Enable video passthrough

To pass a video device, you must first enable the video passthrough in FortiPoC with:

expert video passthrough enable

Don’t forget to reboot once done.

Configure passthrough to the VM

Simple form

When you only have one video device, mouse and keyboard, you can simply use in device expert settings:

{
  "passthrough": true
}

It will pass the first detected PCI Video, USB Keyboard and Mouse devices to the VM.

Detailed form

If you have multiple video devices, you can list them with expert video info:

fortipoc # expert video info
<PCIDevice id='1b36:0100' domain='0000' bus='00' slot='02' function='0'>
<PCIDevice id='1b36:0100' domain='0000' bus='00' slot='03' function='0'>

You can also list USB device with expert usb ls:

fortipoc # expert usb ls
mouse:
<USBDevice name='Bus 001 Device 008: ID 1532:0037 Razer USA, Ltd DeathAdder 2013' vendor='0x1532' product='0x0037' subclass='1' protocol='2'>
keyboard:
<USBDevice name='Bus 001 Device 007: ID 413c:2113 Dell Computer Corp. KB216 Wired Keyboard' vendor='0x413c' product='0x2113' subclass='1' protocol='1'>

You can specify the index (from 1) of the device to use for each device:

{
  "passthrough": {
    "video": 2,
    "mouse": 2,
    "keyboard": 1
   }
}

Or you specifically tell which devices to use, ex:

{
  "passthrough": {
    "video": {"domain": "0x0000", "bus": "0x00", "slot": "0x02", "function": "0x00"},
    "mouse": {"vendor": "0x1532", "product": "0x0037"},
    "keyboard": {"vendor": "0x413c", "product": "0x2113"}
  }
}

You can also mix both forms, ex:

{
  "passthrough": {
    "video": {"domain": "0x0000", "bus": "0x00", "slot": "0x02", "function": "0x00"},
    "mouse": 1,
    "keyboard": 2
  }

When you dump XML definition of the VM, should see some hostdev devices, ex:

fortipoc # expert virsh dumpxml lubuntu
<domain type='kvm'>
...
  <devices>
    ...
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x1531'/>
        <product id='0x0037'/>
      </source>
      <address type='usb' bus='0' port='1'/>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x413c'/>
        <product id='0x2113'/>
      </source>
      <address type='usb' bus='0' port='2'/>
    </hostdev>
    ...

TPM

Important

Support of TPM is only available since FortiPoC 1.9.

The virtual TPM module is always added to the VM definition (but not available for LXC).

Secure Boot and UEFI

Important

Support of UEFI is only available since FortiPoC 1.9.

To enable a UEFI for a VM, add in the device’s Advanced Parameters Expert settings:

{"special": {"uefi": true}}

or in the meta settings:

... "settings": {"uefi": true} ...

In similar way you can also specify the “machine”, the “loader” and the “nvram” to use.

machine

standard values are “pc” (for i440fx) or “q35”, system will use the latest available version of each. Default loaders are: * for “q35”: OVMF_CODE_4M.secboot.fd * for “pc”: OVMF_CODE_4M.fd

nvram

only when uefi is enabled: should be the NVRAM file’s name provided in the firmware archive. Exception for standard NVRAM filename (like “OVMF_VARS_4M.fd” or “OVMF_VARS_4M.ms.fd”) that automatically uses system file if such NVRAM file is not present in the firmware archive. Default NVRAM file is: OVMF_VARS_4M.fd

loader

only when uefi is enabled: should be the loader file name provided in the firmware archive. Exception for standard LOADER filename (like “OVMF_CODE_4M.fd” or “OVMF_CODE_4M.secboot.fd”) that automatically uses system file if such LOADER file is not present in the firmware archive. Default LOADER: see machine.

For more information about the available system NVRAM and LOADER files see Debian EDK2 README.

Network interface model

You can overide default network interface model, example to use “e1000” instead of default “virtio”:

{"network": "e1000"}

Warning

If the device use different models (FTS firwares are using a mix of “e1000” (mgmt) and “virtio”), this parameter overides only the default global value (for FTS you can override “virtio” by “e1000”, but not the “e1000” (mgmt) to “virtio”).