All Posts

Hi Mark, This is a brand new forum. We actually just subdivided the API/SDK discussion into several forums, so that it would be easier to find and answer questions on each different. So, thanks for taking the plunge and writing first, and rest assured that we're watching and answering. Let me start by just throwing a workaround your way for a client library to use against Server 1.0.x on Linux-64: Use the VIX libraries that are installed with Server 1.0.3. They are the latest and greatest. The server-1 libraries that are installed with the standalone VIX API 1.1 are exactly the same. (Only the Workstation client libraries are new in that distribution.) That should get you past the installer's lockout of installing the 32-bit libraries on a 64-bit host. Now, remember that VIX API support of Server 1.0 is beta/experimental, which is part of the reason why it doesn't include 64-bit libraries -- we just didn't have them yet in that product generation. Sorry, running the 32-bit client libraries on a 64-bit linux host is not a supported/tested configuration. You're right, the seg fault is probably due to the glibc mismatch. As you're clearly aware, you could get around this by installing an older gcc. You could also get around this by linking directly to the .so, but as mentioned that does not exist in a 64-bit flavor. I think you could build your client app 32-bit, and link to the .so. On the Windows side, can you be more specific about what your'e seeing? We've tested those client libraries with both VS .net 2003 and 2005, but we don't know of any change that should break backwards compatibility to VS6. (Note: The Workstation 6 IDE integration feature for Visual Studio \*does* require 2005, but that's a totally separate issue, nothing to do with VIX API.) Hope this helps... --Matt

Yes, your earlier code was also releasing the jobHandle twice as it exited, as well as calling VixHost_Disconnect() twice. You're also leaking a jobHandle from the VixHost_Connect() (which essentially means a memory leak). And I'd suggest catching the return value of the VixJob_Wait() after the VixHost_FindItems().

so this is getting a bit funny: I tried removing the Vix_ReleaseHandel(jobHandle) in VixDiscoveryProc() but I was still getting segfaults. this seems to be happening in main, as if it tries to execute abort no matter what. if I return(-1) then all is good. below is the compelete program which works without any segfaults on 32bit. on the 64bit machine I could only get this code to run if I use VMware-vix-1.0.3 and -m32 when compiling. below is the full listing of the code: #include "stdio.h" #include "string.h" #include "vix.h" static VixHandle hostHandle = VIX_INVALID_HANDLE; static VixHandle jobHandle = VIX_INVALID_HANDLE; void VixDiscoveryProc(VixHandle jobHandle, VixEventType eventType, VixHandle moreEventInfo, void *clientData) { VixError err = VIX_OK; VixHandle vmHandle = VIX_INVALID_HANDLE; char *url = NULL; // Check callback event; ignore progress reports. if (VIX_EVENTTYPE_FIND_ITEM != eventType) { return; } // Found a virtual machine. err = Vix_GetProperties(moreEventInfo, VIX_PROPERTY_FOUND_ITEM_LOCATION, &url, VIX_PROPERTY_NONE); if (VIX_OK != err) { // Handle the error... goto abort; abort: printf("Aborting in discover\n"); Vix_ReleaseHandle(jobHandle); VixHost_Disconnect(hostHandle); } printf("\nFound virtual machine: %s\n", url); } int main() { VixError err; // Connect to specified host. jobHandle = VixHost_Connect(VIX_API_VERSION, VIX_SERVICEPROVIDER_VMWARE_SERVER, "vmserver", //serverName 902, // hostPort "root", // userName "password", // password, 0, // options VIX_INVALID_HANDLE, // propertyListHandle NULL, // callbackProc NULL); // clientData err = VixJob_Wait(jobHandle, VIX_PROPERTY_JOB_RESULT_HANDLE, &hostHandle, VIX_PROPERTY_NONE); if (VIX_OK != err) { // Handle the error... printf("An error occurred\n"); goto abort; } printf("\nLooking for running virtual machines"); jobHandle = VixHost_FindItems(hostHandle, VIX_FIND_RUNNING_VMS, VIX_INVALID_HANDLE, // searchCriteria -1, // timeout VixDiscoveryProc, NULL); VixJob_Wait(jobHandle, VIX_PROPERTY_NONE); Vix_ReleaseHandle(jobHandle); VixHost_Disconnect(hostHandle); return(0); abort: printf("Aborting in main\n"); Vix_ReleaseHandle(jobHandle); VixHost_Disconnect(hostHandle); return(-1); }

Yeah, I was afraid you'd copied that bit of docs -- it had a nasty but subtle bug in the jobHandle refcounting. The call to Vix_ReleaseHandle(jobHandle) in the VixDiscoveryProc() is bogus, and probably causing your crash (its overly decreffing that handle). Remove that line, and see if things get happier. VMware server supports just once snapshot, and Vix enforces that. The latest docs are at http://pubs.vmware.com/vix-api/ReferenceGuide/ The functional reference does refer to things only available in the latest release, but each function should specify which release it works with.

