This Question is Possibly Answered
1 "correct" answer available (10 pts) 2 "helpful" answers available (6 pts)
Thanks! The library is synchronous, so Execute runs notepad and returns only when it's done. My example might have been not so clever - if you run a GUI application without a remote desktop you're not going to be able to do much
Wow, looks like we were working on the same thing the last weeks, since I published my VIX API C# library to Codeplex one day after you wrote your CodeProject article
My library basically does the same as yours, it simplifies dealing with the VIX API and makes common tasks (powering on/off, copying files) a lot easier.
I also took the time and fully commented the functions (using the official documentation), so you get hints from IntelliSense while coding, which I find really helpful.
Although your library implements less functions than mine (I wrapped them all...), it seems like you have the better concept when dealing with IJobs.
If you want to take a look at my approach, visit http://www.codeplex.com/VixCOMWrapper and download the library
Regards, Alex
Hey Alex,
I've been adding features while you were away! I really think the VMWare development team should produce something like this, so hopefuly seeing multiple implementations will give them the right object model to start with. A library that is not a wrapper on top of the COM API is really the right answer, there's no need to have a COM object registered to talk to VMWare. You wouldn't need to package the VIX COM DLLs if you were to distribute anything that talks to VMWare. Heck, VMWare should give us a million bucks to share for designing it for them
If I may allow some criticism of the stuff on CodePlex: I think that your library needs to be more consistent with constructs like snapshots or shared folders: those are all objects and should be manipulated as collections. I chose not to implement methods like AddSharedFolder(name, description) - from the object model perspective you want VirtualMachine.SharedFolders.Add(new VMWareSharedFolder(name, description)), then VirtualMachine.SharedFolders reflects the changes. This also applies to snapshots and all other things that belong to the VM. Other important aspects include an active timeout - VMWare won't timeout in blocking operations.
I also wanted to thank you - I learned something from your implementation - I was wondering what the right way of implementing things like Snapshot.Name is - your code helped. I also added Snapshot.Path - post.
Some competition is a good thing! People should use whatever they think is best. Of course, you're welcome to give up the CodePlex library and contribute to VMWareTasks
cheers
dB.
I've been adding features while you were away! I really think the VMWare development team should produce something like this, so hopefuly seeing multiple implementations will give them the right object model to start with. A library that is not a wrapper on top of the COM API is really the right answer, there's no need to have a COM object registered to talk to VMWare. You wouldn't need to package the VIX COM DLLs if you were to distribute anything that talks to VMWare. Heck, VMWare should give us a million bucks to share for designing it for them
If I may allow some criticism of the stuff on CodePlex: I think that your library needs to be more consistent with constructs like snapshots or shared folders: those are all objects and should be manipulated as collections. I chose not to implement methods like AddSharedFolder(name, description) - from the object model perspective you want VirtualMachine.SharedFolders.Add(new VMWareSharedFolder(name, description)), then VirtualMachine.SharedFolders reflects the changes. This also applies to snapshots and all other things that belong to the VM. Other important aspects include an active timeout - VMWare won't timeout in blocking operations.
I also wanted to thank you - I learned something from your implementation - I was wondering what the right way of implementing things like Snapshot.Name is - your code helped. I also added Snapshot.Path - post.
Some competition is a good thing! People should use whatever they think is best. Of course, you're welcome to give up the CodePlex library and contribute to VMWareTasks
cheers
dB.
Hi!
I totally agree that an implementation on top of the COM API shouldn't be necessary, cause this just adds another layer of complexity. It would also be nice if there was a way to use our library on Linux systems (e.g. by leveraging the capabilites of the Mono framework).
Of course I also looked at your source-code and I have to admit that your implementation follows the concept of OOP much better
My intention was to just have a library that looks similar to the original VIX API, but uses C#-style parameters and return values and hides me from dealing with handles, blocking, etc.
I'll have to look at implementing a timeout for the Wait() function, thanks for that !
As you've said, we can only benefit from having seperate approaches and maybe the VMware developement team benefits too
Regards, Alex
Hi!
I just tried it against my ESXi host (3.5.0 build-123629) and it works without problems. Remember that you need at least ESX Update 2 for VIX to work, the default port for connection is 443. Basically, VIX needs the same credentials/IP that you would enter when you connect with the VMware Infrastructure Client.
You don't need to install VIX on the host, just on the machine from where you want to connect to the ESXi server.
If that doesn't help, please let me know
Regards, Alex
Hi!
The documentation is a standard CHM-helpfile, it should open on any Windows system since Windows 98
There may be problems if you try to open it from a network location, so store it locally on your computer.To answer your question: the wrapper doesn't support copying files directly from a ESX datastore to a guest VM and vice versa. There are functions that copy files (CopyFileFromHostToGuest and CopyFileFromGuestToHost) but they copy only to/from the system where the Vix client is running, not the ESX host itself.
You could copy the file to your local machine first, and then upload the file to the datastore (which should be possible with the VI API, I guess).
Regards, Alex
Developer SDKs & APIs
- vCloud API
- vNetwork APIs
- vSphere Web Services SDK
- vSphere SNMP MIB
- VMware Studio
- vSphere Client Plug-ins
- Virtual Disk Development Kit
- VIX API
- vSphere Guest SDK
- vCenter Orchestrator
- CIM SDK (SMASH, SMI-S)
- vSphere SDK for Perl
- vCenter Lab Manager API
- VProbes
- vSphere SDK for Java
- Open Virtualization Format Tool
- Automation Tools
- vSphere PowerCLI
- vSphere CLI
- vSphere Management Assistant
