We have 148 VDI being served by 2 MOVE SVMs. The assignment of SVM IP-s to VDIs are done by an SVM Manager.
The rules for the assignment is correct (has been tested). In addition, the SVM Manager policy does not allow allocating other SVMs to clients if rules do not match (it is meant to be this way).
However, when we look at the following statistics in ePO, they have contradictory results:
- Number of clients connected to SVM 1: 123
- Number of clients connected to SVM 2: 2
- MOVE AV client enabled on VDI: 148 enabled
This suggests some VDIs might have different IP addresses so other rules on SVm Manager match probably and they are served with IPs of other SVM-s belonging to other customers (I call them rogue VDIs).
Does someone have a good idea how to check from ePO the SVM IP assigned to these VDI (Primary server or Active Server fields) so we identify these rogue VDIs ?
Preferably not one by one thorugh the GUI.
Thanks for ideas, guys.
Attila
it sounds like you are managing multiple customers under a single ePO, if that is the case then you could run one of the default MOVE queries to see which IPs/ subnets are been scanned by an SVM, for example the default query "MOVE AntiVirus: Clients Connected With a given SVM" will give you a list of SVMs are respective client IPs assign to it, from there you could understand if a machine is been scanned by an unwanted SVM.
On the other hand, with that amount of machines is not necessary to have a Manager as we recommend a maximum of 25o clients per SVM so a single SVM should do fine for 148 machines, you could change the assignment to a manual assignment and ensure all clients go to the right SVM
Regards
Alejandro
Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?
Hi Alejandro,
thanks for your reply.
Yes you were right: we actually have one customers with several "regions" here so an SVM Manager is needed (we have over 2000 VDIs). The 148 VDI belong to only a very small region.
Another twist of the story, that all the VDIs (including this 148) have a dedicated network interface for scanning, yet they have a different interface for connecting to ePO.
Meaning your report would yield no VDIs as the SVM would report IP-s of scan interface for VDIs while McAfee Agent on same VDI would report a different IP within system properties making ePO unable to match them.
I could not find a way of mass listing certain MOVE antivirus Properties, such as "Primary Server", Active Server", etc. other than see them on each Product Property page of any VDI for MOVE.
Have you any idea here? Otherwise I need to approach client support team for obtaining same information...
Thank you.
Alejandro,
If I could list the IP-s of connecting VDIs (HEartbeat) from every SVM locally, that would be just as good.
I could do it locally on the SVM as we do not have many.
Oh i see yes, MA would only report what is preferred on the OS and MA would not be able to bind to a particular interface.
You could potentially create a new query based on System Management> systems and then query something like this:
And then use any system/OS property that can help you understand which IPs are been scanned by the wrong SVM
Regards
Alejandro
Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?
Hi,
Unfortunately that did not yield much other than the Bar chart list of our SVM-s (bar height being proportional to the number of connected clients) and the amount of 1-1 of them.
I have tried changing the bar value expression, but using the MOVE MP SVM Product Properties column always had details of SVM, not the clients.
Attila
if you click on the bars then you will see the systems with the properties 🙂
Hi Alejandro,
clicking on the bars did not reveal the connecting systems. It revealed the SVM properties as a node.
I have asked from client support a .TXT with "mvadm status" outputs for all the VDIs that are supposed to connect to this SVM. It turned out quite a number of VDIs connect to an SVM using the previous type of adapter, because they are not able to connect to SVM Manager to get the new type of IP.
We are currently investigating the root cause. Also we have learned that it might be suboptimal using the "Allocate SVM if no rule matches" setting for potentially assigning cross-tenant SVM to VDIs of a given tenant.
Still, thank you for having been of assistance here.
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA