Steve_Jin's Accepted Solutions

The problem is the following code: TaskInfo TaskInfoObj = new TaskInfo(); TaskInfo is the type of a property defined with the Task managed object. With the ManagedObjectReference of a Task, you should use PropertyCollector to get its property. The TaskInfo is not meant to be "new"ed. If you use open source VI Java API, you will have Task object, and simple call: TaskInfo ti = task.getInfo(); To clarify the concept, check out: http://www.doublecloud.org/2011/06/managedobjectreference-vs-managedobject/

I think it's better to use a file or environment variable to exchange data with the guest OS.  http://www.doublecloud.org/2012/03/set-environment-variables-in-guest-operating-system-on-vmware/ http://www.doublecloud.org/2012/03/read-environment-variables-in-guest-operating-system-on-vmware/ If you really want to set registry, http://www.doublecloud.org/2012/02/run-program-in-guest-operating-system-on-vmware/ http://en.wikipedia.org/wiki/Windows_Registry#Command_line_editing Good luck! Steve, Author of Open Source VI Java API, VMware VI and vSphere SDK

It's more than the SOAP message itself, but also the related HTTP headers. Check out this article: http://www.doublecloud.org/2011/02/vsphere-sdk-compatibility/ Steve Jin, Author of VMware VI and vSphere SDK, Creator of Open Source VI Java API, http://www.doublecloud.org

A session is terminated by vCenter server in 30 minutes (default) of inactivity. Also check out my articles: http://www.doublecloud.org/2010/02/the-mythical-sessions-in-vsphere-and-vi/ http://www.doublecloud.org/2010/01/tips-on-session-management-for-scaling-your-server-applications-to-vsphere/ Steve, author of VMware VI and vSphere SDK

