This is the second post out of 3 about CAVA on the Celerra/VNX File.
1. What is CAVA?
2. CAVA Considerations and basic setup (this post)
3. CAVA troubleshooting (which is really why I am doing this)
Between the first post and this one EMC has released the new VNX range to replace the CLARiiON and Celerra. So the new version of the Celerra is called VNX File and they have dropped the name ‘Celerra’, which is a shame. So from now on I will use VNX File instead of Celerra. This post is a mash of my own notes and quotes from the doco.
CAVA is part of the CEE or VEE framework, which is a mix of API’s, agents and events that enable things like quota managements, antivirus and auditing on the VNX File. Mainly it’s for partners and 3rd party apps to interface with the Celer… umm … VNX. Bah, this is going to be a hard habit to break.
How much do you care about it? Well, if you are just trying to run CAVA then not much, just note that all the CAVA downloads on Powerlink are in the VNX Event Enabler pack. At the time of writing you can still get it via
Home > Support > Software Downloads and Licencing > Downloads C > Celerra Anti Virus Agent (CAVA)
but that might change when the VNX name starts taking over. The download is an ISO and about 120MB. This includes both the 32 and 64bit versions. I have never understood why they weren’t individual downloads. Powerlink is a bit slow at the best of times outside the US, and it’s excruciatingly slow over a 3G card at a customer’s site when you forgot to download it before you got to site and you only have 3 hours to finish the job. But I would never do that … *cough*.
Another tool you need is the Celerra MMC on the NAS Tools CD. You will get this as part of your delivery of software when the hardware turns up. Just install that on some machine that you can run it with heightened permissions (domain admin). If you can’t find the software then you can download it from Powerlink at
Home > Support > Product and Diagnostic Tools > Celerra Tools > NS-960
and get the Celerra Network Server Version 126.96.36.199 Applications and Tools CD (277MB). That’s right, 227MB and from it you want a 2MB file. Handy Hint – don’t misplace the CD’s 😉 This version still works fine with the VNX.
What do you need:
A downloaded copy of the VEE Celerra install
Minimum 2 x Windows Servers to run the AV engine software (McAfee, Symmantic etc).
A Windows Domain service account to run the AV process and access files on the Velerra.
Velerra NAS Tools Microsoft Management Console (MMC)
A CIFS server on the data mover NOT in a VDM.
A configured and installed viruschecker.conf file.
As far as I can tell, even though the names have changed, all these steps are the same for Celerra and VNX.
So onto the install. All of these steps are available in more detail in the "Using VNX Event Enabler" documentation available on Powerlink. This includes detailed instructions on installing and configuring antivirus engines like McAfee and Sofos. Because of this I won’t go into to much detail, just highlight the steps.
Download and install, CAVA, your AV software and the NAS Tools MMC files.
Provision your CAVA Windows servers, either physical or VM’s. Install your AV software and then the CAVA agent on each machine. The CAVA install is very basic, next next next finish.
For our example I’ll call the AV servers AV1 and AV2 with IP’s of 10.1.1.1 & 10.1.1.2
Create the CAVA CIFS server
This is the easy bit, you just need a CIFS server on the data mover with an IP address. That’s it. It doesn’t need storage but it must be on the physical data mover and not in a VDM.
For our example I’ll call my CIFS server BOB and it’s on server_2 with an IP of 10.1.1.10
Create the Domain User Account and grant access
The CAVA installation requires a Windows user account that is recognised by Celerra Data Movers as having the EMC virus-checking privilege. This user account enables the Data Mover to distinguish CAVA requests from all other client requests. To accomplish this, you should create a new domain user, assign to this user the EMC virus-checking right locally on the Data Mover, and run the CAVA service in this user context.
For our example I will call the user CAVAservice
Using compmgmt.msc and browsing to the CAVA CIFS server (BOB), create a new local group called Viruscheckers and add the CAVAservice user to it. While you are there add the user to the local administrators group on the CAVA AV servers and the CAVA CIFS servers.
Using the NAS MMC, browse to the BOB server and add the Viruscheckers group to the “EMC Virus Checking” section. If you don’t have this CAVA no worky.
Finally, you need to change the CAVA service on the AV servers to "run as" the CAVAservice user. You can do this via services.
The viruschecker.conf file defines the Celerra virus-checking parameters for each Data Mover in the domain.
This is an example viruschecking.conf configuration file. It lists the AV servers as well as the rules of what to scan. This is a common example of the file and can be customised.
maxthreadWaiting=40 (20 on each AV server)
CIFSserver=<CAVA CIFS server name> eg. BOB
Addr=<IP addresses of AV engines separated by semi colons> eg 10.1.1.1:10.1.1.2
[box type="info"]You can see that’s a large list. Always consult with the antivirus vendor to determine exactly which file types cannot and/or should not be scanned in real-time network scanning and what the workarounds are.[/box]
Upload the viruschecker.conf to the data mover
There are three ways of getting the viruschecker.conf file to the data mover.
Use server_file server_2 -put viruschecker.conf viruschecker.conf. Think of that command like an FTP, you have to have the file on the control station and it’s called viruschecker.conf.
You can create the viruschecker.conf file on your Windows machine and then copy it to \\BOB\c$\.etc\viruschecker.conf
Use the NAS MMC to generate the file and it will save it to the right location.
Start the CAVA service on the data mover.
There are two ways of this
Use the NAS MMC to start the service
Run server_setup server_2 -P viruschk –o start=32. The 32 is the number of CIFS threads you want to use, 32 is the default.
Check to make sure the sucker is running!
Seems obvious but is often overlooked, especially because the normal behaviour is that if something is wrong, the viruschecking service is stopped and then the Velerra goes about its normal business. "What problem, I don’t see no stinking problem".
I’ll go into it more in the troubleshooting post but like everything else Velerra, always run server_log server_2 before you do anything else. If there is anything wrong it wil pop up there. If don’t see anything suspicious then use the server_viruschk commands to see if it’s scanning
server_viruschk server_2 -audit
That’s about it for the installation and setup. There is a lot more detail in "Using VNX Event Enabler" including command definitions and screenshots.
VNX File CAVA Considerations
Below are some considerations when setting up and deploying CAVA.
Virus Checker Configuration File Considerations
(Filename viruschecker.conf, resides on the Data Mover)
The mask= parameter can greatly impact virus checking performance. It is recommended that you do not use mask=*.* since this setting scans all files. Many file types cannot harbor viruses, therefore, mask=*.* is not an efficient setting. Most AV engines do not scan all file types. Also scans of file types with an unknown extension will result in the entire file being scanned, increasing network bandwidth and resources.
It is recommended that .pst and other similar “container files” be left out of the scanning queues for the Celerra AV functionality to work properly. McAfee and Symantec do not scan Outlook .pst files and recommend excluding them from scans. Either scan at desktop level or use Exchange server specific products or Exchange client snap-ins. This is good advice for other AV products as well.
It is recommended that you do not set up real-time scanning of databases. Accessing a database usually triggers a high number of scans, which in turn can cause a large amount of lag. To ensure that your database files are virus free, you should schedule regular scans for times when the database is not in use. You can schedule scans through your AV engine. See knowledgebase article emc60746 for specific extensions that should be excluded.
Most AV vendors recommend excluding real-time network scanning of compressed and/or archive files. Scanning compressed or archive files requires a lot of system resources. In order to scan a compressed or archive files, the AV software must extract the file to a temporary location, scan it, and then replace the file. This functionality requires RAM, drive space, and CPU, thereby degrading the overall performance of the server.
[box type="info"]In a complete network AV solution any infected files will be found as they are added to, moved from, or launched from compressed or archive files.[/box]
Depending on the 3rd party AV package, contents of compressed and/or recursively zipped files may or may not be supported for scanning in real-time for network shares. If the vendor does not support scanning compressed files or recursively zipped files in real-time or if scanning of compressed files is not enabled, they should be excluded from scans.
Due to known issues with antivirus software compatibility with Microsoft Excel and MS Project software add the following 8 characters “????????” to the exclude list as a workaround.
This is to avoid a timing or deadlock issue with the 8 character temporary file that it created when files are saved or modified. (For more information refer to knowledgebase article emc60253)
For maximum protection antivirus software vendors suggest scanning all executable files and files that contain executable code. For maximum performance and to reduce network bandwidth and resources, exclude file types that do not contain executable code. Always consult your antivirus vendor for latest information.
Recommend that the “shutdown=” setting in the viruschecker.conf file is configured to shutdown=virus checking. This is the action to take when the VC client on the Data Mover does its routine polling to determine which AV servers are in “ONLINE” status and what action to take if it cannot find any “ONLINE” AV servers. An alert should be configured when this action is triggered for notification and to get the AV servers functioning again. To protect the server during the timeframe the virus checking service was offline, run a manual scan or use the scan on first read feature.
This is recommended over allowing virus checking to continue when no AV servers are available. If all the AV servers are offline for an extended period of time, the file types that meet the criteria for a virus check will wait in the collector queue until an AV server comes back “ONLINE”. The files in the queue are locked to the user until the file is successfully scanned. Each scan request ties up a thread on the Data Mover which can eventually exhaust all the Data Mover threads over a period of time.
[box type="info"]Status “ONLINE” indicates successful communications between the VC client on the Data Mover, CAVA, and the 3rd party antivirus software running on the AV server(s). To verify AV server(s) status at any given time run the server_viruschk server_x command.[/box]
AV Server Workstations
Make sure all file types that are configured to meet the criteria for a virus check on the Data Mover can be checked on the AV servers. 3rd party antivirus “File Types” scan and exclude settings should match the viruschecker.conf file settings. The VC client on the Data Mover should not be configured to trigger scan requests of file types that the AV servers’ antivirus software is not configured to scan.
For every AV vendor EXCEPT Trend Micro, you need to install the AV engine first before the CAVA agent. For Trend you have to install CAVA first, then the AV software. This has got us a few times.
AV servers should be strictly dedicated for CAVA use only. They should NOT also be used for other windows services such as a Domain Controller, DNS, WINS, backup server, CIFS client, etc. Each AV server should only be running one 3rd party antivirus software product at a time.
The dedicated “AV user” domain account that the CAVA service starts under should always be configured so that the password doesn’t expire. Make sure both the CAVA and 3rd party software services on the CAVA server are starting using the AV user domain account, and not a local Admin or AV user account.
If the AV servers are “managed” by a group policy management software package from the AV vendor, the AV servers should be managed in a separate policy to safeguard the required user, permissions, and scanning options required for Celerra virus checking with CAVA from regular workstation settings.
The AV server(s) should not be used for copy and/or scanning proof of concept testing. These tests should only be executed on the client side.
If an AV server is going to be temporarily or permanently removed, then its IP address should be removed from the viruschecker.conf file before the CAVA service is shutdown.
CIFS should be completely configured, tested, and working before setting up virus checker. Before using Celerra virus checking for production use, test the configuration to verify it is suitable for the environment by simulating a production load on the Data Mover(s).
Always ensure that the number CIFS threads used are greater than virus checker threads.
Do not modify the param “maxVCThreads=” unless directed by Engineering/TS2.
VirusChecker can only be configured on a physical Data Mover using a regular CIFS Server and NOT on a CIFS VDM Server, since only the physical data mover root can host the CHECK$ share used for viruschecking operations.
Monitor the server_log(s) and/or system log (/nas/log/sys_log) for “VC: highwater mark reached” (peak activity) entries. These messages may indicate the need for additional AV server(s).
Avoid using real-time network scanning of Celerra shares in addition to the Celerra virus checker feature. Client AV scanning should be disabled for Celerra CIFS shares, this could result in sharing violations and impact performance.
[box type="info"]It is recommended to enforce desktop scanning for all clients. It is important to understand that the CAVA solution is primarily meant to protect the data on the Celerra File Server.[/box]
Virus checker must be disabled during migrations. Files should be scanned prior to the migration or after it’s completed. The virus checker solution assumes you are starting with a clean filesystem.
Care must be taken when sizing a virtual machine for a CAVA server. All sizing tools assume a physical machine.
Protecting data against viruses is a critical service and you do not want to be in a position where other services running in different VMware machines starves it for resources. If this were to happen then DART queue for scanning requests can build up thus affecting file access. Hence the recommendation will be to run CAVA in a non VMware environment until substantial work is done to understand guidelines for CAVA running in a VMware environment.
I hope that helps someone out there. I’ll try and create the troubleshooting post as soon as I can.