That is certainly a lot of discoveries. We should probably dive into your logs and see what is triggering that, because even many vMotions should not cause that. For example you should only see the SV100 events if an actual HOST is added, removed, or changed in some way - just movements of VMs such as vMotion will not cause that.
In any case, I also see that the specific setting for buffering VM discoveries seems to have been missed from the documentation - I'll get that fixed. Meantime, you will find the setting in our nworks UI, in Advanced Settings for the Collector (select Collector in Enterprise Manager tab)
The setting is VMDiscoveryIntervalBuffer and the default is 4, which means VM changes will be cached for 4 intervals (4 x 5 = 20 minutes) before triggering the topo update. You can increase this setting to whatever you feel is appropriate; just be aware that of course VM topology changes (such as vMotion to a new Host) will take longer to be updated in the SCOM topology view.
Note that this setting will not affect the actual monitoring of VMs for performance and events in any way - all that data continues to be delivered on the standard 5-minute schedule.
Please feel free to open a support case and we can dive into why you are triggering so many discoveries - meantime the above should help to reduce the VM-triggered events anyway.
Any questions let me know!