Back to Blog
Symantec antivirus definition7/6/2023 ![]() It isn't a VMware problems per se, rather it is because users of VMware on Netapp often take snapshots and can measure the amount of binary change happening on spindles. Their support was useless and blamed in on VMware. It is too bad SAV is so stupid in the way they handle their defs. Disabling the PAM took the boot times up to 10-20 minutes. When we enabled our PAM for the first time and rebooted 100 VDI desktops as a test, the reboots were 98-99% cached on the PAM card and took 1-3 minutes to boot. It helps in what netapp calls a "boot storm" for shared spindles on a netapp. It then caches all common reads more aggressively than the internal cache. This is basically a PCIe card with 16GB of RAM (cache) you put into your Netapp. One last step on our FAS6080 was to purchase a PAM module (Performance Acceleration Module). Both of these steps helped greatly since VMDK's located on NFS mounts do not experience LUN queuing / LUN reservations. We have since upgraded our FAS3050 to a FAS6080 and migrated to NFS instead of iSCSI / FC LUNs. We also have 500+ VDI desktops that would have the same issue. We now have 300+ VM servers which would have the same problem if we didn't use LiveUpdate. Since the last post a lot has been changed in our environment. This allowed us to stagger the deployment over a 4-6 hours period at night rather than all VM's getting hit at once. The "solution" (which isn't a solution in my opinion) was to use LiveUpdate to deploy the SAV definitions rather than the SAV server pushing the defs out.
0 Comments
Read More
Leave a Reply. |