01.09 Installing the VMware Appliance

Written against VMware Workstation Pro 17.x, Fusion 13.x, and ESXi 8.x. Verified against appliance release 20260519-001.

Introduction

The VMware appliance is the shortest path from “I want to look at SimpleRisk” to a working instance. It is a pre-built Ubuntu virtual machine with Apache, PHP, MySQL, and SimpleRisk already installed and already configured — the appliance ships past the initial configuration wizard, so there is no health check to satisfy, no database to create, and no schema to fetch. Download, verify, import, boot, log in. For evaluations, proof-of-concept work, training environments, and air-gapped demonstrations, it removes every install-time variable at once.

That convenience comes with an ownership transfer that is easy to miss. The appliance is a starting image, not a managed product. The moment it boots on your hypervisor, you own the operating system inside it: the OS patching, the MySQL administration, the TLS certificate, the backups, and — most urgently — the sets 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. That is entirely appropriate for a laptop evaluation and entirely inappropriate for anything holding real risk data.

This guide covers importing and networking the appliance on VMware Workstation Pro, VMware Fusion, and ESXi or vSphere. Once it is up, the appliance behaves exactly like a native Linux installation — the same application, the same Extras, the same upgrade mechanics, the same cron jobs — and the Administrator Guide covers it from there. If you run into any issues, please contact us at support@simplerisk.com.

Before You Start

Have these in hand before you begin:

A VMware hypervisor. This guide is written against VMware Workstation Pro 17.x on Windows and Linux, VMware Fusion 13.x on macOS, and ESXi/vSphere 8.x. If you are still running VMware Workstation Player, the import screens are equivalent — Player was folded into Workstation Pro in the 17.x line, so the menus may be named slightly differently than described here.
Hardware virtualization enabled in firmware (Intel VT-x or AMD-V). The appliance is a 64-bit guest, and VMware will refuse to power on a 64-bit virtual machine without it. On most business laptops this is enabled by default, but it is the first thing to check if the machine will not 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 image is another 1.08 GB, and the appliance's disk is thin-provisioned: it declares a 64 GiB capacity but only about 2.9 GB is actually populated at first boot. It grows as the instance accumulates data, and it never shrinks on its own.
A networking decision, made before first boot. The appliance's exported network adapter is NAT. On Workstation and Fusion that is reachable from the host but from 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. Generating and storing them as you go is far easier than reconstructing afterward which ones you changed.

Instruction

Step 1: Download the appliance and verify the checksum

Go to https://www.simplerisk.com/download/vm and use the VMware appliance download link. You will receive a single zip archive named for the release you downloaded — simplerisk-{version}-vmware.zip, roughly 1.06 GB.

Alongside the download link, the page publishes an MD5 checksum for that specific release. Verify your download against it before unpacking anything.

On Windows, using PowerShell:

Get-FileHash -Algorithm MD5 .\simplerisk-{version}-vmware.zip

On Linux or macOS:

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

Compare the result against the checksum shown next to the link you actually used — the VMware and VirtualBox appliances have different checksums, and every release has its own. If the values do not match, delete the file and download it again. Do not import a mismatched image.

Step 2: Unpack the archive

Extract the zip file to a location with room to spare. 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, in stream-optimized VMDK format.
`simplerisk-{version}.mf`	The OVF manifest: SHA1 digests of the other two files. VMware verifies these on import.

Keep all three files together in the same directory. The descriptor references the disk image by relative filename, and the manifest covers both — separating them causes the import to fail.

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 file invalidates the manifest and the import will fail verification. If you need to change the appliance's declared hardware, do it in the hypervisor after import (Step 4), not by editing the descriptor.

Step 3: Import the appliance

On Workstation Pro or Fusion

Open the .ovf file: in Workstation Pro choose File → Open and select the descriptor; in Fusion choose File → Import. Give the virtual machine a name and a storage location, then start the import. VMware verifies the manifest, converts the stream-optimized disk into its normal working format, and registers the machine. It takes a few minutes, most of which is the disk conversion.

On ESXi or vSphere

Use Deploy OVF Template in the vSphere Client, or ovftool from the command line. Upload all three files (descriptor, disk, and manifest) together. Two prompts in this path have no equivalent on the desktop products:

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 port group the instance should actually live on; the name in the descriptor is meaningless on ESXi.
Disk provisioning. Choose thin or thick. Thin keeps the footprint near the roughly 2.9 GB the appliance actually populates and lets it grow toward 64 GiB; thick reserves the full 64 GiB immediately.

The command-line equivalent looks like this:

