I looked at fog.io when I originally started prototyping the provider, and the lack of documentation and examples around the fog.io vSphere provider is part of the reason I chose to implement with RbVmomi. RbVmomi also appealed to me because it was close enough to the vSphere APIs that the library could be maintained, or new abstractions could be built to interact directly with that API if necessary. 

I took a quick look tonight at the abstractions fog.io provides for vSphere, and it was not obvious to me that the abstractions would improve this provider's maintainability. I can see how adopting a single API to abstract communication to various virtualization technologies could help veewee overall if providers get consolidated. If that is the desire/intention, then I'd recommend that an issue be created to convert the existing providers over to gain similar benefits.

From my review of fog.io, there are at least two places where RbVmomi features I have used have no analogue in fog.io:

1. Uploading ISO images from the calling machine to a vSphere datastore
2. Checking whether to VM is locked with a CD-ROM error post-OS installation, and clearing the condition

I think the first item could be implemented using fog.io calls to feed direct http calls (and I intend to go back and make that enhancement to the current solution to replace the dependency on curl). The second items I don't have a better approach than falling back in fog.io to the raw RbVmomi VM, which would make the interface to fog.io for the vSphere provider brittle. If there is an alternate way of making that work that doesn't require more pain than going direct through RbVmomi, then I am willing to take a closer look.