Sean,

My initial assessment may have been off.  The issue is NOT resolved by turning off clipboard sharing.  I even restarted Multiplicity on both primary and secondary machines.  I also did not see high CPU utilization during the issues of input lag. 

What I did notice, however, is that if Multiplicity loads before VMware, everything seems to work has they have previously.  But, I saw that both VMware guests briefly went to a "not responding" state.  After that, the lag was persistent until I restarted VMware. 

I hope this helps.

Thanks for your time!

So to be clear on the environment...

Two real PCs, one a Multiplicity (MP) Primary, the 2nd an MP Secondary.

The Secondary has VM instances running on it.  No 'lag' when using the actual real Secondary PC, only when interacting with the VM window running on it.

Is that an accurate description of the issue? 

If you do the same, tetonbob:

If you disable clipboard sharing, is there any change?

Sean Drohan
Stardock Product Lifecycle Manager

Ok, so its just when using the VM window instance, no log on the actual Secondary PC.

Are you using KVM connections to connect to the Secondary PC or Seamless?

If the VM freshly run or are apps \ intensive processes running?

Sean Drohan
Stardock Product Lifecycle Manager

This could be the root of all your issues.

Please see, in particular, the PortFix batch file:

https://forums.stardock.com/486104/multiplicity-support-faq#cantcopy

Sean Drohan
Stardock Product Lifecycle Manager

Still no joy.
I shut down both machines.
I started both machines.
I disabled firewall on both machines.
I tried copy/paste of text from primary to secondary. It failed
I tried a copy/paste of text from secondary to primary. It's still fine as before.
I re-enabled firewall on both machines and ran the MPPortfix.bat
I tried copy/paste of text from primary to secondary. It failed
I tried a copy/paste of text from secondary to primary. It's still fine as before.

There's something about this particular machine I have as primary, but I can't figure out what.
I may try using a different machine as primary and see how that behaves.

Is there any process dump or logs I can obtain for developers to review?

Right, no VMs involved in that last test. I'll try the clean boot steps and report back.

The clean boot is not just the service shutdown, it's also done under the new Windows admin account(s) - was that done here?

Sean Drohan
Stardock Product Lifecycle Manager

thank you

Shared clipboard is not enabled.

Hi Sean. It may be too early to claim success but I recently uninstalled and reinstalled Multiplicity and one thing which happened was, when I accessed the UI, it threw a notification that my ethernet connection was public rather than private, and that could cause issues in behavior.

I'm honestly not sure if it's been that way all along, or a recent change caused that. Regardless, I've changed that connection to private, and as of now, the issues of not being able to copy/paste from primary to secondary, and the issue of lag/not responding when accessing a VM on the secondary, from the primary, both seem to be resolved.

My pleasure, thanks for your help. I've been working all day with this now, and it's behaved as expected since I made that change to the ethernet settings. I do consider my case resolved.