ovftool --acceptAllEulas --diskMode=thin \
  --network="{your-port-group}" \
  --name="simplerisk" \
  simplerisk-{version}.ovf \
  vi://{user}@{esxi-host}/

The appliance declares its hardware as VMware virtual hardware version 7 (vmx-07), which is old. Current ESXi releases can still run it, but you should raise it after import — see Step 4.

Step 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 is close to the floor of what current releases support. With the machine 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 version your host supports. Take a snapshot first if the option is offered.

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

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

Mode	Reaching the interface	Use when
NAT (Workstation, Fusion)	`http://{guest-IP}/` from the host only	Single-user evaluation on a laptop. Your host has an interface on the NAT subnet, so the host browser reaches the guest directly — but nothing else on your network can. This is the safest default while the appliance still has its stock credentials.
Bridged (Workstation, Fusion)	`http://{guest-IP}/` from any machine on the network	Shared demonstrations and pilots — anything more than one person needs to reach. The machine takes an address from your network's DHCP like a physical host.
A real port group (ESXi, vSphere)	`http://{guest-IP}/` from wherever that port group routes	Any server-side deployment. You chose this during import; NAT does not exist on ESXi.

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

One thing you do not 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 machine that built the image. It is marked as optional in the descriptor, so VMware ignores it entirely. If ovftool mentions unsupported or ignored elements, that block is why, and the warning is harmless.

Step 5: Boot the appliance and log in at the console

Power on the virtual machine and let it boot to a console login prompt. Log in with the appliance's default operating system credentials:

Login:    simplerisk
Password: simplerisk

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

Step 6: Reach the web interface

Find the guest's address at the console:

ip addr show

