PowerOn throws TimeoutException + VWare tasks does not work on the VM

Jan 6, 2012 at 7:44 AM

I almost pull my hair from my head since i work on my problem for a week

I have ESXi4.1 and vSphere 4.1

I also installed Vix 1.6.2 since this is the only free API

I've also downloaded the VMware Tasks 1.5 and tried also previous versions...

imported to my project all of the VMWare Tasks dlls

I do the following:

static void Main(string[] args)        {


using ( VMWareVirtualHost virtualHost = new VMWareVirtualHost()) 

// connect to a remote (VMWare ESX) virtual machine 
virtualHost.ConnectToVMWareVIServer(ESXi IPUsername, Password);  //OK CONNECTED GOOD
// open an existing virtual machine 
VMWareVirtualMachine virtualMachine = 
virtualHost.Open("[datastore1]  somevm/somevm.vmx");  // OK OPENED GOOD

// power on this virtual machine 

// wait for VMWare Tools 

// power off 



I can't find anything in forums except here that someone got something similar and he didnt get any answer

Is it connected to that i have free license?? since i don't want to buy license unless i need it

it is very simple commend, only to power up so it is strange not to work on free version

i dont know if its he VMWare tasks bug or Vix bugs....

moreover when the VM is up manually and i try to runprogram without doing the PowerOn method before which does not work, it says that "virtual machine needs to be powered on"... BUT IT IS POWERED ON

Moreover when  VM is up manually , and I check if (vm.IsRunning) it returns false!!

Why such simple actions does not work?!?!?

PLLLLLEEAAAASSEEE help i work on somethiong huge in my company and i really can use some help

thanks alot


###This Discuss is continues to the following discuss: ###


Jan 6, 2012 at 3:31 PM

I don't think Vix 1.6.2 is compatible with ESXi 4.1. 1.6.2 also had lots of known issues and so even if it worked, you'd probably get stuck later. You could always ask this question on the Vix API community forum. The bottom line you'll need a license at the end of the day, so if you're looking for free, this is no longer a viable solution.

Jan 20, 2012 at 1:34 AM

I had this same problem with timeouts With ViX versions 1.10 and earlier, but I just tried to reproduce it and failed. That's a total mystery to me, but many of the users of my code face it now too... In fact, it's a problem that has plagued me for many months, but appears to have been resolved by my upgrade to VMWare 8. I experience this problem on VMWare Workstation 7-8, VMWare Server 2.0, and ESXi/vSphere 4.x. Basically if I specify a timeout over 2100 seconds, which comes to 35 minutes, VMWare Tasks was throwing an exception. Function below. This is running applications in interactive mode, which is a requirement I have. This test is just going to be simply running notepad.

2100 second output... Notepad starts in interactive mode, I click close rather than wait for 35 minutes to pass (at 35 minutes I'd get a timeout exception, which is expected since that's what timeout is for):

Type is VMWare
Connecting to VMWareWorkstation
Opening VMWare Session.
Revert to Snapshot disabled.
Not Powering on: Power Expected to already be on.
Remote desktop is not enabled.
Waiting for VMWare tools in client
VMWare ATP task logging into process
Logging in as (domain): Plant.Tester
Executing (waiting for the process to complete):
    c:\windows\system32\notepad.exe C:\ATP\test.txt
VM Timeout: 2100
False 0 3788
Leaving VM Powered On.

2101 second output:

Well, this used to throw an exception, so I'm going to have to work more on reproducing this issue and see if I can upgrading to ViX 1.11 doesn't just solve the problem. What version of ViX ships with VMWare Workstation? I know it's "workstation versioned" but perhaps the issue is that the users just have the version shipped with VMWare Workstation?

Any feedback on this would be great.



        /// <summary>Run an Application.</summary>
        /// <param name="apppath">Path to the program that will be executed.</param>
        /// <param name="apparg">Arguments passed to the app to be executed.</param>
        /// <param name="isInteractive">Setting this to true causes the program to wait for
        /// for program execution to finish before returning from the process.
        /// Setting this to false causes the program to return immediately regardless of
        /// whether or not the process has finished executing.</param>
        /// <param name="checkReturnCode">Optional flag that if set to true checks the return
        /// code of the app run.</param>
        ///<author>Henry.Pinney</author>                                <date>3/2011</date> 
        public override void RunApp (string apppath, string apparg, bool isInteractive, bool checkReturnCode)
            int vmrunmode = Constants.VIX_RUNPROGRAM_ACTIVATE_WINDOW;
            if (isInteractive)
                Trace.WriteLine ("Executing (waiting for the process to complete):");
                Trace.WriteLine ("Executing (returning immediately):");
                vmrunmode = Constants.VIX_RUNPROGRAM_RETURN_IMMEDIATELY;
            Trace.WriteLine ("    " + apppath + " " + apparg);

                Trace.WriteLine ("VM Timeout: " +m_vm.VmTimeout);
                VMWareVirtualMachine.Process vmproc = m_virtualMachine.RunProgramInGuest (apppath, apparg, vmrunmode, m_vm.VmTimeout);
                Trace.WriteLine (vmproc.IsBeingDebugged + " " + vmproc.ExitCode + " " + vmproc.Id);
                if (checkReturnCode)
                    if (vmproc.ExitCode == Constants.APP_SUCCESS)
                        throw new VMWareException(200, "Application did not exit successfully!");
            catch (VMWareException ex)
                Trace.WriteLine ("Exception running program in guest: " + apppath + " " + apparg + "");
                Trace.WriteLine ("Error: " + ex.ErrorCode + " " + ex.Message);



Jan 26, 2012 at 2:57 AM

Update on this issue: VMWare Workstation 7.x (and possibly VMWare Server 2.x and other VMWare products made around that time) would crash during startup when vmTimeout values above 2100 (seconds) were specified on some function calls. My code was using one user-configurable timeout setting (pulled from XML) for all of the VMWare timeout parameters. This 2100 second timeout limitation was resolved in VMWare Workstation 8.x (i.e. no code changes--it just worked fine with 8.x). It was determined that timeout values used by VMWare functions do not all behave the same. Some of the functions seem to fail when long timeouts were given (above 2100 seconds), but after some trial and error it was clear that this was not a limitation for RunProgramInGuest. I did not test the timeout limitations of all of the other functions, but I set the timeouts for ConnectToVMWareWorkstation, ConnectToVMWareVIServer, RevertToSnapshot,  PowerOn, PowerOff, WaitForToolsInGuest, and LoginInGuest to something reasonable--RunProgramInGuest is really the only thing I can reasonably expect to take more than 35 minutes to execute (we're executing automated tests, so they can potentially run for hours). Instead of adding values for each of the other timeouts, the code was updated to use separate, lower timeout values for those timeouts that might cause critical errors, while continuing to allow vmTimeout to control the timeout for RunProgramInGuest. A 2100 second maximum timeout is more than sufficient time for PowerOn/Off/authentication functions. This fix was tested and confirmed to still work on VMWare Workstation 8.0.1 (though this was never an issue for 8.x since it never threw an exception), as well as fix the problem for VMWare Workstation 7.1.4.

Basically, if you want to reproduce this issue:

What the original posts says is true. Use VMWare Workstation 7.0.1 - 7.1.5 (reproduced on several versions of 7.x), ViX 1.11 (reproducible on other versions as well, but this is what I used), and Vestris VMWare Tasks 1.5. Set the PowerOn timeout to a large value, say 2200 seconds or higher. VMWare will crash during startup.

Note that this issue is definitely not reproducible with VMWare Workstation 8.x.