Product Documentation
NetScaler VPX
14.1-Current Release 13.1 13.0 12.1
View PDF

Support matrix and usage guidelines

October 29, 2024
Contributed by: 
C

This document lists the different hypervisors and features supported on a NetScaler VPX instance. The document also describes their usage guidelines and known limitations.

VPX instance on XenServer or Citrix Hypervisor

Citrix Hypervisor version SysID Performance range
8.2 supported 13.0 64.x onwards, 8.0, 7.6, 7.1 450000 10 Mbps to 40 Gbps

VPX instance on VMware ESXi hypervisor

ESXi version ESXi release date (YYYY/MM/DD) ESXi build number NetScaler VPX version Performance range
ESXi 8.0 update 3b 2024/09/17 24280767 13.1-53.x and higher builds 10 Mbps to 100 Gbps

















ESXi 8.0 update 3 2024/06/25 24022510 13.1-53.x and higher builds
ESXi 8.0 update 2c 2024/05/21 23825572 13.1-53.x and higher builds
ESXi 8.0 update 2b 2024/02/29 23305546 13.1-49.15, and 13.1-52.x and higher builds
ESXi 8.0 update 2 2023/09/21 22380479 13.1-52.x and higher builds
ESXi 8.0 update 1 2023/04/18 21495797 13.1-45.x and higher builds
ESXi 8.0c 2023/03/30 21493926 13.1-45.x and higher builds
ESXi 8.0 2022/10/11 20513097 13.1-42.x and higher builds
ESXi 7.0 update 3q 2024/05/21 23794027 13.1-53.x and higher builds
ESXi 7.0 update 3p 2024/03/05 23307199 13.1-52.x and higher builds
ESXi 7.0 update 3o 2023/09/28 22348816 13.1-51.x and higher builds
ESXi 7.0 update 3n 2023/07/06 21930508 13.1-49.x and higher builds
ESXi 7.0 update 3m 2023/05/03 21686933 13.1-48.x and higher builds
ESXi 7.0 update 3i 2022/12/08 20842708 13.1-37.x and higher builds
ESXi 7.0 update 3f 2022/07/12 20036589 13.1-33.x and higher builds
ESXi 7.0 update 3d 2022/03/29 19482537 13.1-27.x and higher builds
ESXi 7.0 update 3c 2022/01/27 19193900 13.1-21.x and higher builds
ESX 7.0 update 2d 2021/09/14 18538813 13.1-9.x and higher builds
ESX 7.0 update 2a 2021/04/29 17867351 13.1-4.x and higher builds

Note:

Each ESXi patch support is validated on the NetScaler VPX version specified in the preceding table and is applicable for all the higher builds of NetScaler VPX 13.1 version.

VPX instance on Microsoft Hyper-V

Hyper-V version SysID Performance range
2016, 2019 450020 10 Mbps to 3 Gbps

VPX instance on Nutanix AHV

NetScaler VPX is supported on Nutanix AHV through the Citrix Ready partnership. Citrix Ready is a technology partner program that helps software and hardware vendors develop and integrate their products with NetScaler technology for digital workspace, networking, and analytics.

For more information on a step-by-step method to deploy a NetScaler VPX instance on Nutanix AHV, see Deploying a NetScaler VPX on Nutanix AHV.

Third-party support:

If you experience any issues with a particular third-party (Nutanix AHV) integration on a NetScaler environment, open a support incident directly with the third-party partner (Nutanix).

If the partner determines that the issue appears to be with NetScaler, the partner can approach NetScaler support for further assistance. A dedicated technical resource from partners works with the NetScaler support until the issue is resolved.

VPX instance on generic KVM

Generic KVM version SysID Performance range
RHEL 7.6, RHEL 8.0, RHEL 9.3 450070
10 Mbps to 100 Gbps
Ubuntu 16.04, Ubuntu 18.04, Ubuntu 22.04

Points to note:

