Multithreading in VIX API: more crashes, any news on fixes?

[dblock]

I've been trying to extend our test automation to parallelize against multiple virtual machines. I am using VMWareTasks. I make a connection to a different VM on two threads, then use the handle(s) returned, etc. This is a collection of crash messages followed by access violations that I got recently. I'll edit with more as i see them

Most of the issues happen on connect or disconnect.

• ** (RemoteInstaller.exe:5572): WARNING **: ???: object class `GVmomiSession' has no property named `state'

• ** ERROR *: g_type_plugin_() invalidly modified type GVmomiSession' aborting (popup)

Is there any news on a 1.6.3 that might fix these problems? I'd be really happy to try a beta too.

Thx

dB.

[fixitchris]

I would think you would need to create a thread manager that would interact with the underlying active VMWareVirtualHost class, along with a collection of VMWareVirtualMachines. I could see the sharing violations brought on by building on top of the VIX SDK.

Can you share some code?

[dblock]

No no no I have two completely independent threads that each connect to a completely different host, open two completely different virtual machines, do something on them, then disconnect. I guess I could write a simple repro, but it's the same range of problems as . IMHO it's a bug.

[fixitchris]

If you wanna write something up I can test it...

[fixitchris]

I see what you're saying. I think I'm getting the same behavior but it is harder to pin point since my app is a Windows service.

What I am doing is connecting to one host on one thread, where I create some more threads to do things with the guests. At the same time I create a thread for another host, plus some guest threads and do some operations. When the second host thread is finished it disconnects and is killed.... Also the Windows service crashes!

I'm going to try to pin point this issue, but it sounds like the same problem.

[lemke]

This is probably the same issue referred to in http://communities.vmware.com/message/1162597#1162597

This sounds a lot like you're getting hurt by host handle sharing. If

HostConnect() is called again with the same parameters, the host handle

gets reused. HostDisconnect() will clean up that handle, even if its

shared. This is actually documented behaivior. We've also decided it

can can problems like the one you've hit, so it will be removed in an

upcoming release.

So your app will be sharing the host handle amongst all threads, and as

soon as one calls disconnect, the host handle in the others also

becomes invalid.

Doing a single HostConnect() and sharing that handle inside the threads

is one way to avoid this. HostConnect() in general is pretty expensive,

so we'd recommend that in any case.

[fixitchris]

lemke, I think dblock means that he's creating two separate threads, T1 and T2 then he's calling T1.connect(host001) and T2.connect(host002). Then when he calls T2.Disconnect, T1 handle is invalidated as well.

What you are saying is calling T1.connect(host001) and T2.connect(host001)... Am I understanding you correctly?

[lemke]

Sorry, I missed that.

I'll have to try to repro this.

[dblock]

Please find attached a repro. Edit the code and change the two ConnectionInfo-s to some other host(s). I get the crash 99% of the time on disconnect and sometimes on connect.

[fixitchris]

Thank you for 1.7!

Can you vmware guys confirm that the above is resolved in a .NET environment?

dblock, are you upgrading your lib to 1.7?

[fixitchris]

1. Failures when connecting or disconnecting host handles from multiple threads simultaneously. When calling VixHost_Connect or VixHost_Disconnect from multiple threads in a single client, a crash or hang might occur. This was encountered in stress testing with 10 - 20 simultaneous threads.

[dblock]

I have definitely not seen this. I am sure VMWare developers did see it in stress testing and it's real, but couldn't nail it down on time for VMWorld