CPU and Memory Considerations

CPU Types

The CPU type setting allows you to choose based on CPU generation and features, ensuring consistent functionality even if the private cloud infrastructure uses different CPUs. However, live migration between Intel and AMD CPUs is not guaranteed.

Selecting “host” at the bottom of the dropdown menu will use the same CPU as the physical host, maximizing efficiency. However, this prevents live migration between hosts with different generations, which may cause issues if new HRPC units are added to the virtual data center in the future.

Most modern operating systems work with x86-64-v2, which supports instruction sets such as SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, and CMPXCHG16B. The x86-64-v2-aes option includes AES encryption instructions, enabling faster performance for encryption software.

Choosing x86-64-v3 enables the use of AVX and AVX2 instructions, while x86-64-v4 adds support for AVX-512 instructions.

All HRPC private cloud models from 6Gt onwards support x86-64-v4.

The following table summarizes this information:

Processor	x86-64-v1	x86-64-v2	x86-64-v2-aes	x86-64-v3	x86-64-v4
Supported Instructions	Base x86-64 instruction set	SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CMPXCHG16B	x86-64-v2 + AES	AVX, AVX2, BMI1, BMI2, FMA, MOVBE	AVX-512 family (AVX-512F, AVX-512CD, AVX-512DQ, AVX-512BW, AVX-512VL, etc.)
Intel Xeon	Intel Xeon 3000/5000/7000 series (1st Gen)	Intel Xeon 5500 series (Nehalem) and later	Intel Xeon 5600 series (Westmere) and later	Intel Xeon E3 v3 (Haswell) and later, Intel Xeon E5/E7 v3 (Haswell-EP/EX) and later, Intel Xeon Scalable Processors 1st Gen (Skylake-SP) and later	Intel Xeon Scalable Processors 2nd Gen (Cascade Lake-SP) and later, Intel Xeon Scalable Processors 3rd Gen (Ice Lake-SP)
AMD Opteron	AMD Opteron 100/200/800 series (SledgeHammer)	AMD Opteron 4200/6200 series (Bulldozer) and later	AMD Opteron 4300/6300 series (Piledriver) and later	Not applicable	Not applicable
AMD EPYC	Not applicable	1st Gen AMD EPYC (Naples)	1st Gen AMD EPYC (Naples)	AMD EPYC 7002 series (Rome) and later	AMD EPYC 7003 series (Milan) and later

KVM Memory Management and Ballooning Driver

In short, the Ballooning driver is unnecessary in HRPC infrastructure and is recommended to be disabled.

In KVM, setting the “Minimum Memory” value equal to the “Memory” value appears to create a fixed memory allocation. However, due to the nature of Linux memory management, allocated memory and actual usage differ. The system reserves memory at startup, but it is only actively used when data is written to it, making memory usage effectively dynamic.

This can be observed in the “Memory Usage” section of the host or virtual machine summary. For example, a virtual machine assigned 32GiB of memory may only use 13.56GiB in reality.

In a typical Proxmox VE system, virtual machines can be created as long as there is available memory. However, if the displayed “Memory Usage” appears low, administrators may allocate more memory than physically available, leading to memory overcommitment. When virtual machines suddenly demand more memory, this can cause instability, potentially triggering the Out-Of-Memory Killer in the host OS, which may randomly terminate critical system processes.

HRPC 6Gf is designed for enterprise use with a focus on isolation, ensuring that virtual machines cannot be created beyond available memory capacity.

If the host machine runs out of memory and the Ballooning device is enabled, the Ballooning Driver forces the guest OS to release unnecessary memory (e.g., disk caches, dirty pages), returning it to the host OS. This process increases CPU load and I/O operations, leading to delays and instability, especially in high-availability (HA) systems that are sensitive to latency.

As mentioned earlier, the custom hypervisor in HRPC 6Gf prevents unnecessary virtual machine creation, making the Ballooning device largely irrelevant in this environment.