Consider the following points while using KVM hypervisors.

  • The VPX instance is qualified for hypervisor release versions mentioned in table 1–4, and not for patch releases within a version. However, the VPX instance is expected to work seamlessly with patch releases of a supported version. If it does not, log a support case for troubleshooting and debugging.

  • Before using RHEL 7.6, complete the following steps on the KVM host:

    1. Edit /etc/default/grub and append "kvm_intel.preemption_timer=0" to GRUB_CMDLINE_LINUX variable.

    2. Regenerate grub.cfg with the command "# grub2-mkconfig -o /boot/grub2/grub.cfg".

    3. Restart the host machine.

  • Before using Ubuntu 18.04, complete the following steps on the KVM host:

    1. Edit /etc/default/grub and append "kvm_intel.preemption_timer=0" to GRUB_CMDLINE_LINUX variable.
    2. Regenerate grub.cfg with the command "# grub-mkconfig -o /boot/grub/grub.cfg “.
    3. Restart the host machine.

VPX instance on AWS

AWS version SysID Performance range
N/A 450040 10 Mbps to 30 Gbps

Note:

The VPX 25G offering doesn’t give the 25G throughput in AWS but can give higher SSL transactions rate compared to VPX 15G offering.

VPX instance on Azure

Azure version SysID Performance range
N/A 450020 10 Mbps to 10 Gbps

VPX instance on GCP

GCP version SysID Performance range
N/A 450070 10 Mbps to 10 Gbps

VPX features matrix

VPX feature matrix table

The superscript numbers (1, 2, 3) used in the preceding table refers to the following points with respective numbering:

  1. Clustering support is available on SRIOV for client-facing and server-facing interfaces, and not for the backplane.

  2. Interface DOWN events are not recorded in NetScaler VPX instances.

  3. For Static LA, traffic might still be sent on the interface whose physical status is DOWN.

  4. For LACP, the peer device knows the interface DOWN event based on the LACP timeout mechanism.

    • Short timeout: 3 seconds
    • Long timeout: 90 seconds

  5. For LACP, do not share interfaces across VMs.

  6. For Dynamic routing, convergence time depends on the Routing Protocol since link events are not detected.

  7. Monitored static Route functionality fails if you do not bind monitors to static routes because the Route state depends on the VLAN status. The VLAN status depends on the link status.

  8. Partial failure detection does not happen in high availability if there’s link failure. High availability-split brain condition might happen if there’s link failure.

    • When any link event (disable/enable, reset) is generated from a VPX instance, the physical status of the link does not change. For static LA, any traffic initiated by the peer gets dropped on the instance.

    • For the VLAN tagging feature to work, do the following:

    On the VMware ESX, set the port group’s VLAN ID to 1–4095 on the vSwitch of the VMware ESX server.

Supported browsers

Operating system Browser and versions
Windows 7 Internet Explorer- 8, 9, 10, and 11; Mozilla Firefox 3.6.25 and above; Google Chrome- 15 and above
Windows 64 bit Internet Explorer - 8, 9; Google Chrome - 15 and above
MAC Mozilla Firefox - 12 and above; Safari - 5.1.3; Google Chrome - 15 and above

AMD processor support for VPX instances

From NetScaler release 13.1, the VPX instance supports both the Intel and AMD processors. VPX virtual appliances can be deployed on any instance type that has two or more virtualized cores and more than 2 GB memory. For more information on system requirements, see NetScaler VPX data sheet.

VPX platforms vs. NIC matrix table

The following table lists the NICs supported on a VPX platform or cloud.

Mellanox CX-3 Mellanox CX-4 Mellanox CX-5 Intel 82599 SRIOV VF Intel X710/X722/XL710 SRIOV VF Intel X710/XL710 PCI-Passthrough Mode
  VPX (ESXi) No Yes No Yes No Yes
  VPX (Citrix Hypervisor) NA NA NA Yes Yes No
  VPX (KVM) No Yes Yes Yes Yes Yes
  VPX (Hyper-V) NA NA NA No No No
  VPX (AWS) NA NA NA Yes NA NA
  VPX (Azure) Yes Yes Yes NA NA NA
  VPX (GCP) NA NA NA NA NA NA

Usage guidelines

Follow these usage guidelines:

  • We recommend you to deploy a VPX instance on local disks of the server or SAN-based storage volumes.

