Deploy QRadar Console (SIEM) on OCI using IBM Cloud Marketplace Image

In my previous blog post I explained how to deploy QRadar Console on OCI using an ISO file, along with the limitations of that approach—especially the 2 TiB boot volume limitation caused by legacy BIOS and IDE-based images.

While looking for a solution to the storage problem, I revisited the IBM QRadar 7.5 Installation Guide . In Section 19, IBM describes QRadar marketplace deployments on major cloud providers, including AWS, Azure, Google Cloud, and Oracle Cloud Infrastructure.

After going through that section, it became clear that IBM Marketplace images are the intended and supported approach for cloud deployments—and importantly, they solve the storage design problem.

This blog post walks through how I deployed QRadar on OCI using the IBM Marketplace image, and why this approach works significantly better.

Unlike ISO-based installations:

• The Marketplace image is cloud-optimized
• QRadar is installed as software, not a pre-built appliance
• Storage layout supports large secondary disks
• The installation flow is exactly as documented by IBM
• No legacy BIOS / IDE limitations

Most importantly, /store is placed on a secondary block volume, not the boot disk. This completely avoids the 2 TiB boot volume limitation discussed in my previous post.

So here are the high-level steps:

1. Download QRadar image from IBM Cloud Marketplace
2. Upload the image to OCI Object Storage
3. Create a custom image in OCI
4. Provision the OCI instance with proper networking and storage
5. SSH into the instance and install the QRadar Console

1 We downloaded the QRadar Console image from the IBM Cloud Marketplace , as referenced in the IBM QRadar 7.5 Installation Guide. The downloaded file name is ORACLE-CLOUD-741-console-20220811114721 which is similar to what is mentioned in the guide. This image is specifically prepared for Oracle Cloud and follows IBM’s supported deployment model.

2 Next, I uploaded the image to an OCI Object Storage bucket. You can use OCI web interface or create Pre-authenticated requests wih object writes following steps here .

3 Then using the OCI Console:

• Navigate to Compute → Custom Images
• Create a new custom image
• Select Object Storage as the source
• Choose the uploaded QRadar image file
• Select OCI as the image type

As you see we don't worry about launch mode (Paravirtualized, Emulated etc.), OCI validates the image and prepares it for instance creation.

4 While creating the VM instance from the custom image, there are a few important considerations.

Networking

• Although the guide says "Assign a public IPv4 address" during provisioning, I did not. I reserved a public IP for practical reasons, and assigned it after provisioning. This kind of workaround works fine.
• HTTPS access on port 443 was enabled using a Network Security Group (NSG)
• Another benefit of this approach is ability provide SSH access to the VM through ssh key authentication, not password.

Storage

• Also guide doesn't mention anything about the boot volume and if left untouched VM is provisioned with 122GB boot volume. I find this very small for a QRadar deployment. So I allocated 2 TiB and added some post-provisioning steps to make this space available.
• I created a secondary disk by attaching block volume, installation guide recommends using Paravirtualized attachment type, no need set device path, and obviuosly Read/write access type. I was able to use 12 TB without any problem.

Important Storage size cannot be increased after installation. Make sure you allocate enough space for log retention from day one.
Important I tested provisioning the instance with the default boot volume size (122 GB) and resizing it after deployment. I was able to successfully extend the boot volume up to 2 TiB without breaking the boot process or affecting QRadar functionality.

5 After the instance was running I connected using my SSH keys provided during provisioning. Note that user is cloud-user not opc.
ssh -i ~/.ssh/server.key cloud-user@$public_ip Fixing Storage on Boot Volume
So when checked the boot volume disk capacity is 2T but partition table doesn't know this, and needs to be updated. Here are the steps:

• Expand the Partition: Use fdisk to extend sda3 to fill the 2 TB disk.
• Resize the PV: Run pvresize so LVM recognizes the partition is now larger.
• Extend the Logical Volumes: Decide which folders need more space (e.g., /var or /opt) and grow those specific LVMs.

Expand the Partition
Enter the fdisk interactive menu: fdisk /dev/sda Follow these keystrokes carefully:

1. p: Print the table (one last check of that Start sector).
2. d: Delete a partition.
3. 3: Select partition 3. (Don't worry, the data is still on the bits of the disk).
4. n: New partition.
5. p: Primary.
6. 3: Partition number 3.
7. First sector: TYPE THE START SECTOR YOU WROTE DOWN. (It usually defaults to the right spot, but double-check).
8. Last sector: Press Enter to accept the default (the end of the 2 TB disk).
9. Signature?: If it asks "Do you want to remove the signature?", type N (No). This is critical.
10. t: Change type.
11. 3: Select partition 3.
12. 8e: (or 31 for LVM on some versions). Type L to list codes if unsure, but usually, it's Linux LVM.
13. w: Write changes and exit.

Since sda3 is currently mounted (it holds your OS!), the kernel might use the old table until a reboot. Force an update: partprobe /dev/sda (If partprobe gives an error that the disk is busy, you may need to reboot, but usually it works on modern RHEL).

Or simply just reboot!

Resize the PV
Now that the partition is 2 TB, tell LVM to use that new space: [root@qradar-20260102-1919 ~]# pvresize /dev/sda3
Physical volume "/dev/sda3" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized
vgs (volume group scan) should display a large amount of "VFree" (Virtual Free space). [root@qradar-20260102-1919 ~]# vgs
VG #PV #LV #SN Attr VSize VFree
rhel 1 9 0 wz--n- 1.95t 1.83t

Extend the Logical Volumes
QRadar is extremely "log-heavy." If /var/log or /storetmp fills up, the services will crash or stop collecting events. So based on my current LVM layout and best of judgment this is what I've come up with:

Mount	Old	New	Why?
/ (root)	20 GB	100 GB	Gives the OS breathing room for updates and temporary files.
/opt	14 GB	200 GB	QRadar binaries and many extensions/apps live here.
/var/log	18 GB	500 GB	Critical. This is where QRadar stores active logs.
/storetmp	15 GB	500 GB	Used for temporary data processing and backups.
/var	8 GB	50 GB	General system variable data.
Free Space	0 GB	~500 GB	Keep this unallocated. LVM allows you to grow any folder instantly later if it gets full.

And here are the commands to distribute space:


QRadar Software Installation
Then I started installation as documented in installation guide: sudo /root/setup_console At some point you might see a hardware warning message, proceed with Y.

Script will format attached secondary block volume (sdb), organize the storage with volume groups and folders. Also install required packages, install software ("All-In-One" Console and many supporting others) and configure everything. When the script completes, it will ask you to set the admin password. You can set/change the admin password anytime using: sudo /opt/qradar/support/changePasswd.sh -a

Final Thoughts
If you are planning to run QRadar on OCI for production, this is the recommended and supported approach. The ISO-based method can still be useful for labs, short-term testing or if you can live with 2 TiB storage, but for long-term SIEM workloads, IBM Marketplace images are the right choice. Just plan your storage requirements ahead including log retention and software updates as well and allocate enough storage to both boot volume and additional block volume.