Skip to content
English
Customer portal
Contact us
  • There are no suggestions because the search field is empty.

01.09 Installing the VMware Appliance

Import SimpleRisk's pre-built VMware appliance on Workstation, Fusion, or ESXi — verifying the download, raising the ancient exported hardware version, mapping the network on ESXi where NAT does not exist, and rotating the five published default credentials before the machine holds anything real.

Why this matters

The VMware appliance is the shortest path from "I want to look at SimpleRisk" to a working instance. It's a pre-built Ubuntu virtual machine with Apache, PHP, MySQL, and SimpleRisk already installed and already configured — it ships past the initial configuration wizard, so there's no health check to satisfy, no database to create, and no schema to fetch. Download, verify, import, boot, log in.

That convenience comes with an ownership transfer that's easy to miss. The appliance is a starting image, not a managed product. The moment it powers on you own the operating system inside it: the OS patching, the MySQL administration, the TLS certificate, the backups, and — most urgently — the set of published default credentials it ships with. An appliance imported and left at its defaults is a SimpleRisk instance whose OS login, root account, and administrator account are documented on our public knowledge base. Fine for a laptop evaluation, entirely inappropriate for anything holding real risk data.

Once it's up, the appliance behaves exactly like a native Linux installation — same application, same Extras, same upgrade mechanics, same cron jobs.

Before you start

  • A VMware hypervisor. This article is written against VMware Workstation Pro 17.x on Windows and Linux, Fusion 13.x on macOS, and ESXi/vSphere 8.x. On the older Workstation Player the import screens are equivalent — Player was folded into Workstation Pro in the 17.x line — so menus may be named slightly differently.
  • Hardware virtualization enabled in firmware (Intel VT-x or AMD-V). The appliance is a 64-bit guest and VMware refuses to power one on without it. The first thing to check if the machine won't start.
  • Free disk space on the host — roughly 6 GB to get started, with headroom toward 64 GB. The download is about 1.06 GB compressed, the packaged disk another 1.08 GB. The disk declares 64 GiB but only about 2.9 GB is populated at first boot; it grows as data accumulates and never shrinks.
  • A networking decision, made before first boot. The exported adapter is NAT. On Workstation and Fusion that's reachable from the host but nowhere else; on ESXi there is no NAT at all and you must map the network during import. Step 4 covers all three cases.
  • A password manager, open. Step 7 rotates five secrets in one sitting.

Step-by-step

1. Download the appliance and verify the checksum

Go to https://www.simplerisk.com/download/vm and use the VMware appliance link. You'll get simplerisk-{version}-vmware.zip, roughly 1.06 GB.

Alongside the link, the page publishes an MD5 checksum for that specific release. Verify before unpacking.

# Windows, PowerShell
Get-FileHash -Algorithm MD5 .\simplerisk-{version}-vmware.zip

md5sum simplerisk-{version}-vmware.zip   # Linux
md5 simplerisk-{version}-vmware.zip      # macOS

Compare against the checksum next to the link you actually used — the VMware and VirtualBox appliances have different checksums, and every release has its own. If they don't match, delete and download again.

2. Unpack the archive

Unlike the VirtualBox appliance, the VMware archive contains three files:

  • simplerisk-{version}.ovf: The appliance descriptor — the file you point VMware at
  • simplerisk-{version}-disk1.vmdk: The disk image, stream-optimized VMDK
  • simplerisk-{version}.mf: The OVF manifest: SHA1 digests of the other two, which VMware verifies on import

Keep all three together. The descriptor references the disk by relative filename and the manifest covers both, so separating them fails the import.

The manifest is worth understanding before you touch anything. Because it pins SHA1 digests of the descriptor and the disk, any edit to the OVF invalidates it and the import fails verification. If you need to change the declared hardware, do it in the hypervisor after import (Step 4) — never by editing the descriptor.

3. Import the appliance

On Workstation Pro or Fusion. Open the .ovf: File → Open in Workstation Pro, File → Import in Fusion. Name the machine, pick a storage location, start the import. VMware verifies the manifest, converts the stream-optimized disk to its normal working format, and registers the machine. A few minutes, most of it disk conversion.

On ESXi or vSphere. Use Deploy OVF Template in the vSphere Client, or ovftool. Upload all three files together. Two prompts here have no desktop equivalent:

  • Network mapping. The appliance declares a network literally named NAT. ESXi has no NAT network, so the wizard asks you to map it to one of your port groups. Pick the one the instance should actually live on — the name in the descriptor is meaningless on ESXi.
  • Disk provisioning. Thin keeps the footprint near the ~2.9 GB actually populated and lets it grow toward 64 GiB. Thick reserves the full 64 GiB immediately.
ovftool --acceptAllEulas --diskMode=thin \
  --network="{your-port-group}" \
  simplerisk-{version}.ovf \
  vi://{user}@{esxi-host}/

4. Settle the machine's hardware and networking