See the VMware ESXi CPU Considerations section in the Performance Best Practices for VMware vSphere 6.5 document. Here’s an extract:

  • It isn’t recommended that virtual machines with high CPU/Memory demand sit on a Host or Cluster that is overcommitted.

  • In most environments, ESXi allows significant levels of CPU overcommitment without impacting virtual machine performance. On a host, you can run more vCPUs than the total number of physical processor cores in that host.

  • If an ESXi host becomes CPU saturated, that is, the virtual machines and other loads on the host demand all the CPU resources the host has, latency-sensitive workloads might not perform well. In this case you might want to reduce the CPU load, for example by powering off some virtual machines or migrating them to a different host (or allowing DRS to migrate them automatically).

  • Citrix recommends the latest hardware compatibility version to avail the latest feature sets of the ESXi hypervisor for the virtual machine. For more information about the hardware and ESXi version compatibility, see VMware documentation.

  • The NetScaler VPX is a latency-sensitive, high-performance virtual appliance. To deliver its expected performance, the appliance requires vCPU reservation, memory reservation, vCPU pinning on the host. Also, hyper threading must be disabled on the host. If the host does not meet these requirements, issues such as high-availability failover, CPU spike within the VPX instance, sluggishness in accessing the VPX CLI, pit boss daemon crash, packet drops, and low throughput occur.

A hypervisor is considered over-provisioned if one of the following two conditions is met:

  • The total number of virtual cores (vCPU) provisioned on the host is greater than the total number of physical cores (pCPUs).

  • The total number of provisioned VMs consume more vCPUs than the total number of pCPUs.

    If an instance is over-provisioned, the hypervisor might not guarantee the resources reserved (such as CPU, memory, and others) for the instance due to hypervisor scheduling over-heads, bugs, or limitations with the hypervisor. This behavior can cause lack of CPU resource for NetScaler and might lead to the issues mentioned in the first point under Usage guidelines. As administrators, you’re recommended to reduce the tenancy on the host so that the total number of vCPUs provisioned on the host is lesser or equal to the total number of pCPUs.

    Example

    For ESX hypervisor, if the %RDY% parameter of a VPX vCPU is greater than 0 in the esxtop command output, the ESX host is said to be having scheduling overheads, which can cause latency related issues for the VPX instance.

    In such a situation, reduce the tenancy on the host so that %RDY% returns to 0 always. Alternatively, contact the hypervisor vendor to triage the reason for not honoring the resource reservation done.

  • Hot adding is supported only for PV and SRIOV interfaces with NetScaler on AWS. VPX instances with ENA interfaces do not support hot-plug, and the behavior of the instances can be unpredictable if hot-plugging is attempted.
  • Hot removing either through the AWS Web console or AWS CLI interface is not supported with the PV, SRIOV, and ENA interfaces for NetScaler. The behavior of the instances can be unpredictable if hot-removal is attempted.

Commands to control the packet engine CPU usage

You can use two commands (set ns vpxparam and show ns vpxparam) to control the packet engine (non-management) CPU usage behavior of VPX instances in hypervisor and cloud environments:

  • set ns vpxparam [-cpuyield (YES | NO | DEFAULT)] [-masterclockcpu1 (YES | NO)]

    Allow each VM to use CPU resources that have been allocated to another VM but are not being used.

    Set ns vpxparam parameters:

    -cpuyield: Release or do not release of allocated but unused CPU resources.

    • YES: Allow allocated but unused CPU resources to be used by another VM.

    • NO: Reserve all CPU resources for the VM to which they have been allocated. This option shows higher percentage in hypervisor and cloud environments for VPX CPU usage.

    • DEFAULT: No.

    Note:

    On all the NetScaler VPX platforms, the vCPU usage on the host system is 100 percent. Type the set ns vpxparam –cpuyield YES command to override this usage.

    If you want to set the cluster nodes to “yield”, you must perform the following extra configurations on CCO:

    • If a cluster is formed, all the nodes come up with “yield=DEFAULT”.
    • If a cluster is formed using the nodes that are already set to “yield=YES”, then the nodes are added to cluster using the “DEFAULT” yield.

    Note:

    If you want to set the cluster nodes to “yield=YES”, you can configure only after forming the cluster but not before the cluster is formed.

    -masterclockcpu1: You can move the main clock source from CPU0 (management CPU) to CPU1. This parameter has the following options:

    • YES: Allow the VM to move the main clock source from CPU0 to CPU1.

    • NO: VM uses CPU0 for the main clock source. By default, CPU0 is the main clock source.

  • show ns vpxparam

    Display the current vpxparam settings.

Other References

Support matrix and usage guidelines
October 29, 2024
Contributed by: 
C
October 29, 2024
Contributed by: 
C

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.