Multiple Connections to ESX

[jimmyc11]

Hi,

I'm creating a multi-threaded web application the job of which is to manage automation jobs running on ESX server. When 'jobs' are submitted, the system manages the running of each job on a VMWare image on the ESX server. I'm using dblock's 'Vestris.VMWareLib' wrapper for C# to perform these actions.

However, I'm having some issues when I try to connect to ESX. If I attempt a number of connections to ESX (like when 3 jobs are submitted to be run) at the exact same time in my web app, I get the error:

Vestris.VMWareLib.VMWareException: The handle is not a valid VIX object

I then proceded to write a simple C# console app to make 5 concurrent connections to ESX, but had no problem with these. I've attached that example.

Will I have issues if I make a number of connections to ESX at the same time? Is it an idea that I have to 'stagger' making the connections by a couple of seconds?

Please help Thanks !!

[dblock]

VixCOM attempts to do something "smart" about handle sharing. Even if you resolve connectivity you're going to run into . You'll probably have to patiently wait for the next release of VixCOM.

[jimmyc11]

I don't suppose there's an ETA on that?

[dblock · Accepted solution]

I've asked the same question many times on this forum (http://communities.vmware.com/thread/214215) and I am not the only one. I tried other channels in VMWare and I got nothing but radio silence.

Update: this thread, , says that there's going to be a release within a few weeks. Fingers crossed.

[jimmyc11]

Thanks, fingers crossed indeed!

[jimmyc11]

Just one last question. I've created a console app to do my automation work in the Virtual Machines. The app takes care of one job independently

I can run multiple instances of this application, i.e. connect multiple times to the ESX server without any issues. What's the differance between doing this and doing the same thing from one application in a bunch of threads?

Thanks,

jimmyc1

[dblock]

VixCOM has something clever about connection pooling (that doesn't work). I presume that, provided it's fixed, the number of actual connections to the remote server is going to be 1 per server in a single application. That reduces concurrency and probably performs better.