Kaspersky Security for Virtualization 6.2 Light Agent

Connecting Light Agent to SVM

For the Kaspersky Security solution to function, constant interaction between the Light Agent and the Protection Server is required. If there is no connection to the Protection Server, the Light Agent cannot transfer file fragments to the Protection Server for scanning, and scanning is not performed. If Light Agent loses a connection to the Protection Server for more than 5 minutes while running scan tasks, the scan tasks stop and return an error.

To interact with the Protection Server, the Light Agent establishes and maintains a connection to the SVM on which this Protection Server is installed.

Light Agent can only connect to an SVM whose version is compatible with the Light Agent version.

To connect to an SVM, Light Agent must receive information about the SVMs to which a connection can be made. Light Agent selects an available SVM that is optimal for connection according to the SVM selection algorithm.

Regardless of the algorithm used in selecting SVMs, Light Agents also take into account the following parameters:

  • Availability of a valid license (a license key that is not in the denylist is added to the SVM, and the license associated with the key has not expired). Light Agent first connects to the SVM on which the solution is activated (the key is added).
  • Type of the license key added to the SVM. If you use a licensing scheme based on the number of virtual machines protected by the solution (server keys and desktop keys), the Light Agent first connects to the SVM on which the key type matches the operating system installed on the virtual machine with the Light Agent.
  • Protecting the connection between the Light Agent and the Protection Server. A Light Agent for which connection protection is enabled can only connect to SVMs for which encryption of the data channel between the Light Agent and the Protection Server is enabled. A Light Agent for which connection protection is disabled can only connect to SVMs for which channel encryption is disabled or an unsecure connection between the Light Agent and the Protection Server is allowed.
  • SVM connection tags. If a tag is assigned to a Light Agent, the Light Agent can only connect to SVMs that are configured to use that connection tag.

The ability to connect the Light Agent to the SVM also depends on the settings for downloading updates to the SVM, which are specified in the policy for the Protection Server. Only Light Agents for which database updates are downloaded to this SVM can connect to the SVM.

Keep in mind that the scope of functionality available on the Light Agent depends on the license under which the solution is activated on the SVM:

  • If you want to use the Light Agent functionality included in the Enterprise license, you need to connect the Light Agent to a SVM on which the solution is activated under the Enterprise license. When connecting to an SVM on which the solution is activated under a Standard license, less functionality is available on the Light Agent.
  • If you want to use additional Light Agent functionality (for example, integration the Kaspersky Detection and Response solution or integration with Kaspersky Unified Monitoring and Analysis Platform), you need to connect the Light Agent to an SVM on which the solution is activated under a license that includes this additional functionality, or to an SVM for which a separate license key for activating the additional functionality has been added. When a Light Agent is disconnected from the current SVM and connects to an SVM on which additional functionality has not been activated, the functionality becomes unavailable on the Light Agent.

To prevent Light Agents from switching between SVMs with different license types, you can use connection tags or a list of SVMs available for connection to limit the number of SVMs available to a Light Agent.

You can get information about the status of the Light Agent's connection to the SVM in the following ways:

The lack of a connection between Light Agent and an SVM is communicated in Kaspersky Security Center through the status of the host device: if the connection to an SVM is not established, the status of the protected virtual machine changes to Critical. Information about the loss and restoration of the connection of the Light Agent and SVM is saved as events in Kaspersky Security Center.

We do not recommend using live snapshots of virtual machines taken on a running guest OS for SVMs and virtual machines with Light Agent for Linux installed. Restoring from such snapshots results in loss of the connection between Light Agents and the SVMs and degrades the performance of the virtual infrastructure. You can use virtual machine snapshots taken on a running guest OS only if the "Notify only" mode is enabled in the Light Agent settings. For details, see the Kaspersky Endpoint Security for Linux Help of the relevant version.

In this section:

About SVM discovery

About the SVM selection algorithms

Page top
[Topic 254867]

About SVM discovery

Light Agent can discover SVMs running on the network in one of the following ways:

  • Using the Integration Server. SVMs relay information about themselves to the Integration Server. The Integration Server compiles a list of SVMs available for connection, and sends this list to Light Agents.

    In a large-sized virtual infrastructure running the OpenStack platform, VK Cloud platform, or TIONIX Cloud Platform, you can limit the size of the list of SVMs available for connection that the Integration Server relays to Light Agents. The Integration Server can transfer information only about the limited number of available SVMs, which you specified in the Integration Server configuration file.

    To use this method of SVM discovery, you must connect SVMs and Light Agents to the Integration Server.

  • With the use of the list of SVM addresses. You can specify a list of SVM addresses to which Light Agents can connect.

If the extended SVM selection algorithm is used for the Light Agent, and large infrastructure protection mode is enabled on the SVMs, it is recommended to select the Integration Server as the method for Light Agents to discover SVMs.

Each Light Agent can only use one of two possible SVM detection methods.

You can configure SVM detection settings for Light Agents in the following ways:

