- About Kaspersky Security for Virtualization 6.1 Light Agent
- What's new
- Solution architecture
- Preparing to install the solution
- Files required for installing the solution
- Downloading SVM images using the wizard
- Configuring the ports to use
- Accounts for installing and using the solution
- Configuring the use of secure cryptographic algorithms, ciphers, and protocols
- Configuring rules for moving virtual machines to administration groups
- Installing the Kaspersky Security solution
- Installing the Integration Server and Integration Server Console
- Deploying SVMs using the Integration Server Console
- Selecting an action
- Selecting infrastructure for SVM deployment
- Selecting the SVM image
- Selecting the number of SVMs for deployment (infrastructures based on OpenStack)
- Specifying SVM settings
- Specifying SVM settings (infrastructures based on OpenStack)
- Configuring SVM network settings (infrastructures based on OpenStack)
- Configuring IP address settings for SVM
- Specifying Kaspersky Security Center connection settings
- Creating the configuration password and the root account password
- Starting SVM deployment
- Starting SVM deployment (infrastructures based on OpenStack)
- SVM deployment
- Finishing SVM deployment
- Installing Kaspersky Security web plug-ins
- Installing Kaspersky Security MMC plug-ins
- Automatically creating tasks and a default policy for the Protection Server
- Preparing the Protection Server for operation
- About installing Kaspersky Security Center Network Agent on virtual machines
- About installing Light Agent for Linux
- About installing Light Agent on a virtual machine template
- Preparing Light Agents for operation
- Displaying virtual machines and SVMs in Kaspersky Security Center
- Viewing the list of SVMs connected to the Integration Server
- Updating Kaspersky Security from the previous version
- Removing the Kaspersky Security solution
- Application management framework
- About managing the solution using Kaspersky Security Center
- About Kaspersky Security management plug-ins
- Starting and closing Kaspersky Security Center Web Console
- Managing the solution using Kaspersky Security Center policies
- Managing the solution using tasks
- About access rights to the settings of policies and tasks in Kaspersky Security Center
- About Integration Server Console
- Connecting to the Integration Server via Integration Server Console
- Viewing Integration Server settings in the Integration Server Console
- Licensing Kaspersky Security for Virtualization 6.1 Light Agent
- About the End-User License Agreement
- About data provision
- About the license
- About the License Certificate
- About license key
- About the activation code
- About the key file
- About subscription
- License-specific solution functionality
- About activating Kaspersky Security for Virtualization 6.1 Light Agent
- Procedure for activating the solution
- Renewing a license
- Renewing subscription
- Viewing information about the license keys used in Kaspersky Security Center
- Starting and stopping Kaspersky Security
- Virtual machine protection status
- Connecting SVMs and Light Agents to the Integration Server
- Connecting Light Agents to SVMs
- Protecting large infrastructures
- Updating Kaspersky Security databases and application modules
- Using Kaspersky Security Network
- Additional Protection Server settings
- Reports and notifications
- SVM reconfiguration using the Integration Server Console
- Selecting an action
- Selecting SVM for reconfiguration
- Entering the configuration password
- Editing SVM network settings
- Editing SVM network settings (infrastructures based on OpenStack)
- Changing SVM IP settings
- Changing Kaspersky Security Center connection settings
- Changing the configuration password and root account settings
- Starting SVM reconfiguration
- Starting SVM reconfiguration (infrastructures based on OpenStack)
- SVM reconfiguration
- Finishing SVM reconfiguration
- Configuring Integration Server settings
- Replacing the Integration Server and SVM certificates
- SNMP monitoring of SVM status
- Checking the integrity of solution components
- Using Kaspersky Security for Virtualization 6.1 Light Agent in multitenancy mode
- Deploying a tenant protection infrastructure
- Configuring the Integration Server connection settings to the Kaspersky Security Center Administration Server
- Creating a tenant and virtual Administration Server
- Configuring SVM path and Protection Server settings
- Configuring settings for SVM discovery by Light Agents and general tenant protection settings
- Installing a Light Agent on tenant virtual machines
- Registering tenant virtual machines
- Activating a tenant
- Registering existing tenants and their virtual machines
- Enabling and disabling tenant protection
- Getting information about tenants
- Getting tenant protection reports
- Removing virtual machines from the protected infrastructure
- Removing tenants
- Using the Integration Server REST API in multi-tenancy scenarios
- Deploying a tenant protection infrastructure
- Contacting Technical Support
- How to get technical support
- Technical Support via Kaspersky CompanyAccount
- Getting information for Technical Support
- Protection Server and Light Agent dump files
- Trace files of the Kaspersky Security Components Installation Wizard
- Trace files of the Integration Server and Integration Server Console
- Trace files of the tool for managing Integration Server and SVM certificates
- Trace files of SVMs, Light Agent, and Kaspersky Security management plug-ins
- SVM Management Wizard log
- Using the utilities and scripts from the Kaspersky Security distribution kit
- About remotely diagnosing a device using Kaspersky Security Center
- Appendices
- Using the klconfig script API to define SVM configuration settings
- Executing configuration commands
- Using the SVM first startup script
- Configuring an SVM
- Description of commands
- accept_eula_and_privacypolicy
- apiversion
- checkconfig
- check_viis_infra_accessibility
- connectorlang
- dhcp
- dhcprenew
- dns
- dnslookup
- dnssearch
- dnsshow
- getdnshostname
- gethypervisordetails
- hostname
- listpatches
- manageservices
- nagent
- network
- ntp
- passwd
- permitrootlogin
- productinstall
- reboot
- resetnetwork
- rollbackpatch
- setsshkey
- settracelevel
- test
- timezone
- version
- Settings in the ScanServer.conf file
- Object ID values for SNMP
- How to remove duplicate virtual machines from the list of managed devices in Kaspersky Security Center
- How to restore the Integration Server database and settings from a backup copy
- Using the klconfig script API to define SVM configuration settings
- Sources of information about the solution
- Glossary
- Activation code
- Active key
- Administration Server
- Application activation
- Backup
- Backup copy of a file
- Compound file
- Database of malicious web addresses
- Database of phishing web addresses
- Desktop key
- End User License Agreement
- Heuristic Analysis
- Integration Server
- Kaspersky CompanyAccount
- Kaspersky Security databases
- Kaspersky Security Network (KSN)
- Key file
- Key with a limitation on the number of processor cores
- Key with a limitation on the number of processors
- Keylogger
- License
- License certificate
- License key (key)
- Light Agent
- OLE object
- OpenStack domain
- OpenStack project
- Phishing
- Protected virtual machine
- Reserve key
- Server key
- Signature Analysis
- Startup objects
- SVM
- SVM Management Wizard
- Update source
- Information about third-party code
- Trademark notices
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 the virtual infrastructure running on OpenStack platform, VK Cloud platform, or TIONIX Cloud Platform, you can specify how to determine SVM locality relative to the Light Agent using the
StandardAlgorithmSvmLocality
parameter in theHypervisorSpecificSettings:Openstack
section of the Integration Server configuration file (%ProgramFiles(x86)%\Kaspersky Lab\Kaspersky VIISLA\appsettings.json).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 specify how to determine SVM locality relative to a Light Agent in the Light Agent policy. You can also specify whether Light Agents must consider an SVM's location in the virtual infrastructure when selecting an SVM for connection.
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.
You can select SVM path type, which will be taken into account when determining SVM locality relative to Light Agent. Light Agent can connect only to local SVMs.
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.
You can also specify that Light Agents must not take into the account SVM path in the virtual infrastructure when selecting an SVM for connection. In this case, Light Agents can connect to any available SVMs.
If a Light Agent uses the advanced SVM selection algorithm and 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.
When selecting an SVM, Light Agents take into account the number of connected Light Agents to ensure that Light Agents are evenly distributed between SVMs that are available for connection.
You can specify which SVM selection algorithm the Light Agents will use, and configure the settings for using the extended SVM selection algorithm.