Ignore the loopback interface (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 you chose in Step 4. On the default NAT adapter, that address is on a private VMware subnet: your host can reach it, but other machines on your network cannot, no matter that the address looks routable. If you need colleagues to reach the instance, switch the adapter to bridged and read the new address.

You should arrive at the SimpleRisk login page. The appliance ships already installed, so the default application credentials are:

Username: admin
Password: admin

If you instead arrive at the installation wizard, the appliance's install state did not survive the import — uncommon, and usually a sign that the download was incomplete. Re-verify the checksum from Step 1, and if it is correct, complete the installation using the initial configuration wizard documented in the Administrator Guide.

Step 7: Change every default credential

Do this before the appliance holds real data

The appliance ships with five secrets at published defaults. Until they are rotated, treat the machine as an open instance and keep it on NAT rather than bridged or a routable port group.

Rotate all five in one sitting. The knowledge base article How to Secure Your SimpleRisk VM gives the step-by-step commands; the inventory is:

The simplerisk operating system user — run passwd at the console.
The operating system root account — run sudo passwd root.
The MySQL root user. The appliance generates a MySQL root password on first boot and leaves it in a file in /root (root_mysql_password.txt). Read it, change the password with mysqladmin -u root -p password '{new-password}', then delete the file.
The MySQL simplerisk application user — ALTER USER 'simplerisk'@'localhost' IDENTIFIED BY '{new-password}'; followed by FLUSH PRIVILEGES;. This one has a second half that 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 next request.
The SimpleRisk admin account — in the web interface, go to Admin → My Profile and change the password. While you are there, set a real email address so password resets and notifications work.

On a laptop that leaves the building with risk data on it, consider VMware's own encryption for the virtual machine as well, under VM Settings → Options → Access Control in Workstation Pro or Fusion. On vSphere, use VM Encryption with your key provider.

Step 8: Record your baseline and finish the standard setup

The appliance is now an ordinary SimpleRisk installation on a Linux host that you own. Three closing tasks.

Record what you actually received. You are responsible for patching this stack, so establish what is in it:

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

Confirm the VMware guest tools are present. They provide clean guest shutdown from the hypervisor, time synchronization, and quiesced snapshots — all of which matter more on VMware than the appliance's defaults suggest:

systemctl status open-vm-tools

If the service is not installed, add it with sudo apt install open-vm-tools and enable it.

Then complete the same post-installation work that any deployment needs, none of which the appliance can do for you:

Set the base URL to the address your users will actually type, so that emailed links resolve. A mismatched base URL is the usual cause of “the link in the notification goes nowhere.”
Put a real certificate in front of it if this is anything more than a laptop demonstration.
Confirm the cron jobs are scheduled and running. Notifications, scheduled reports, and maintenance tasks all depend on them.
Set up database backups on a schedule that ships the output off the host.
Take a snapshot of the freshly hardened, freshly configured appliance. It is the cheapest rollback point you will ever have, and the right thing to take again before every upgrade.
Install the Extras you are licensed for.

Common Pitfalls

A handful of patterns recur with appliance deployments.

Expecting colleagues to reach a NAT-mode appliance. On Workstation and Fusion, NAT puts the guest on a private VMware subnet that only the host can reach. The address the console prints looks like an ordinary private address, which makes this confusing: the host works, everyone else times out. Switch the adapter to bridged for shared access.
Editing the OVF descriptor. The archive ships a manifest pinning SHA1 digests of the descriptor and the disk, so hand-editing the OVF — to bump the hardware version, rename the network, change the memory — makes the import fail verification. Import first, adjust the machine afterward.
Manifest verification failing on newer tooling. The manifest uses SHA1, which current VMware tooling treats as deprecated and which strict or FIPS-mode configurations may refuse outright. If the import stops on a manifest or digest error, that is the cause. ovftool --skipManifestCheck bypasses it — but only do that after you have verified the download's published MD5 yourself, because skipping the manifest removes the last integrity check in the chain.
Leaving the machine at hardware version 7. vmx-07 is close to the oldest version current hypervisors support, and a future upgrade of your host may drop it. Raising compatibility is a two-minute, powered-off operation; doing it now avoids a migration surprise later.
Switching the SCSI controller to Paravirtual for “performance.” The guest is installed against LSI Logic Parallel. Changing the controller under a booted-and-installed guest risks an unbootable machine for a gain no evaluation instance will notice.
Deploying to ESXi and losing the network. The descriptor's network is named NAT, which means nothing on ESXi. If you accept the wizard's defaults without mapping it, the machine can land on whatever port group happened to be first — possibly one that does not route where you expect.
Leaving the defaults in place “just for now.” The operating system password, the root password, and the administrator password are published in our public knowledge base. An appliance on a routable 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 packages, its PHP, or its MySQL but you. An appliance imported and never updated accumulates operating-system vulnerabilities indefinitely, regardless of how current the SimpleRisk application inside it is.
Upgrading by importing the next appliance. A newer appliance is a new, empty instance. Importing it does not carry your data across, and running the two side by side on the same network invites confusion about which one is real. Upgrade the appliance in place, exactly as you would any Linux installation, and take a snapshot first.
Running a real deployment on the exported 2 GB and 2 virtual CPUs. Those defaults suit an evaluation. The Administrator Guide puts a mid-size deployment at 2–4 virtual CPUs and 4–8 GB of RAM, and the appliance runs Apache, PHP, and MySQL together on one host. Raise the allocation before you load frameworks or import scanner data, not after users start reporting slow pages.
Assuming the 64 GiB disk is a fixed cost, or that it can be reduced. The disk declares 64 GiB but populates only about 2.9 GB at first boot, then grows as data accumulates. It does not shrink when data is deleted. Watch the datastore or host free space.
Mistaking a snapshot for a backup. A snapshot of a running machine captures MySQL mid-transaction, and it lives on the same storage as the machine itself. It is an excellent rollback point for an upgrade and it is not a backup strategy. Snapshots left in place also grow, and on a datastore that fills, they take the machine down with them.
Skipping the checksum because the download “looks fine.” A truncated download can still import and then fail later in ways that look like application defects. The verification is one command.
Clock drift after the host sleeps. Suspending a laptop suspends the guest's clock with it. A guest whose time has drifted produces cron jobs that fire late or not at all, notification timestamps that do not line up, and audit-trail entries in the wrong order. Confirm time synchronization inside the guest with timedatectl status, and that open-vm-tools is running.

Appliance Reference

Appliance 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 files).
Declared hardware	VMware virtual 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 network adapter on a network named `NAT`; BIOS firmware.
Ignored on VMware	The descriptor also carries an optional VirtualBox machine block (display adapter, remote-display server with build-host certificate paths, VirtualBox NAT semantics). It is marked not required, so VMware ignores it; it is the source of any “unsupported element” warnings from `ovftool`.
Default credentials	Operating system: `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.
Key paths in the guest	`/var/www/simplerisk/` (web root), `/var/www/simplerisk/includes/config.php` (database credentials, written when the image was built), `/var/www/simplerisk/logs/` (operational logs).
Database	The full schema, already created and populated when the image was built. No install-time schema fetch is performed.
Host requirements	VMware Workstation Pro 17.x, Fusion 13.x, or ESXi/vSphere 8.x, with hardware virtualization enabled. Outbound HTTPS from the guest is required for Extras, framework content, and update checks.

Summary

These instructions should have allowed you to download, verify, import, network, and secure the SimpleRisk VMware appliance on Workstation Pro, Fusion, or ESXi, and to reach a working SimpleRisk instance in your browser. If you have run into any issue or have questions, please contact us at support@simplerisk.com.