This knowledge base article provides information on the functionality and changes introduced with Sophos for Virtual Environments version 1.2.0. The following sections are covered:
Applies to the following Sophos products and versions Sophos for Virtual Environments 1.3.1 Sophos for Virtual Environments 1.3.2 Sophos for Virtual Environments 1.3.3 Sophos for Virtual Environments 1.3.4
The release of Sophos for Virtual Environments 1.2.0:
Sophos for Virtual Environments 1.2.0 and later versions enable guest VMs to migrate between multiple Security VMs. This provides improved support for environments using vMotion (VMware ESXi) and Live Migration (Microsoft Hyper-V) technologies as well as those that clone templates for their guest VMs to be distributed across multiple Security VMs.
Each guest VM will evaluate the list of available Security VMs to determine the following:
Based on these criteria the guest VM will then choose a "good" Security VM to connect to. All guest VMs randomly choose a good Security VM and therefore will have a random distribution over the good available Security VM set.
A guest VM can lose connection to the Security VM that is providing it with protection, for a number of possible reasons, not limited to:
In this scenario, the guest VM will connect to another available Security VM and resume protection. There will be a small gap in protection when the guest VM migrates during which access will be allowed to files.
The guest VM will also evaluate the available set of Security VMs periodically to determine is the states of any of the Security VMs has changed. If the state of the Security VM currently providing protection for the guest VM is significantly degraded and there is a better Security VM available, then the guest VM will migrate across to the better Security VM.
Available Security VMs are the set of Security VM IP addresses available for your guest VMs to connect to. This includes all configured IP addresses for all deployed Security VMs as well as any reserved IP addresses that are to be used for Security VMs that have not yet been deployed.
The complete list of available Security VM IP addresses needs to be configured on all Security VMs and can be configure after the Security VM has been deployed (please see the Sophos for Virtual Environments Configuration Guide for details on how to do this). This information is then automatically shared with all connected guest VMs.
Due to significant changes in the architecture of the product for this release existing customers will need to uninstall any existing deployment of Sophos for Virtual Environments and the redeploy Security VMs and the guest agent with GVM migration configured. Redeployment can be done in a phased approach installing the new Security VMs on version 1.2.0 first and then redeploying the guest agents to be associated with these before removing the non-migration enabled Security VMs. Please refer to the Sophos for Virtual Environments Startup guides for details on how to do this. If as an existing customer you choose to continue with your already installed SVE set up then you will be upgraded to SVE 1.2.0 but will not be able to use the GVM migration functionality.
Yes, Sophos recommend that you configure the Hypervisor migration technologies in a certain way to enable the Security VMs to work correctly. For further information please see KBA 127956.
Historically with Sophos Anti-Virus for VMware vShield there was a requirement to have one Security VM per host. Sophos for Virtual Environments does not have the same restrictions; therefore multiple Security VMs can be deployed to a single host if required. However, the overall set of SVE Security VMs need to be configured to provide protection for all networks that guest VMs might be able to connect from.
For example, if you have guest VMs on networks A, B and C any one of the following options could be configured:
Sophos for Virtual Environments 1.2.0 introduces support for environments where SMB message signing is enforced or unauthenticated guest access to SMB shares is not permitted. In previous versions this meant that the customer could not access the public SMB share on the SVM to get the guest VM agent installer; guest agent updates; or get automatic clean up functionality.
Due to changes required to allow the Security VM and Guest VM agents to authenticate using SMB signing there is a requirement to uninstall and reinstall all required Security VMs and Guest VM agents.
On a clean install of a Sophos for Virtual Environments 1.2.0 Security VM, you will be asked to configure a password for the 'sophospublic' user as well as the 'sophos' user. The 'sophospublic' user can then be used to provide read only access to the Security VM public share and as such can be shared for access to the guest VM agent installer. The 'sophos' user remains for support access and should be protected as it provides logon access to the Security VM itself required for support activities.
For existing Security VMs, when they are automatically upgraded to version 1.2.0, there will be no change in functionality, to get support for the authenticated public share access you will need to redeploy all Security VMs and guest agents. Redeployment can be done in a phased approach installing the new Security VMs on version 1.2.0 first and then redeploying the guest agents to be associated with these before removing the previous Security VMs.
Sign up to the Sophos Support SMS Notification Service to get the latest product release information and critical issues.
Every comment submitted here is read (by a human) but we do not reply to specific technical questions. For technical support post a question to the community. Or click here for new feature/product improvements. Alternatively for paid/licensed products open a support ticket.