VM Lab R82 ElasticXL - Lightshot Partition is out of space

[nadmin]

Hello, I'm rebuilding my Check Point Lab on the latest version of the XCP-ng xen hypervisor. It was great on R81.20 and ClusterXL. New challenge is R82 and ElasticXL.

First issue using ElasticXL with the second gateway not showing up as a pending gateway. Solution was to patch the exl_detectiond.py as noted in the previous thread https://community.checkpoint.com/t5/Security-Gateways/R82-elasticXL-lab/td-p/219343 (deals with open servers, looks like a bug)

Second issue is adding the second gateway fails due to failed cloning process.

/var/log/lightshot.log shows "Lightshot Partition is out of space".

Reviewing the script I ran these commands to confirm:

mount /dev/vg_splat/lv_log_lightshot /mnt/lightshot

df -h

[...]

/dev/mapper/vg_splat-lv_log_lightshot  14G  14G 124K  100% /mnt/lightshot

This confirms only 14G was on the partition even though during setup 79GB of the 128GB drive was reserved for Backup and Upgrade. I increased the drive to 300GB so that 209GB was reserved for Backup and Upgrade. Same issue, out of space, 14GB on the lightshot partition.

I understand that some people here have got ElasticXL with multiple VMs working. VMware Workstation, for example in combination with network adapter workarounds.

Q1) has anyone see this issue "Lightshot Partition is out of space" in VMs before?

Q2) if so, any suggestions on how to fix it?

Notes: I am using thick provisioning on the VM storage and there is plenty of space on the storage volume. I also built this VM from scratch, not cloning from a checkpoint-template like I do customarily. (yes i tried my template but it failed too, and i wanted to avoid using fast-clone)

If you would like to play along and see the complete build: https://github.com/doritoes/NUC-Labs/blob/xcp-ng-8.3/XCP-ng/8_Checkpoint.md

I'm willing to retry on VMware, proxymox, VirtualBox (probably not hyperv). Since this looks like a partition issue, I wanted to check here before heading that way.

Thank you!

PS: Please add a Label for ElasticXL

[ShaiF · Accepted solution]

Hi @nadmin,

The lightshot partition size should dynamically adjust based on your image size on the SMO.
Since you’re working with an unsupported hypervisor/VM (as you have a GA take installed), this mechanism might not function as expected.

To resolve this, you can manually increase the partition size from the new member’s CLISH using the following command:

set lightshot-partition size <size in GB>

Regards,
Shai.

[the_rock]

Just tried it in the lab as well, worked great 👍

[the_rock]

Just do exactly what @ShaiF had said. I had to do that once in eve-ng lab.

[nadmin]

Thanks to @the_rock  and @ShaiF I I will test that tonight.

[the_rock]

Glad we can help.

[the_rock]

Just to be on a safe side, BEFORE doing anything, I would generate backup and also config file (here is an example)

from expert -> clish -c "show configuration" > /var/log/filename.txt (file name I usually give it hostname and date, so say if your hostname was fw01 and date is November 10th 2025, you could do fw01-Nov10-2025.txt).

Hope that helps.

[nadmin]

Notes from testing:

Cannot set lightshot partition size on the new gateway to be added in initial state. Only after it has been added to the cluster.

I tried setting the first gateway lightshot partition size:

set lightshot-partition size 20

save config

reboot

When I added the second gateway, it still had 14GB and ran out of space.

At this point I was able to set the snapshot size on the new gateway

set lightshot-partition size 20

reboot

But there is no real way to restart the cloning; reboots didn't help. Removing the second member using WebGUI and rebooting second gateway did not show it as a pending gateway. The new cluster member appeared to be corrupted somehow so I rebuilt it and tried again. `show cluster` on it exploded with components not found.

I will keep testing different iterations.

[the_rock]

Let me try it in the lab tomorrow and see.

[emmap]

In the other thread about EXL in the lab there was a command to reenable EXL detection - make sure you run that on both/all cluster members after the reboot.

[nadmin]

Thank you @emmap I didn't see that. Is that after adding the cluster member is successful?

[nadmin]

Good news, after leaving it overnight, it showed as pending and I was able to successfully add it. I will re-enable exl detection and test some.

I will try to repeat the process again and share any learnings in case anyone else runs into this.

Edit to add: huh I left the first gateway at download & verify overnight, and it failed validation. I will test applying JHF before I burn it down and rebuild.

[the_rock]

Great job!

[nadmin]

I have a repeatable process that I need to simplify.

The secret sauce is going away from an hour while waiting for the status to change from JOINING_CLUSTER back to REQUEST_TO_JOIN.

[the_rock]

I tested in the lab on R82 jumbo 44 and worked well.

[emmap]

The detection needs to be running before the member is added, to ensure that it shows up as an available cluster member. Once it's added there's no need for it. Sounds like though yours just needed more time, so all good there. Sometimes the main tool we need for these things is patience, and to go make a nice cup of tea.