Upgrade the VM hardware compatibility. The appliance is exported at vmx-07 — VMware hardware version 7, which predates most features your hypervisor now offers and sits close to the floor of what current releases support. Powered off, use VM → Manage → Change Hardware Compatibility in Workstation Pro, or Actions → Compatibility → Upgrade VM Compatibility in the vSphere Client, and raise it to the newest your host supports. Snapshot first if offered.

Leave the storage controller alone. The disk hangs off an LSI Logic Parallel controller. That's a legacy choice — modern VMware defaults are LSI Logic SAS or VMware Paravirtual — but the guest is configured to boot from it. Switching controller type on an already-installed guest is a good way to produce an unbootable machine, and there's no performance problem here worth that risk on an evaluation appliance.

Then decide how the machine reaches the network. The exported adapter is a single E1000 on NAT, and what NAT means differs sharply by product:

NAT (Workstation, Fusion)

  • Reaching the interface: http://{guest-IP}/ from the host only
  • Use when: Single-user evaluation. Your host has an interface on the NAT subnet so it reaches the guest directly — but nothing else on your network can. Safest default while the appliance still has stock credentials.

Bridged (Workstation, Fusion)

  • Reaching the interface: http://{guest-IP}/ from any machine on the network
  • Use when: Shared demonstrations and pilots. The machine takes a DHCP address like a physical host.

A real port group (ESXi, vSphere)

  • Reaching the interface: http://{guest-IP}/ from wherever that port group routes
  • Use when: Any server-side deployment. You chose this during import; NAT doesn't exist on ESXi.

Change it under VM Settings → Network Adapter on the desktop products, or by editing the network adapter in the vSphere Client. On corporate networks, bridging exposes a new MAC to the switch, which port security or network access control may reject.

One thing you don't need to worry about on VMware: the descriptor also carries a block of VirtualBox-specific configuration, including a remote-display server pointed at certificate paths from the build machine. It's marked optional, so VMware ignores it entirely. If ovftool mentions unsupported or ignored elements, that block is why, and the warning is harmless.

5. Boot the appliance and log in at the console

Power on and let it boot to a console login prompt.

Login:    simplerisk
Password: simplerisk

This account has sudo, authenticated with the same password. You'll need it in Step 7.

6. Reach the web interface

Find the guest's address at the console:

ip addr show

Ignore loopback (lo, 127.0.0.1) and take the IPv4 address on the Ethernet interface, then browse to http://{that-address}/.

Where you can browse from depends on the adapter mode from Step 4. On the default NAT adapter that address is on a private VMware subnet: your host reaches it, other machines on your network cannot, however routable the address looks. If colleagues need access, switch to bridged and re-read the address.

Log in to SimpleRisk with admin / admin.

7. Change every default credential

Do this before the appliance holds real data. The appliance ships five secrets at published defaults. Until they're rotated, treat the machine as an open instance and keep it on NAT.

  1. The simplerisk OS user — run passwd at the console.
  2. The OS root account — sudo passwd root.
  3. The MySQL root user. Generated at first boot and left in /root/root_mysql_password.txt. Read it, change it with mysqladmin -u root -p password '{new-password}', then delete the file.
  4. The MySQL simplerisk application user — ALTER USER 'simplerisk'@'localhost' IDENTIFIED BY '{new-password}'; then FLUSH PRIVILEGES;. The second half is easy to forget: update DB_PASSWORD in /var/www/simplerisk/includes/config.php to match, or the application loses its database connection on the very next request.
  5. The SimpleRisk admin account — in the web interface, My Profile → change the password, and set a real email address so password resets and notifications work.

On ESXi, consider VM encryption for anything holding real data.

8. Record your baseline and finish the standard setup

Record what you actually received. You're responsible for patching this stack:

cat /etc/os-release   # Ubuntu release, for the OS patch cadence
php -v                # SimpleRisk requires PHP 8.3.0 or newer
mysql --version

Then complete the post-installation work any deployment needs:

  • Set the base URL to the address your users will actually type, so emailed links resolve.
  • Put a real certificate in front of it — see HTTPS and TLS Configuration.
  • Confirm the cron jobs are scheduled — see The Cron Jobs.
  • Set up database backups that ship off the host — see Database Backup and Restore.
  • Register the instance for the free Upgrade and SCF Extras — see Registration and Licensing.
  • Take a snapshot of the freshly hardened, freshly configured appliance, and take another before every upgrade.

Giving the appliance a static address

A bridged appliance takes a DHCP lease, which is fine for a demonstration and wrong for anything people bookmark. To pin it, edit the guest's netplan configuration.

Find the adapter name first:

ip addr show

Then edit sudo vi /etc/netplan/01-netcfg.yaml, replacing ens3 with your adapter and the addresses with yours:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: no
      addresses:
        - 192.168.1.199/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8, 1.1.1.1]

Apply with sudo netplan apply. No output means success; confirm with ip addr show.

