Newbie Question - VixCom 1.2 & Server 2 Beta 1

[John_Swainston]

Hi,

I'm a complete newbie at using VIX, and have a hopefully simple question.

I am using WMWare Server 2 Beta (Build 63231), and want to create a c# app to control the VM's.

I have installed the server components on Windows 2003 Enterprise x64, and have a couple of VM's running on the server.

From my development machine I have been using VS2008 (RTM Version) to create a .Net 2.0 C# test app to connect to the server.

From various installs of VIX, Server & Workstation I seem to have three different VixCom.dll, all with version 1.0.0.1.

All the Vix versions I have seem not to have the 1.2. API documentation, but only the 1.1. The parameter I have seen on the forums to connect to the Server is "VIX_SERVICEPROVIDER_VMWARE_VI_SERVER", which is not a constant I can find in any of the DLL's I have. Also, the DLL from the server does not seem to work on my development machine - perhaps due to conflicts of x64 and x86 libraries?

FYI, I have installed (at various times)

Workstation 6

Server V1

Server V2

VIX api 1.1.2

VMWare-vix-e.x.p-63621.exe,

and get a VIX_API_VERSION of 2 for some dll's, and 3 for others.

As I'm new to this could someone tell me what DLL I need for this connection, and is it a VixCom.dll, or do I need to PInvoke a Vix.dll?

Sorry for the rambling message, but I seem to be going around in circles.

Thanks,

John....

[JPatten · Accepted solution]

The reason it is not showing as a constant is due to the VixCOM.dll you are referring to in your application. This can happen when you install a new version of VIX without uninstalling the old one.

Remove all references in your .NET app to VixCom.

I would use Add/Remove Programs and remove VMWare VIX and delete the folder C:\Program Files\VMWare\VMWare VIX. Then, run the VIX 1.2 setup (VMWare-vix-e.x.p-63621.exe).

Add the VixCOM.dll from the VIX folder as a reference to your app. The dll it calls is located in the ws_server_esx-4 folder in the VIX program folder. This has the new service provider constant.

[John_Swainston]

Hi,

Deleting the VIX directory after ininstalling, and then reinstalling seemed to do the trick.

However, I now keep getting "The program '[2272] VMWareTest.vshost.exe: Managed' has exited with code 1 (0x1)." when trying to do a connect.

I have a reference to VixCOM in the project, and have included the ws_server_esx-4 dll's in the application directory.

The code I'm using to connect is nicked from another thread (), and is as below.

Any thoughts?

Thanks,

John....

VixCOM.VixLibClass vixlib = new VixCOM.VixLibClass();

UInt64 err = 0;

object results = null;

Console.WriteLine("Connecting...");

VixCOM.IJob job = vixlib.Connect(VixCOM.Constants.VIX_API_VERSION, VixCOM.Constants.VIX_SERVICEPROVIDER_VMWARE_VI_SERVER, "https://192.168.253.15:902/sdk", 0, "user", "pw", 0, null, null);

err = job.Wait(new int[] { VixCOM.Constants.VIX_PROPERTY_JOB_RESULT_HANDLE }, ref results);

Console.WriteLine("Connected....");

[JPatten]

It could be a missing DLL, which is one of the problems I ran into with this version of the VIX. Since debug of the VIX is turned on, you will need MSVCR71D.dll in either the application directory or c:\windows\system32

If you have that already, you can use the depends.exe tool from microsoft to step through the VixCOM.dll and see if it is missing any other dependencies.

Is this a console application or Windows form? If it is console, you will get output to the console about the VIX initializing. Otherwise, check your temp folder (Easiest way is go to start -> run and type in %TEMP%) and you should see a folder name "vmware-*" . There will be some VIX log files in there which may have some helpful messages if it gets that far.

[John_Swainston]

Thanks for the help.

In the vmware logs I'm now getting the below. The vixd.dll does exist in the directory that it fails to load from, but the path has a double backslash so I don't know if that is causing a loading issue.

I've added the DLL you suggested,but to no avail. Also, the dependency walker seems to indicate all is fine.

Any Idea?

Thanks,

John....

Nov 22 16:40:09.720: app| Log for VixWrapper pid=1428 version=1 build=build-63231 option=BETA

Nov 22 16:40:09.722: app| vixWrapper config file D:\Program Files\VMware\VMware VIX
vixwrapper-config.txt not found

Nov 22 16:40:09.722: app| vixWrapper config file D:\Program Files\VMware\VMware VIX
vixwrapper-config.txt not found

Nov 22 16:40:09.722: app| Failed to load wrapper configuration file

Nov 22 16:40:09.723: app| config points to non-existant implementation dir 'ws-3'

Nov 22 16:40:09.723: app| config points to non-existant implementation dir 'ws-3'

Nov 22 16:40:09.723: app| config points to non-existant implementation dir 'ws-2'

Nov 22 16:40:09.723: app| config points to non-existant implementation dir 'server-1'

Nov 22 16:40:09.724: app| Loading Vix implementation library D:\Program Files\VMware\VMware VIX
ws_server_esx-4\32bit\vixd.dll

Nov 22 16:40:09.735: app| failed to load library D:\Program Files\VMware\VMware VIX
ws_server_esx-4\32bit\vixd.dll (126)

Nov 22 16:40:09.735: app| failed to load library D:\Program Files\VMware\VMware VIX
ws_server_esx-4\32bit\vixd.dll (126)

Nov 22 16:40:09.735: app| No Vix library found for provider 10 revision 4

[admin]

Please try running the dependency walker on D:\Program Files\VMware\VMware VIX\ws_server_esx-4\32bit\vixd.dll and seeing if any missing dependencies are reported.

[John_Swainston]

Thanks!

Running the dependency walker on the vixd.dll (rather than the VixCOM.dll) showed that it was indeed a missing MSVCR71D.dll

I now seem to be over my DLL Hell, and should hopefully be able to cobble together a simple VM backup service

Regards,

John....

[giordano]

hi

where is the correct download for Vix 1.2 ?

i found only "VMware-vix-1.1.2-59824" on downloads section ..and seem not correct for VMWare Server 2.0.

Thanks for the help

[admin]

VIX 1.2 is currently in beta release and should be available on the Server 2.0 beta download page.

[pyopyopyo]

I found a workaround for this issue;

just rename vix.dll to vixd.dll

[pyopyopyo]

I found a workaround for this issue;

just rename vix.dll to vixd.dll