> Source: [sk104848](https://support.checkpoint.com/results/sk/sk104848)

# sk104848 - Best Practices - Performance Optimization of the Security Management Server installed on a VMware ESX Virtual Machine

| Property | Value |
|----------|-------|
| Solution ID | sk104848 |
| Date Created | 2015-03-22 |
| Last Modified | 2026-01-19 |
| Technical Level | General |
| Products | Security Management Server, Multi-Domain Security Management Server |
| Versions | R82, R81.20, R81.10 (EOS), R81 (EOS), R81 (EOS), R81.10 (EOS), R81.20, R82 |
| OS | Linux, Gaia |
| Platform | VMWare ESX, Open Server |

## Solution

The following configurations are highly recommended to optimize the performance of the Check Point Security Management Server when installed on a VMware Virtual Machine:

### Virtual Machine Guest Operating System

To achieve optimal virtual hardware presentation when manually building a Virtual Machine running Check Point software, define the Guest operating system (Guest OS Version) as follows:

Check Point operating systems:

|-----------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Kernel Version and details                          | Check Point Release                                                                                                                                                                                                                              |
| ### 5.14 RedHat Enterprise Linux version 9 (64-bit) | R82.10 Management Server                                                                                                                                                                                                                         |
| ### 4.18 RedHat Enterprise Linux version 8 (64-bit) | R82 Management Server                                                                                                                                                                                                                            |
| ### 3.10 RedHat Enterprise Linux version 7 (64-bit) | R81.20 Management Server R81.10 Management Server R81 Management Server R80.40 Management Server R80.30 Management Server R80.20 T101 Management Server R80.20.M2 Management Server R80.20.M1 Management Server R80.10 Smart-1 525 / 5050 / 5150 |
| ### 2.6 RedHat Enterprise Linux version 5 (64-bit)  | R80.30 Security Gateway (Gateway and Standalone) R80.20 T101 Security Gateway (Gateway and Standalone) R80.10 (not Smart-1 525, 5050, and 5150) All pre-R80.10 releases                                                                          |

<br />

**Notes**:

* Upgrading to a later Check Point OS version that uses a higher level version of the kernel, does not require a change to the Guest OS Version.
* Using a higher level Guest OS Version than indicated by the respective RedHat Enterprise Linux version based on installed kernel versions is not recommended due to changes in how the Guest OS handles the hardware baseline, which can lead to strange results and require a complete rebuild.

To determine the kernel version of the installed Check Point OS, use the "`uname -r`" command.

Utilization of other VMware Guest OS Versions may not provide optimal results, because Check Point OS is very close to the implementation of RedHat Enterprise Linux.   
Future Check Point OS kernel versions may provide support for higher levels of Guest OS Versions.

### Disk Controller (SCSI Controller) Recommendations

* For R80 to R81 versions, only the **LSI Logic SAS** or **LSI Logic Parallel** adapters are recommended. VMware-specific controllers, such as **VMware Paravirtual SCSI (PVSCSI) Controller** are not supported or recognized by the Gaia operating system for in these versions.
* For R82 versions, the **VMware Paravirtual SCSI (PVSCSI) Controller** is supported by the Gaia operating system.

### Disk

Always use *Thick provisioning* (thick/lazy is acceptable), never *Thin-provision* disk resources.

Thick provisioning allocates the entire virtual disk prior to use and is fully zeroed out, whereas Thin provisioning virtual disks are neither pre-allocated or pre-zeroed. When a write is issued by a guest to a thin provisioned disk to an unallocated segment, it must wait for disk to grow and be zeroed.   
The Security Management performs a large number of writes, such as logs and policy installations, which are critical components of the infrastructure. If you use Thin provisioning, then I/O performance becomes a bottleneck.

**Make sure the disk partitions within the guest are aligned**.

Unaligned or misaligned partitioning results in the I/O crossing a track boundary, resulting in additional I/O. This incurs a penalty on both latency and throughput. The additional I/O can impact system resources significantly on some host types and some applications - especially disk-intensive applications, such as SmartEvent or heavily loaded logging modules. An aligned partition ensures that the single I/O is serviced by a single device, eliminating the additional I/O and resulting in overall performance improvement.

For more information and remediation, refer to the documentation of the SAN provider.

### Memory

See the [Release Notes](https://support.checkpoint.com/product/184#f-commonsource=C.%20Documentation&q=%22Release%20Notes%22) document for the Gaia version. Allocate at least 10 GB of memory to the Virtual Machine. For Virtual Machines running Multi-Domain Security Management Server, plan to allocate 10 GB for the base installation plus 2 GB for each additional Domain. Consider reserving 50% of the memory allocated and consider increasing the Virtual Machine's resource shares allocation.

### vCPUs

In multi-CPU (SMP) guests, the guest operating system can migrate processes from one vCPU to another. This migration can incur a small CPU overhead. If the migration is very frequent, it might be helpful to pin guest threads or processes to specific vCPUs. Allocate only the number of vCPUs that are necessary.

For heavily-subscribed environments, consider reserving at least 30% of the CPU frequency and consider increasing the CM's resource shares allocation.

### Virtual Network Adapter

**Note** : The E1000 driver is supported only on versions R82 and lower. Refer to [sk180572 - Hardware Compatibility Notifications](https://support.checkpoint.com/results/sk/sk180572).

The default virtual network adapter emulated in a Virtual Machine is either an AMD PCnet32 device (vlance / "Flexible"), or an Intel E1000 device (E1000).

Using "Flexible" NIC driver Gaia OS is not recommended, as it has been shown to carry a significant performance penalty.

VMware also offers the VMXNET family of paravirtualized network adapters. The VMXNET family contains VMXNET, Enhanced VMXNET (available since ESX/ESXi 3.5), and VMXNET Generation 3 (VMXNET3; available since ESX/ESXi 4.0).

Check Point recommends to use VMXNET Generation 3 (VMXNET3) on all supported Gaia releases.  
On a Gaia release that does not support VMXNET3, we recommend E1000.  

VMXNET3 is included in Security Gateway VE OVF R77 and higher.  
ISO version of Security Gateway VE support VMXNET3 on R77.30 and higher using Gaia OS.   

For more information on the configuration and usage of VMXNET3 network adapters, refer to [sk110686 - How to configure VMXNET3 Network Adapters](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk110686).

In some cases, low receive throughput in a Virtual Machine can be caused by insufficient receive buffers in the receiver network device. If the receive ring in the guest operating system's network driver overflows, packets are dropped in the VMkernel, degrading network throughput. A possible workaround is to increase the number of receive buffers, although this might increase the host physical CPU workload. For VMXNET3 and E1000, the default number of receive and transmit buffers are controlled by the guest driver, with the maximum possible for both being 4096.

### I/O Scheduling

Not supported for Gaia OS.

### Disk Queue Depth

Changing the disks ***queue_depth*** increases the amount of Disk I/O throughput.

* To check the current setting, run in the Expert mode: **cat /sys/block/<DISK_DEVICE>/device/queue_depth**

  Example:

  **[Expert@Hostname:0]# cat /sys/block/sda/device/queue_depth
  32
  [Expert@Hostname:0]#**
* For each disk presented to the Virtual Machine, change the queue depth with this command in the Expert mode:

  **echo "New_Value" > /sys/block/<DISK_DEVICE>/device/queue_depth**

  Example:

  **[Expert@Hostname:0]# echo "64" > /sys/block/sda/device/queue_depth**

### I/O request queue

The I/O request queue is the size of the request - in and out. When using the deadline scheduler, it is recommended to set this value to twice the size of the ***queue_depth*** . This configuration optimizes performance with the size settings for ***nr_requests***.

* To check the current setting with this command in the Expert mode, run:  
  **cat /sys/block/<DISK_DEVICE>/queue/nr_requests**  
  Example:   
  **[Expert@Hostname:0]# cat /sys/block/sda/queue/nr_requests****`64`
  `[Expert@Hostname:0]#`**
* For each disk presented to the Virtual Machine, change the queue depth with this command in the Expert mode:  
  **echo "New_Value" > /sys/block/<DISK_DEVICE>/queue/nr_requests**Example:  
  **[Expert@Hostname:0]# echo "128" > /sys/block/sda/queue/nr_requests**

### Related documentation and solutions:

* [sk169252 - Performance Tuning for Virtual Security Gateway](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk169252)

<!-- -->

* VMware Knowledge Base: [Linux 2.6 kernel-based virtual machines experience slow disk I/O performance (2011861)](http://kb.vmware.com/kb/2011861)
* VMware Guide: [Performance Best Practices for VMware vSphere� 4.0 (VMware� ESX 4.0 and ESXi 4.0, vCenter Server 4.0)](http://www.vmware.com/pdf/Perf_Best_Practices_vSphere4.0.pdf)
* VMware Guide: [Performance Best Practices for VMware vSphere? 5.0 (VMware ESXi? 5.0, vCenter? Server 5.0)](http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdf)
* IBM Redpaper: [Linux Performance and Tuning Guidelines](https://lenovopress.com/redp4285)

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content