Hi Vivek, You are on the right track. Just remove the jars from Apache AXIS, and you will be good. All jars you need is the vijava*.jar and dom4j*.jar. Good luck! Steve (http://www.doublecloud.org)

I hope my blog can help you to understand the session management: http://www.doublecloud.org/2010/02/the-mythical-sessions-in-vsphere-and-vi/ http://www.doublecloud.org/2010/01/tips-on-session-management-for-scaling-your-server-applications-to-vsphere/ Steve JIN Author of VMware VI and vSphere SDK (Prentice Hall) Creator of open source vSphere (VI) Java API(Tutorial, Testimonials, Download, Samples, Forum) Blog: DoubleCloud.ORG ( Top 10 Best Practices,[Object Model|http://www.doublecloud.org/2010/02/object-model-of-vmware-vsphere-api-a-big-picture-in-2-minutes/],[Common Mistakes|http://www.doublecloud.org/2010/01/31/common-mistakes-using-vmware-vi-and-vsphere-sdk/], Tiny REST API, Cloud Application Architecture) Twitter: @sjin2008

Something wrong in your SOAP request. The "object" referred in the return fault does NOT mean the vm object you are trying to search by IP, but the SerachIndex object with which the FindByIp() method is defined. <n:_this type="SearchIndex">FindByIp</n:_this> should be <n:_this type="SearchIndex">SearchIndex</n:_this> I am not very sure if the value of second SearchIndex, maybe it's "searchIndex", but you can double check using MOB. The "FindByIp" should be earlier than <n:_this. Also, I haven't a namespace "n" before. How did you get it? Steve JIN Author of VMware VI and vSphere SDK (Prentice Hall) Creator of open source vSphere (VI) Java API(Tutorial, Testimonials, Download, Samples) Blog: DoubleCloud.ORG ( Top 10 Best Practices,[Common Mistakes|http://www.doublecloud.org/2010/01/31/common-mistakes-using-vmware-vi-and-vsphere-sdk/], Tiny REST API)

I think it's an issue of Apache. Instead of solving the problem, you want to try the open source VI Java API (see my signature for links). It use much less memory and no memory leak at all. I believe after switching, you won't have this issue unless other part of you app demands too much memory. As a bonus, VI Java is much faster than AXIS. Steve JIN Author of VMware VI and vSphere SDK (Prentice Hall) Creator of open source vSphere (VI) Java API Blog: DoubleCloud.ORG Twitter: @sjin2008

The "View" type is provided in both VI Perl and VI .Net (part of VI Powershell, see the developer guide). They are not part of Web Service API. Note: this "View" is client side concept, kind of cached copy of remote managed object. Don't confuse it with the View managed object type and its subtypes on the server side. Steve JIN, VMware Engineering Creator of VMware Infrastructure Java(Jython) API. VI Java API 2.0 --- 15 times faster than AXIS in loading, 4+ faster in deserialization; only 1/4 of the size required by AXIS. More importantly, the freedom to redistribute it with your applications. (Download, Samples, DocWiki, RSS Feed) Get Connected with Other Developers in the Community?

Hi Manfred, Sorry that I don't have VB Script, but you can take a look at the VI Java API source code to get the idea. Check the com.vmware.vim25.mo.Task class for the waitForMe() method. You can read on the web http://vijava.svn.sourceforge.net/viewvc/vijava/trunk/src/, or download all the source from download link as listed below. Steve JIN, VMware Engineering Creator of VMware Infrastructure Java API. VI Java API 2.0 --- 15 times faster than AXIS in loading, 4+ faster in deserialization; only 1/4 of the size required by AXIS. More importantly, the freedom to redistribute your applications. (Download, Samples, DocWiki, RSS Feed) Get Connected with Other Developers in the Community?

if TypeOf var is TaskReasonAlarm Then end if There are three other possible types: TaskReasonSchedule, TaskReasonSystem, TaskReasonUser Steve JIN, VMware Engineering Creator of VMware Infrastructure Java API. VI Java API 2.0 --- 15 times faster than AXIS in loading, 4+ faster in deserialization; only 1/4 of the size required by AXIS. More importantly, the freedom to redistribute your applications. (Download, Samples, DocWiki, RSS Feed) Get Connected with Other Developers in the Community?

Check out the PerformanceManager @ VI Java API samples at Steve JIN, VMware Engineering Creator of VMware Infrastructure Java API. VI Java API 2.0 --- 15 times faster than AXIS in loading, 4+ faster in deserialization; only 1/4 of the size required by AXIS. More importantly, the freedom to redistribute your applications. (Download, Samples, DocWiki, RSS Feed) Get Connected with Other Developers in the Community?

VMware tools has to be installed in order to get exact information about your guest OS. A VM does NOT really knows what OS runs on it unless you install the VMware tool. This is not a VI SDK limit per se. Steve JIN, VMware Engineering Creator of VMware Infrastructure Java API: http://vijava.sf.net VI Java API 2.0 --- 15 times faster than AXIS in loading, 4+ faster in deserialization; only 1/4 of the size required by AXIS. More importantly freedom to redistribute your applications. Download, Samples, DocWiki, RSS Feed

Yes. Check out: http://pubs.vmware.com/vi-sdk/visdk250/ReferenceGuide/vim.SessionManager.html#sessionIsActive Steve JIN, VMware Engineering Creator of VMware Infrastructure Java API: VI Java API 2.0 --- 15 times faster than AXIS in loading, 4+ faster in deserialization; only 1/4 of the size required by AXIS. More importantly freedom to redistribute your applications. Download, Samples, DocWiki, RSS Feed

The VI 3.5 (ESX3.5/VC2.5) is not compatible with its predecessor VI 3.0 (ESX 3.0/VC2.0), mainly because the namespace issue. Moving forward, all should be compatible. Steve JIN, VMware Engineering Creator of VI Java API:

According to the API ref, the capacityInKB is required. In theory, you shouldn't need to provide that. But the API ref (and WSDL) says yes. Since you already retrieve the information about the VirtualDisk, I would suggest you grab the whole VirtualDisk object from the config.hardware.device property and assign it directly to your diskSpec. Good luck! Steve JIN, VMware Engineering Creator of VI Java API:

When you create the floppy device, make sure you choose "create" in the VirtualDeviceSpec.FileOperation http://pubs.vmware.com/vi-sdk/visdk250/ReferenceGuide/vim.vm.device.VirtualDeviceSpec.FileOperation.html http://pubs.vmware.com/vi-sdk/visdk250/ReferenceGuide/vim.vm.device.VirtualDeviceSpec.html Steve JIN, VMware Engineering Creator of VI Java API:

From the virtual machine, you can find the datastores it associated (the datastore property). From each datastore, you can find the corresponding HostDatastoreBrowser (the browser property). From the HostDatastoreBrowser object, you can call either SearchDatastore_Task() or SearchDatastoreSubFolders_Task. When you call either of the methods, a Task object is returned. Upon the success of the Task, check the info.result property of the Task, the real result HostDatastoreBrowserSearchResults object is there. Check out the FileInfo objects -- they include the sizes and last modification times of files. Good luck. Steve JIN, VMware Engineering Creator of VI Java API:

The line (_service = null;) just tells Java that the object is OK to be garbage collected. It does NOT notify the server to logout current session. The reason (_service.logout(_svcRef);) didn't work is because the it's passed in wrong parameter. The logout is defined with SessionManager, not ServiceInstance. If you code in Java, you can use VI Java API which makes your code much less and much more readable. Steve JIN, VMware Engineering Creator of VI Java API:

Try this: C:\Windows\system32\cmd.exe C:\VMware\VMwareCLI\scripts\call_migrate_perl.cmd Actually, you can just run the perl scripts as this: C:\Perl\perl.exe C:\scripts\migrate.pl Note: the commands are executed under "System", not the currently login user. So you won't see it visually. You can take a look using Windows Task Manager if needed. Further, you can have placeholder parameters that will be replaced before the "scripts" are actually run. Good luck! Steve JIN, VMware Engineering Creator of VI Java API: