Having recently completed a hardware specification analysis for a QRadar 7.5.0 proof-of-concept deployment, I can provide concrete data from IBM's documentation and my own empirical testing. The official "Minimum Requirements" are often insufficient for a functional lab, as they fail to account for realistic data ingestion and retention. For a PoC that demonstrates core functionality (log collection, basic correlation, dashboard use), you must plan beyond the absolute bare minimum.
The primary constraints are RAM, CPU core allocation, and disk I/O. Storage capacity is often secondary to storage performance in a PoC context. A common failure point is underestimating the resources needed for the **Event Collector** and **Event Processor** components, even in a consolidated all-in-one deployment.
Based on the QRadar 7.5.0 Installation Guide and validation tests, here is the *functional* bare minimum for a consolidated All-in-One appliance (hosting Console, Event Processor, and Event Collector):
* **CPU:** 8 physical cores (16 vCPUs). The underlying CentOS and Java heap sizes for services are highly concurrent. Fewer than 8 will result in chronic pipeline stalls during even modest ingestion.
* **RAM:** 32 GB minimum, 64 GB strongly recommended. The key factor is the `java_heap` settings for services like `ecs-ec-ingress`, `aio-middleware`, and `econsole`. With 32 GB, you will be operating at the absolute edge, leaving no room for buffer.
* **Storage:** Performance is critical. You require:
* **Type:** SAS or NVMe SSD. SATA SSDs may be acceptable for very light loads, but avoid spinning HDDs entirely for the `/store` filesystem.
* **Configuration:** A dedicated, high-IOPs filesystem for `/store` (where events/logs are written). Do not share this with the OS.
* **Capacity:** 500 GB for `/store` is a pragmatic PoC minimum. This allows for a 7-14 day retention period with a simulated data feed of 500-1000 EPS (Events Per Second).
* **Network:** A dedicated 1 GbE NIC is the minimum. The lab host should not share this NIC with other VM traffic if possible.
A critical configuration note: The default appliance type in the QRadar setup wizard is "Managed Host." For an All-in-One PoC, you must explicitly select **"Console"** as the appliance type. Misconfiguration here leads to an non-functional deployment.
The following is an example `fstab` entry for the dedicated `/store` filesystem, which should be formatted with `ext4` and mounted with `noatime` for performance:
```
/dev/mapper/vg_store-lv_store /store ext4 defaults,noatime,nodiratime,data=writeback 0 0
```
For a virtualized environment (VMware or KVM), you must reserve the CPU and RAM resources; do not rely on over-provisioning. Enable hypervisor-assisted CPU virtualization extensions. The most common performance pitfall in lab deployments is disk latency on the `/store` filesystem, which directly impacts the `ecs-ec-ingress` service's ability to commit events. Monitor the **Disk Write Backlog** metric in the Health Dashboard; sustained backlog indicates an I/O bottleneck.
If your PoC goal includes testing features like Network Insights or custom rules with large reference sets, immediately escalate the RAM specification to 64 GB. The same applies if you intend to deploy any additional Content Extension Packs beyond the base set.
Your point on storage performance is critical. Even with sufficient capacity, a lab on consumer-grade SATA SSDs will see high I/O wait during retention processing, skewing PoC results. The JVM's GC behavior under load is the real constraint, not just core count.