Hi, well thank you for taking the time to look into all this. Great work indeed and we all miss things one time or another. I have 1 more questions(there is always 1 more, right?) would I be able to take multiple snapshots with the vix api against a vmware server product giving the snapshots different names or would it always take 1 snapshot overwriting the existing snapshots below is the full listing of the code which causes the segfault, it pretty much came out of the docs. I haven't started doing anything complex yet. #include "stdio.h" #include "string.h" #include "vix.h" static VixHandle hostHandle = VIX_INVALID_HANDLE; static VixHandle jobHandle = VIX_INVALID_HANDLE; void VixDiscoveryProc(VixHandle jobHandle, VixEventType eventType, VixHandle moreEventInfo, void *clientData) { VixError err = VIX_OK; VixHandle vmHandle = VIX_INVALID_HANDLE; char *url = NULL; // Check callback event; ignore progress reports. if (VIX_EVENTTYPE_FIND_ITEM != eventType) { return; } // Found a virtual machine. err = Vix_GetProperties(moreEventInfo, VIX_PROPERTY_FOUND_ITEM_LOCATION, &url, VIX_PROPERTY_NONE); if (VIX_OK != err) { // Handle the error... goto abort; } printf("\nFound virtual machine: %s\n", url); abort: Vix_ReleaseHandle(jobHandle); Vix_FreeBuffer(url); } int main() { VixError err; // Connect to specified host. jobHandle = VixHost_Connect(VIX_API_VERSION, VIX_SERVICEPROVIDER_VMWARE_SERVER, "vmserver1", // hostName 902, // hostPort "root", // userName "password", // password, 0, // options VIX_INVALID_HANDLE, // propertyListHandle NULL, // callbackProc NULL); // clientData err = VixJob_Wait(jobHandle, VIX_PROPERTY_JOB_RESULT_HANDLE, &hostHandle, VIX_PROPERTY_NONE); if (VIX_OK != err) { // Handle the error... goto abort; } Vix_ReleaseHandle(jobHandle); printf("\nLooking for running virtual machines"); jobHandle = VixHost_FindItems(hostHandle, VIX_FIND_RUNNING_VMS, VIX_INVALID_HANDLE, // searchCriteria -1, // timeout VixDiscoveryProc, NULL); VixJob_Wait(jobHandle, VIX_PROPERTY_NONE); Vix_ReleaseHandle(jobHandle); VixHost_Disconnect(hostHandle); abort: printf("Aborting\n"); Vix_ReleaseHandle(jobHandle); VixHost_Disconnect(hostHandle); }

Can you post your complete code, include the discovery procedure? The online docs are the most up-to-date, and we did recently clean up several problems in the sample code (including possibly the inconsistency you spotted, where the docs used Vix_INVALID_HANDLE -- this was a doc bug.) Thanks for pointing out the case typo in the Simple docs -- that slipped by everyone til now.

I tried both VMware-vix-1.0.3 and VMware-vix-1.1.0 on a 32bit machine. I am still getting segfault half way through the "finditems" loop. strace makes it look like it was on a poll on the temporarily file created. is this a known issue or do you suspect it has to do with my environment? There are a few cases where the documentation was not accurate when it included example code. also the documentation for VMware::Vix::Simple has a typo, one line says "use VMware::Vix::Simple" and the other says "use VMWare::Vix::Simple".

There's no native support for 64 bit linux in vmware server, and we only tested 32 bit. 1.1 does have compatiblity, but still only 32 bit for vmware server. The API should be consistant with names. Functions start with Vix, constants with VIX. The latest docs should be correct and on the web.

I initially installed vix-1.1.0 release, which claimed to be compatible with server. it had a 64bit version under ws-2 and I tried to use that initially and it did not work so I installed the vix1.0.3 release and with -m32 things sort of work. I am going to try 1.1.0 with -m32 and if all fails I will have to use a 32bit machine. Do you know of any plans to have 64bit support for vix with server? Also, do you know if the API is going to get standardized in case and conventions. some calls use VIX and other use Vix. the docs seem to be out of date on the case isssue. Thanks. I will post what I find.

I personally have had very little success using -m32 with a 64 bit gcc to link with 32 bit libraries -- it tends to have major issues with CRT code. Do you have any issues on a 32 bit Linux? Im still confused what versions are being used -- the ws-2 directory is part of the Workstation 6 Vix, and is used only for Workstation, not Server.

Yes I changed the port number because the installer claimed 902 was in use. I can connect and query the server now but I am seeing different problems as described in the othe other posts in this thread.

Did you change the port number when you installed VMware Server? The default port that it listens on is 902, but you are trying to connect on port 904. When you try to establish a remote connection to a port that is not listening, the VixJob_Wait for that connect job will wait indefinitely. You can also use VixJob_CheckCompletion to check if the call has succeeded without blocking.

Hi, I found a solution, one must pass -m32 flag to the compiler to be able to link against the 32bit versions of the libraries. The ws-2 64bit version don't work on vmwar-server up to 1.0.3. This is what I used to complie code that worked. gcc -m32 -o hostconnect hostconnect.c -I/usr/include/vmware-vix /usr/lib/libvmware-vix.so.0.0.0 The only thing is I get a segmentation fault at the end. much like what I am used to seeing from vmrun up to VMware server 1.0.2. Any hints what I can do to fix that?

OS: OpenSUSE 10.2 x86_64 VMware Product: VMware server VMware Product version: VMware-server-1.0.3-44356 Vix version: VMware-vix-1.0.3-44356.tar.gz let me know if there is anything else to help file a bug on this or find a way to get it to work