How to list vmware folders using API


I’am struggling to list the vmware folders using the ManageIQ API.

I can use http://miq-server/api/v1/providers/id/folders.

But using this method, I have 2 more challenges :

  • iterate over the full list of folders which is quite long even when using only a few folders. This will not hold when I will have several dozens of folders.

  • find the full path of the folders which is not natively exposed. The folders exposed are only folder names without full path and moreover without any clue on the parent folder.

Is there any native API to get the vmware full paths?

Shall I use a generic_object to expose the informations from Ruby code?


@Remi_Colinet I don’t believe we expose the fully qualified path of a folder, but that seems like a reasonable enhancement.

We have the backend code to generate the path so we can probably expose it via a virtual attribute. My only concern is performance since we’d have to calculate it. Alternately, we should probably add a new column to ems_folders and have the precalculated fully qualified path in there as we have already mentioned in a TODO.

@agrare What do you think?
@Remi_Colinet Can you open an enhancement request at

1 Like

Only issue with setting the full path in refresh is we won’t be able to until the full is completed so we’d have to cache all of the folders which we’re trying to get away from.

I am working through the same problem in trying to find the ID of the folders for placement at deployment time in a VMware environment. It would be nice to be able to do have a listing of this somehow.


I’ve managed to find a long term solution to convert object names to id in order to have placement when submitting VM requests through the provider.

MIQ has the information internally.
So I wrote a gem which is scheduled by the MIQ scheduler.

The gem uses Ruby primitives to collect the mapping between names and id into a YAML file.
See at:

You need to schedule the execution of vmw_show_infos() function in Configuration / Schedule for any given vCenter.

This also has the advantage of performance because the mapping is kept in a YAML file which may be reused without re collecting the mapping each time.


Rather than use a file which would need synchronising across all MIQ appliances in a region, how about making your method callable as an automation request via the API, and return the structure via the request’s options hash?

Relying on files on a filesystem in a distributed environment is fraught with problems. Even if /srv/miq-vms was NFS-mounted, it would be another potential step to forget when you added a new appliance.

Hope this helps,

I agree that an API method would be much better.
But I do not know how to achieve it exactly to produce the json with the mapping.

Should I use a generic object?


No need for a generic object, just produce a json structure instead of yaml, and rather than write it out to a file, write it into the options hash. Then the external caller can retrieve it from the same options hash.

There’s an example here (see " Returning Results to the Caller")

Hope this helps,


Thank you for your response & time
This looks very nice.

In the MIQ schedule details below, I’ve set the vcenter Provider (EMS) which is then used as ems var in the ruby code I wrote. This is the same approach as dumpEMS(ems) in the documentation.

But how can I fetch this object internally from MIQ, outside of the context of a schedule or provider button ? Is there a hash of all the EMS defined ?

Best regards


Description VMWCollect
Active : true
Action: Automate Task
Zone: Default Zone

Object Details:
System/Process: Request:
Message: create
Request: Call_Instance

Object Attribute
Type: Provider
Selection: myvcenter.localdomain

Attribute/Value Pairs:
Instance: show_infos
class: Methods
namespace: Item

From an automate method you can find your provider using something like the following:

ems = $evm.vmdb(:ems).where(:type => 'ManageIQ::Providers::Vmware::InfraManager').first


ems = $evm.vmdb(:ems).find_by(:name => 'My vCenter')