Note
My learning and exploration of these topics are heavily AI-guided and my writing and thoughts are my own. My goal with this site is to serve as a knowledge base and playbook while displaying my work and progress.
The Storage You See Is Not The Storage You Get
Before getting Wazuh up and running, I ran into some issues with completing the install that I felt were worth documenting. For 1-25 agents, which is the scale I’ll be working at, 4vCPU, 8GiB RAM, and 50GB Storage are what the Wazuh installation docs recommend. Before first boot of the wazuh clone, I only allocated the CPU and RAM needed to run this installation. The Ubuntu template the clone is made from only allocates 20GB, thus this is what the clone starts with.
I actually didn’t even get 20GB because unbeknownst to me the Ubuntu installer only allocates 10GB to the root logical volume, leaving the rest as unallocated volume group storage in case you want to expand later… Annoying, but I’m sure there is a use case where that makes sense. I didn’t have the 50GB Wazuh recommends to begin with, so probably better to cross this bridge now.
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 20G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 1.8G 0 part /boot
└─sda3 8:3 0 18.2G 0 part
└─ubuntu--vg-ubuntu--lv 252:0 0 10G 0 lvm /lsblk shows that the disk has 20GB, the sda3 partition has ~18GB, but then the logical volume ubuntu--vg-ubuntu--lv only gets 10GB. Now I could have just run sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv and called it a day, but in troubleshooting I noticed that I actually needed 50GB to comfortably run Wazuh for 1-25 agents.
The Unhappy Path
Running the installation with inadequate storage results in this error output:
18/09/2026 14:39:27 ERROR: Filebeat installation failed.
18/09/2026 14:39:27 INFO: --- Removing existing Wazuh installation ---
18/09/2026 14:39:27 INFO: Removing Wazuh manager.
18/09/2026 14:39:44 INFO: Wazuh manager removed.
18/09/2026 14:39:44 INFO: Removing Wazuh indexer.
18/09/2026 14:39:46 INFO: Wazuh indexer removed.
18/09/2026 14:39:47 INFO: Installation cleaned. Check the /var/log/wazuh-install.log file to learn more about the issue.In checking the log file /var/log/wazuh-install.log the error shows what went wrong:
18/09/2026 14:39:25 INFO: Starting Filebeat installation.
Reading package lists... Building dependency tree... Reading state information..
. The following packages were automatically installed and are no longer required
: libfwupd2 libgusb2 Use 'sudo apt autoremove' to remove them. The following NEW
packages will be installed: filebeat 0 upgraded, 1 newly installed, 0 to remove
and 10 not upgraded. Need to get 22.1 MB of archives. After this operation, 73.
6 MB of additional disk space will be used. E: You don't have enough free space
in /var/cache/apt/archives/.
18/09/2026 14:39:27 ERROR: Filebeat installation failed.E: You don't have enough free space in /var/cache/apt/archives/. More disk space needs to be allocated, and it wasn’t as simple as allocating more RAM or vCPU.
Allocating Additional Storage
In the Proxmox UI, navigate to the wazuh VM > Hardware > Highlight Hard Disk > Disk Action > Resize > 30GB (Taking the total hard disk to 50GB).
Run lsblk to confirm the changes:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 50G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 1.8G 0 part /boot
└─sda3 8:3 0 18.2G 0 part
└─ubuntu--vg-ubuntu--lv 252:0 0 10G 0 lvm /The disk space, sda, has been expanded to 50GB in the Proxmox UI. Now the partition holding the LVM (Logical Volume Manager) physical volume needs to expand to fill the free space.
Run sudo growpart /dev/sda 3 to grow the partition.
Warning
If growpart reports NOCHANGE, the Proxmox resize hasn’t landed yet. It can only grow the partition into space the virtual disk actually has. Make sure you’ve resized the hard disk in Proxmox beforehand.
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 50G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 1.8G 0 part /boot
└─sda3 8:3 0 48.2G 0 part
└─ubuntu--vg-ubuntu--lv 252:0 0 10G 0 lvm /The sda3 partition expanded, but the physical volume needs to update its capacity so that the logical volume in the next command knows there is more space now. Updating the physical volume updates the LVM (Logical Volume Manager) metadata, which lvextend references before increasing the size of the logical volume.
$ sudo pvresize /dev/sda3
Physical volume "/dev/sda3" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resizedRun lsblk again and it looks like nothing changed. This is because lsblk only knows about the block-device layer: the disk, partition, and logical volumes. It doesn’t know about the LVM’s metadata or the filesystem.
Next we need to expand the logical volume - the ubuntu--vg-ubuntu--lv in the lsblk output.
Running sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv expands the logical volume to fill all of the free space available in the volume group.
$ sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
Size of logical volume ubuntu-vg/ubuntu-lv changed from 10.00 GiB (2560 extents) to 48.22 GiB (12345 extents).
Logical volume ubuntu-vg/ubuntu-lv successfully resized.Now lsblk shows ubuntu--vg-ubuntu--lv with ~48GB, up from the 10GB earlier. The last step is to resize the filesystem with sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv. Then we can run df -h to see those changes reflected.
$ df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 795M 1020K 794M 1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv 48G 6.5G 39G 15% /
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/sda2 1.8G 200M 1.5G 13% /boot
tmpfs 795M 12K 795M 1% /run/user/1000$ curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh && sudo bash ./wazuh-install.sh -a
...
...
...
18/09/2026 18:47:40 INFO: --- Summary ---
18/09/2026 18:47:40 INFO: You can access the web interface https://<wazuh-dashboard-ip>:443
User: admin
Password: [password listed here]
18/09/2026 18:47:40 INFO: Installation finished.Re-ran the installation and it finished cleanly. Good to go. On to enrolling agents.