Page top
[Topic 254868]

About the SVM selection algorithms

Light Agents can apply one of the following SVM selection algorithms for connection:

  • A standard SVM selection algorithm

    If this algorithm is applied, after installing and running on a virtual machine, the Light Agent selects an SVM to connect to that is local to Light Agent.

    SVM locality relative to Light Agent is determined depending on the type of virtual infrastructure:

    • In a virtual infrastructure based on Microsoft Hyper-V, XenServer, VMware vSphere, KVM, Proxmox VE, Basis, Skala-R, HUAWEI FusionSphere, Nutanix Acropolis, Alt Virtualization Server, Astra Linux, or Numa vServer, the SVM that is considered to be local to a Light Agent is the SVM that is deployed on the same hypervisor as the virtual machine with the Light Agent installed.
    • In a virtual infrastructure running on the OpenStack platform, VK Cloud platform, or TIONIX Cloud Platform, you can specify how SVM locality relative to the Light Agent is determined using the StandardAlgorithmSvmLocality parameter in the HypervisorSpecificSettings:Openstack section in the Integration Server configuration file appsettings.json. Depending on the version of the Integration Server, the file is located at one of the following paths:
      • /var/opt/kaspersky/viis/common/ for the Linux-based Integration Server
      • %ProgramFiles(x86)%\Kaspersky Lab\Kaspersky VIISLA\ for the Windows-based Integration Server.

      The StandardAlgorithmSvmLocality parameter can take the following values:

      • ServerGroup – if this value is selected, SVM is considered local for Light Agent if it is located within the same server group as the virtual machine where Light Agent is installed. This value is used by default.
      • Project – if this value is selected, SVM is considered as local for Light Agent if it is deployed within the same OpenStack project as the virtual machine with the installed Light Agent.
      • AvailabilityZone – if this value is selected, SVM is considered as local for Light Agent if it is located within the same availability zone as the virtual machine with the installed Light Agent.

    If there are no local SVMs for connection, Light Agent selects a SVM with the lowest number of Light Agent connections regardless of SVM path in the virtual infrastructure.

    The application does not determine whether the SVM is local relative to the Light Agent if large infrastructure protection mode is enabled for the Protection Server on the SVM. In this case, it is recommended to use the extended SVM selection algorithm and select the Integration Server as the SVM discovery method.

  • An extended SVM selection algorithm

    If this algorithm is applied, you can define the following SVM selection settings:

    • whether to consider or ignore the SVM location in the infrastructure when choosing SVMs for connection
    • if the SVM location is considered, how to determine the locality of SVMs relative to the Light Agent.

    If Light Agents ignore the location of SVMs in the infrastructure, Light Agents will be able to connect to any SVMs available for connection.

    If Light Agents must consider the location of SVMs in the infrastructure, you need to select the SVM path type that will be considered when determining the SVM locality relative to the Light Agent. SVM locality relative to Light Agent is determined differently depending on the virtual infrastructure.

    In a virtual infrastructure based on Microsoft Hyper-V, XenServer, VMware vSphere, KVM, Proxmox VE, Basis, Skala-R, HUAWEI FusionSphere, Nutanix Acropolis, Alt Virtualization Server, Astra Linux, or Numa vServer, an SVM can be considered local for the Light Agent in any one of the following cases:

    • The SVM is deployed on the same hypervisor as the virtual machine with the installed Light Agent.
    • The SVM is deployed on the same hypervisor cluster as the virtual machine with the installed Light Agent.
    • SVM is deployed in the same data center as the virtual machine with the installed Light Agent.

    In a virtual infrastructure running on the OpenStack platform, VK Cloud platform, or TIONIX Cloud Platform, an SVM can be considered as local for Light Agent in one of the following cases:

    • The SVM is located in the same server group as the virtual machine with the installed Light Agent.
    • The SVM is deployed within the same OpenStack project as the virtual machine with the installed Light Agent.
    • The SVM is located in the same availability zone as the virtual machine with the installed Light Agent.

    If Light Agents consider the location of SVMs in the infrastructure when choosing which SVM to connect to, Light Agents can only connect to SVMs that are local.

    For example, if you specify hypervisor cluster as SVM path type, all SVMs deployed on this hypervisor cluster will be considered as local for Light Agent, and Light Agent can connect only to one of this SVMs. If there are no SVMs available for connection in the same cluster in which the Light Agent is running, the Light Agent does not connect to an SVM.

    When selecting SVMs, Light Agents also consider the number of connected Light Agents to ensure that Light Agents are evenly distributed among SVMs available for connection.

    If a Light Agent uses the extended SVM selection algorithm, a list of SVM addresses is selected as the SVM discovery method, and large infrastructure protection mode is enabled on an SVM, then connecting a Light Agent to this SVM is only possible if the SVM path is ignored.

You can specify which SVM selection algorithm the Light Agents will use, and configure the settings for using the extended SVM selection algorithm.

Page top
[Topic 254869]