Having trouble connecting to a VM on a remote ESX host

Jan 29, 2010 at 7:18 PM

I am having trouble connecting to a VM on a remote ESX host using the code listed below.  I don’t receive an error message but the program crashes on the “virtualMachine.PowerOn()” line.  If I put a breakpoint on the previous line where a VM is opened, it doesn’t receive an error but if I hover over the virtualMachine object I see the entire list of properties are showing errors of “Function evaluation disabled because a previous function evaluation timed out. You must continue execution to reenable function evaluation.”

To test to make sure it was connecting to a host, I changed the name and/or password in the connection string and it gave an error.  I also did this same thing for connecting to the VM.  It does appear that it is connecting to the proper host and VM but it doesn’t get beyond that.  Any ideas?


// declare a virtual host

using (VMWareVirtualHost virtualHost = new VMWareVirtualHost())

{

    // connect to a remove (VMWare ESX) virtual machine

    virtualHost.ConnectToVMWareVIServer("esx.mycompany.com", "vmuser", "password");

    // open an existing virtual machine

    using (VMWareVirtualMachine virtualMachine = virtualHost.Open("[storage] testvm/testvm.vmx"))

    {

        // power on this virtual machine

        virtualMachine.PowerOn();

        ....
     }
     .....
}


Jan 29, 2010 at 7:46 PM
Edited Jan 29, 2010 at 7:57 PM

I discovered that the error message is a bug with the VS2005 Debugger, but the original questions still stands.  Why does the program keep crashing after it connects to a VM?

Also, one more thing to add.  We have 3 hosts in a HA cluster and I am just using the current host that the VM resides on.  Not sure if that makes a difference but I thought I would throw it in there.

 

Coordinator
Jan 29, 2010 at 8:15 PM

Can you please post the contents of the crash, call stack, etc. Then, make sure that you have VixCOM 1.8.x and not an older version, there're many knows bugs there that cause crashes with "gvomi" all over the call stack.

Jan 29, 2010 at 10:16 PM

I may have used the wrong term when I said it "crashes".  There are no errors but it just stops running right after that line.  It doesn't do anything and doesn't provide an error.  I downloaded VixCOM 1.8 but I did not make a reference to it within my application.  The only reference I have added was based on the instructions, "In your project add a reference to Vestris.VMWareLib.dll and a namespace reference."  I added a call stack dump portion to my app using the StackTrace object from System.Diagnostics, so it would gather information right before it dies but I'm not sure how helpful this will be for you.  Let me know if there is anything else I can provide you with.  Thanks.

PrintStack at offset 94 in file:line:column \\File-Share\docs\mydocs\Visual Studio 2005\Projects\DTVIClone\DTVIClone\Program.cs:13:13
Main at offset 166 in file:line:column \\File-Share\docs\mydocs\Visual Studio 2005\Projects\DTVIClone\DTVIClone\Program.cs:31:21
_nExecuteAssembly at offset 0 in file:line:column <filename unknown>:0:0
ExecuteAssembly at offset 58 in file:line:column <filename unknown>:0:0
RunUsersAssembly at offset 43 in file:line:column <filename unknown>:0:0
ThreadStart_Context at offset 102 in file:line:column <filename unknown>:0:0
Run at offset 111 in file:line:column <filename unknown>:0:0
ThreadStart at offset 68 in file:line:column <filename unknown>:0:0

Coordinator
Jan 30, 2010 at 4:39 PM

So, it hangs on PowerOn? In your VI client (the thing that lets you manage snapshots and virtual machines), you should see some events. The first one is a lookup of the virtual machine, caused by the Open command. The second one is a power-on. Does the virtual machine actually power on?

What is the version of your VMWare ESX server?

Next, write a simple 5-line command-line program that has the same behavior and post it here.

Jan 30, 2010 at 10:28 PM
Edited Jan 31, 2010 at 12:08 AM

I think even "hangs" may not be the proper terminology because I don't have to end the application or anything, it just stops running with no errors.  The only reason I know it stops running after that line (VirtualMachine.PowerOn()) is if I put a break point after the line, the debugger won't even fire up because the program just stops running.  However, If I put a break point on that line, the debugger will stop at the break point, it just stops running as soon as I step over or out of the break point.  Also, I don't see any events running for that VM in the VIC and it does not power on.  I would assume this means it's not even running the PowerOn() command or it errors out before it even tries.  As far as writing a 5 line console app, are you referring to the 1st code snippet I wrote in my 1st post?  Thanks again.

Edit:  Do you think this is related to port 443 or a secure connection issue?

Coordinator
Jan 31, 2010 at 12:22 AM

I don't know. There's nothing here except "it doesn't work". There's nothing magical about an ESX host - and if you have a VI client working with it, i don't see why this code wouldn't. Maybe try the VixCOM forum.

Feb 1, 2010 at 9:14 PM

I was finally able to find something in the event details on that VM that gave me some new information.  The first event says "Virtual Machine is starting" and the next one down says, "Could not power on VM : Admission check failed for memory resource".  I did some searching on the internet and most people who were getting this had very low end machines trying to run multiple VM's and they had to lower the amount of resources each VM used before they could power them on.  However, each of of our hosts has 16GB of RAM with 2 quad core procs and there really aren't that many VM's running at the moment.  Also, I am able to manually power that machine on without any problem.  Have you ever seen that before?

 

Coordinator
Feb 1, 2010 at 11:04 PM

Never seen this. You should ask someone at VMWare, sorry.

Feb 1, 2010 at 11:12 PM

No problem, I appreciate your help up to this point.

 

Coordinator
Feb 8, 2010 at 2:00 PM

Looks like your thread on the VMWare forum had a solution!

Feb 8, 2010 at 4:01 PM

Yes, it certainly did.  Thanks again for your help.