Views: 6
Wazuh 5.0 is currently in beta, and the project also ships it as a ready-to-run OVA appliance. That’s convenient if you just want to kick the tyres on the new release, but Proxmox doesn’t import OVAs natively the way it does with qm importdisk for raw/qcow2 images — you have to unpack the appliance and rebuild the VM definition by hand with qm.
This walkthrough explains exactly how I got the Wazuh 5.0 beta OVA running as a VM on Proxmox, end to end: extracting the appliance, importing the disk, tuning the virtual hardware, and getting into the dashboard for the first time. Treat this as a lab/beta build — not a production deployment — and expect some of these steps to shift once Wazuh 5.0 goes GA.
Before you start
- A Proxmox node with enough headroom for 4 vCPUs / 8 GB RAM (the resource profile used below) [Note: Wazuh recommends 8 vCPU and 16 GB RAM as the minimum configuration for the VM)
- The Wazuh 5.0 beta
.ovafile downloaded from Wazuh - Root or sudo access to the Proxmox shell
- A spare VM ID and a bridge (
vmbr0or whatever your Wazuh network segment uses)
1. Upload the OVA to Proxmox
In the Proxmox web UI:
- Select your Proxmox node.
- Pick a storage that supports ISO images — normally
local. - Open ISO Images.
- Click Upload.
- Upload the Wazuh 5.0 beta
.ovafile.
It lands here on disk:
/var/lib/vz/template/iso/Confirm it from the node shell:
ls -lh /var/lib/vz/template/iso/For every command below, swap in your actual filename.
2. Create a temporary extraction directory
An OVA is just a tar archive wrapping an OVF descriptor, a disk image, and a manifest. Proxmox needs those unpacked before it can import anything.
mkdir -p /root/wazuh5-ova
cd /root/wazuh5-ovaExtract it:
tar -xvf /var/lib/vz/template/iso/wazuh-5.0.0-beta.ova
Check what came out:
ls -lhYou should see three files:
wazuh-5.0.0-beta.ovf
wazuh-5.0.0-beta-disk001.vmdk
wazuh-5.0.0-beta.mf
If you’re not sure of the exact OVF filename, this will find it for you:
find /root/wazuh5-ova -maxdepth 1 -type f -iname "*.ovf"3. Choose a VM ID and storage
Check what VM IDs are already in use:
qm listI’m using:
- VM ID:
150 - VM name:
wazuh-5-beta - Proxmox storage:
local-lvm
Confirm your storage name if it’s not the default:
pvesm statusIf your VM storage is called something else — e.g. VM-Storage — swap it in for local-lvm in every command from here on.
4. Import the OVF
qm importovf 150 /root/wazuh5-ova/wazuh-5.0.0.ovf local-lvm
Proxmox supports both a GUI import wizard and this CLI path — for appliance OVAs like this one, the CLI route is more predictable since you control every setting explicitly.
Confirm the VM exists:
qm config 150
Give it a proper name:
qm set 150 --name wazuh-5-beta
5. Configure the virtual hardware
Set CPU and memory:
qm set 150 --cores 4
qm set 150 --memory 8192
qm set 150 --balloon 0
qm set 150 --cpu host
I disable memory ballooning here on purpose — the Wazuh Indexer runs on OpenSearch, and OpenSearch behaves much better with a fixed, predictable memory ceiling than with memory that Proxmox can reclaim on the fly.
Boot settings:
qm set 150 --bios seabios
qm set 150 --ostype l26
qm set 150 --onboot 1
qm set 150 --agent enabled=1
Stick with SeaBIOS unless the appliance specifically calls for UEFI. Most OVAs, including this one, are built against conventional BIOS boot — switching to OVMF prematurely is a common reason imported appliances fail to boot at all.
6. Check the imported disk
qm config 150
Look for a line like:
scsi0: local-lvm:vm-150-disk-0or:
sata0: local-lvm:vm-150-disk-0Make sure that disk is actually in the boot order. If it’s scsi0:
qm set 150 --boot order=scsi0If it came in as sata0 instead:
qm set 150 --boot order=sata0If the disk shows up as unused0 — meaning Proxmox imported it but never attached it — attach it explicitly:
qm set 150 --scsi0 local-lvm:vm-150-disk-0
qm set 150 --scsihw virtio-scsi-single
qm set 150 --boot order=scsi0Use whatever disk identifier actually appears next to unused0 in your qm config 150 output — don’t assume it matches the example.
7. Configure the network adapter
Attach the VM to whichever Proxmox bridge carries your Wazuh server network. For a plain vmbr0 setup:
qm set 150 --net0 virtio,bridge=vmbr0,firewall=1If you’re running a VLAN-aware bridge and the Wazuh VM needs to sit on a specific VLAN:
qm set 150 --net0
virtio,bridge=vmbr0,tag=YOUR_VLAN_ID,firewall=1For example, VLAN 30:
qm set 150 --net0 virtio,bridge=vmbr0,tag=30,firewall=1If the appliance doesn’t pick up the VirtIO NIC on first boot, fall back to Intel E1000 temporarily:
qm set 150 --net0 e1000,bridge=vmbr0,firewall=1In practice this is rarely needed — Linux appliances almost always support VirtIO out of the box.
You can also do all of this from the Proxmox web GUI instead of the CLI:
8. Review the completed configuration
qm config 150A healthy configuration at this point looks roughly like:
agent: 1
balloon: 0
bios: seabios
boot: order=scsi0
cores: 4
cpu: host
memory: 8192
name: wazuh-5-beta
net0: virtio=...,bridge=vmbr0,firewall=1
ostype: l26
scsi0: local-lvm:vm-150-disk-0
scsihw: virtio-scsi-single
9. Start the Wazuh VM
qm start 150Open the console from Proxmox: VM 150 → Console.
If it doesn’t boot, re-check the config:
qm config 150The usual suspects, in order of likelihood:
- Wrong BIOS type (SeaBIOS vs. OVMF)
- Imported disk never added to the boot order
- Disk still sitting as
unused0instead of attached - Storage name typo
- Network adapter type the appliance doesn’t recognize
If SeaBIOS reports “No bootable device,” switch to UEFI as a fallback:
qm stop 150
qm set 150 --bios ovmf
qm set 150 --efidisk0 local-lvm:1,efitype=4m,pre-enrolled-keys=0
qm start 150Only reach for this if SeaBIOS genuinely fails — don’t switch preemptively.
10. Find or configure the IP address
Log in with the default credentials at the console prompt.
The appliance will typically pull an address from DHCP. Once you’re logged in, check it:
ip aor the shorter:
hostname -I
11. Access the Wazuh dashboard
Once the VM has fully finished starting up, browse to:
https://<WAZUH-VM-IP>
For example:
https://172.30.1.100Accept the self-signed certificate warning.
Use the credentials shipped with the Wazuh 5.0 beta OVA specifically — don’t assume they match the production appliance. The current GA OVA uses wazuh-user / wazuh for the OS account and admin / admin for the dashboard, but the beta build may differ. Change every default password immediately after your first login.
Welcome to Wazuh 5 (Beta).
12. Check the services
Back inside the VM, confirm the core services are healthy:
sudo systemctl status wazuh-manager
sudo systemctl status wazuh-indexer
sudo systemctl status wazuh-dashboardAnd check what’s actually listening:
sudo ss -lntupAt minimum, make sure your network firewall permits:
| Port | Purpose |
|---|---|
443/TCP | Dashboard |
1514/TCP | Agent communication |
1515/TCP | Agent enrollment |
55000/TCP | Wazuh API |
Bonus: Setting a Static IP on the Wazuh 5.0 Beta Appliance
The dashboard walkthrough above uses whatever address DHCP hands the VM, which is fine for a quick look but not something you want to rely on long-term — you don’t want your Wazuh manager’s IP changing under you every time a lease renews. Here’s how to pin it down, and a gotcha worth knowing about before you start.
It’s not what you’d expect
This appliance is built on an Amazon Linux base, which makes it tempting to reach for the usual RHEL-family tools — nmcli, or editing /etc/sysconfig/network-scripts/ifcfg-eth0. Neither is the right layer here. nmcli isn’t installed at all, and while an ifcfg-eth0 file exists, nothing is reading it — the legacy network.service sits inactive (dead) on this image. The interface is actually managed by systemd-networkd, which is enabled and active. Any edits to ifcfg-eth0 are silently ignored, and the VM will boot back onto DHCP every time no matter how carefully that file is configured — which is a frustrating way to lose an afternoon if you don’t know to check.
Confirm what’s actually managing the interface
Before editing anything, check who owns eth0:
bash
networkctl status eth0The output tells you everything you need:
Network File: /etc/systemd/network/20-eth0.network
State: routable (configured)
Address: 172.30.1.100 (DHCP4 via 172.30.1.254)The Network File: line is the important part — that’s the config file actually in effect. If you see a real path there (rather than nothing), you’re on systemd-networkd, and that’s the only file worth editing.
Set the static IP
Edit the file networkctl pointed you at:
bash
sudo cp /etc/systemd/network/20-eth0.network /etc/systemd/network/20-eth0.network.bak
sudo nano /etc/systemd/network/20-eth0.networkIt will currently look something like:
[Match]
Name=eth0
[Network]
DHCP=yesReplace it with your static values — drop DHCP=yes entirely rather than leaving it alongside a static address:
[Match]
Name=eth0
[Network]
Address=172.30.1.179/24
Gateway=172.30.1.254
DNS=172.30.1.20
DNS=8.8.8.8Apply it:
sudo systemctl restart systemd-networkdVerify it actually took
networkctl status eth0
ip aYou’re looking for the (DHCP4 via ...) qualifier next to the address to be gone — its absence is what confirms the interface is genuinely static now, not just coincidentally holding the same-looking address.
Reboot and check once more before calling it done:
sudo rebootnetworkctl status eth0If the static address survives the reboot with no DHCP qualifier, you’re set.
If your image manages networking differently
Not every Wazuh appliance build will necessarily use systemd-networkd — a future OVA revision could ship with NetworkManager (nmcli) or the legacy network-scripts system instead. networkctl status <interface> is the fastest way to find out which one you’re actually dealing with before you start editing config files that nothing is reading.
Wrapping up
That’s a full Wazuh 5.0 beta appliance running as a Proxmox VM, from OVA upload to a working dashboard login. Since this is beta software, keep it isolated from anything production — treat it as a lab build for evaluating what’s new in Wazuh 5 before the GA release lands.
