Recently there were some customer related questions about MTVs session usage and session re-usage for specific migration activities, like warm migration using multiple plans.

Nir requested to open this ticket which is intended to collect session counts related to MTV based on specific activities.

When MTV is connected to a vsphere environment a session is created.  This session lives for a certain amount of time before it expires or has to be recreated.  New connections may use new or re-use existing sessions.  The purpose of this task is to collect information that baselines how many sessions AND connections are used.

To monitor connections the scripts in misc-scripts/ConnectionsCounter_VMware.sh can be used.

To monitor sessions you can use the flow described below:

You can find session information in Vsphere Client by clicking on the Monitor Tab and under tasks and events section there is a 'sessions' tab, you'll want to monitor total sessions and specifically ones with User Agent: govmomi

 Additionally you can get the above info from api using powercli also which is recommended to avoid having to review runs manually.

This task is focused on getting an understanding of how vsphere sessions and connections are used per the following suggested activities listed:

• Adding a provider with correct authentication (check each provider type)
• Migrating 10 vms using cold migration
• Migrating 10 vms using warm migration (allowing 1 pre-copy and then cut-off)
• Adding a provider with incorrect authentication

Its important for us to understand how many sessions and connections are used per each scenario above, the highest priority on Warm, and then cold.

Consider:

How long does a session/connection live in general, what do we observe for the lifecycle of session? Is there any un-expected build up of sessions, if so what is it related to which scenario?  Are sessions properly cleared after a migration completes?

Testing for this task can be isolated to the smaller vcenter env in order to isolate any unnecessary noise from this benchmark. If additional hosts (esxs) are needed we can move testing to the large vcenter when necessary.