Two things to get right, because both are easy to miss:

  • The address and gateway must be on the same subnet. An address of 192.168.121.199/24 with a gateway of 192.168.1.1 cannot work — the gateway isn't reachable from that network. Match the first three octets.
  • Use routes:, not gateway4:. Older guides use gateway4, which netplan deprecated; current Ubuntu warns on it and it will eventually stop working.

Changing the address changes the URL your users type, so update the SimpleRisk base URL to match afterwards.

Growing the appliance disk

The disk declares 64 GiB, is thin-provisioned, and never shrinks. The usual reason to resize is hitting that ceiling on a long-lived instance.

Two parts, and people routinely do only the first and wonder why nothing changed:

  1. Grow the virtual disk. Power off, then VM Settings → Hard Disk → Expand on the desktop products (or edit the disk size in the vSphere Client) and set the new size.

  2. Grow the partition and filesystem inside the guest, so the OS can see the new space. Boot a live Ubuntu ISO — attach it under VM Settings → CD/DVD → Use ISO image file, then interrupt the boot with F2 to put the CD-ROM ahead of the disk in the boot order. Choose Try Ubuntu, extend the partition with a partition editor, then extend the filesystem. On the appliance's LVM layout that's lvextend followed by resize2fs.

Take a snapshot before you start. Partition surgery on a machine holding real risk data is worth one cheap rollback point.

Common pitfalls

  • Expecting NAT to behave the way it does on VirtualBox. On VMware Workstation and Fusion, the host can reach a NAT guest directly at its own address — no port forwarding needed. On VirtualBox it cannot. If you're moving between the two, that difference will catch you out.

  • Expecting NAT to exist on ESXi. It doesn't. If you didn't map the declared NAT network to a real port group during import, the machine has nowhere to talk.

  • Editing the OVF descriptor. The manifest pins SHA1 digests of the descriptor and the disk. Any edit invalidates it and the import fails verification. Change hardware after import, in the hypervisor.

  • Leaving the machine at hardware version 7. vmx-07 is close to the floor of what current hypervisors support and will eventually drop off it entirely. Raise it while the machine is empty and the change is cheap.

  • Switching the storage controller to something modern. The guest boots from LSI Logic Parallel. Changing it on an already-installed guest is a reliable way to produce a machine that won't boot.

  • Chasing "unsupported element" warnings from ovftool. The descriptor carries an optional VirtualBox configuration block. VMware ignores it. The warning is harmless.

  • Leaving the defaults in place "just for now." The OS password, root password, and administrator password are published in our public knowledge base. An appliance on a bridged corporate network with stock credentials is an open instance.

  • Treating the appliance as maintained by SimpleRisk. The image is a point-in-time build. Nothing patches its Ubuntu, PHP, or MySQL but you.

  • Upgrading by importing the next appliance. A newer appliance is a new, empty instance. It doesn't carry your data across. Upgrade in place, exactly as you would any Linux installation, and snapshot first.

  • Running a real deployment on the exported 2 GB and 2 virtual CPUs. Those suit an evaluation. A mid-size deployment wants 2–4 virtual CPUs and 4–8 GB, and the appliance runs Apache, PHP, and MySQL together on one host.

  • Mistaking a snapshot for a backup. A snapshot of a running machine captures MySQL mid-transaction and usually lives on the same datastore. Good rollback point; not a backup strategy.

  • Skipping the checksum because the download "looks fine." VMware verifies the manifest, but the manifest only proves the three files agree with each other — the MD5 on the download page is what proves you got the file we published.

  • Clock drift after the host sleeps. Suspending a laptop suspends the guest's clock. A drifted guest produces cron jobs that fire late or not at all and audit-trail entries in the wrong order. Confirm with timedatectl status, and check VMware Tools time synchronization.

What the appliance ships with

  • Artifacts: simplerisk-{version}-vmware.zip (about 1.06 GB), containing simplerisk-{version}.ovf (OVF 1.0 envelope), simplerisk-{version}-disk1.vmdk (stream-optimized VMDK, about 1.08 GB), and simplerisk-{version}.mf (manifest, SHA1 digests of the other two).
  • Declared hardware: VMware hardware version 7 (vmx-07); Ubuntu 64-bit guest; 2 virtual CPUs; 2048 MB RAM; one 64 GiB thin-provisioned disk (about 2.9 GB populated) on an LSI Logic Parallel SCSI controller; one E1000 adapter on a network named NAT; BIOS firmware.
  • Ignored on VMware: An optional VirtualBox machine block (display adapter, remote-display server with build-host certificate paths, VirtualBox NAT semantics). Marked not required, so VMware ignores it — and it's the source of any "unsupported element" warning from ovftool.
  • Default credentials: OS: simplerisk / simplerisk (sudo-capable). MySQL root: generated at first boot, written to /root/root_mysql_password.txt. MySQL application user: simplerisk @ localhost. Application: admin / admin. All must be rotated — see Step 7.

Related