runScriptInGuest causes seg fault when calling through vCenter

[ChrisSears]

Greetings,

I'm using the VIX C bindings to call runScriptInGuest. When I make the call when connected to vCenter, I get a seg fault, but when I connect directly to the ESX system, it works fine. Is there something different that I should be aware of when calling through vCenter?

It may not be relevant, but I know the PowerShell wrapper for this function, Invoke-VMScript, seems to require the ESX system host/login info be passed in as parameters. This struck me as odd since the PowerShell session already had an authenticated vCenter connection, but now I'm wondering if certain VIX commands can't be run through vCenter and must be run directly against the ESX host.

Is there anything I should check on the vCenter system to troubleshoot its ability to proxy a VIX call?

Thanks,

- Chris

[lemke]

There should be no differences for RunScriptInGuest -- vCenter isn't even involved in the communication of that specific request; Vix sends it directly to the ESX system.

Do other guest operations work properly?

[ChrisSears]

Other guest functions seem to have the same problem. I tried ListProcessesInGuest for example and it crashed when connected to vCenter.

There must be some difference in the code path when I connect to vCenter instead of an ESX host. If vCenter doesn't proxy the call, there must some initial phase where VIX asks vCenter which ESX host hosts a given VM, gets some sort of authentication token, and then VIX makes a separate connection to the ESX host.

If I'm way off, could you explain the sequence?

Thanks.

[lemke]

You're correct, but that happens early on when we first open/power on the VM. Are you doing a WaitForTools? It should trip over any issue as well.

What version of Vix are you using? There have been bugs with vCenter, where a complex VC (one with multiple datastores) could cause a Vix memory smash. But that was in the VM open code, and fixed since at least 1.8.1 I suppose (like any mem smash) it might wait about and blow up on a later call.

Another bug is that the Vix client sometimes can't resolve the hostname that vCenter returns, and fails to connect. I've not seen it cause a crash though; Vix just gets confused and thinks a poweredOn VM is off when it opens it, instead of returning an error about being unable to connect.

[ChrisSears]

I haven't tried waitForTools, but I expect it would have the same problem.

I'm using Vix version 1.8.1.

My current thought is that I may have some other (non-vix) memory management bug that just happens to get triggered by the different vCenter code path. Until you explained how the vCenter interaction works, I was under the impression that vCenter proxied the call. I'll try to isolate the cause better and let you know how it turns out. Thanks for your help.