Christophe, I tried to set the most likely component, but please feel free to reassign to a better match

This is probably caused by a libgovirt limitation where it cannot handle multiple resources/collections of a given type with the same name. My guess here would be that the 2 ISO domains are called 'isos', and then libgovirt/virt-viewer only get to see the one which is inactive.
Is it possible to rename ISO domains to confirm this, or do they have to have a hardcoded name?

On the libgovirt side, I think we should add a OvirtCollection::resources_uuid to use the resource uuid as the hash key rather than the resource name (we need to keep OvirtCollection::resources for ovirt_collection_get_resources() as OvirtCollection need to own the returned hash table, and this will be better for performance reasons). Then we can add an ovirt_collection_get_resources_by_uuid() method to return the new hash indexed by uuid, and use this in virt-viewer. This would allow to deal with the situation we have in this bug without breaking libgovirt ABI (which might be cleaner to do at some point though ;)

(In reply to Christophe Fergeau from comment #2)
The 2 ISO domain have a different name

I'll need libgovirt version, and the output of
'REST_DEBUG=proxy remote-viewer console.vv' in the non-working case.

The debug is already attached,
The name of the ISO are:
nsimsolo_ISO and netappISO

the libgovirt version: libgovirt-0.3.4-1.fc23.x86_64

(In reply to Shira Maximov from comment #5)
> The debug is already attached,

Oops, sorry, I missed it, thanks for providing it when opening the bug :)

Ok, this would be https://bugzilla.redhat.com/show_bug.cgi?id=1313371
See in the trace
GET /ovirt-engine/api/storagedomains/9d3b50b9-2ec6-42e3-869f-83f2b75e224e/files HTTP/1.1
so it's trying to use netappISO even if it's not attached.

This is fixed upstream by https://git.fedorahosted.org/cgit/virt-viewer.git/commit/?id=0ea2a674b8a7fd51dc1a115c646fe6ff82da3e39 which is not in a release yet (so not in the fedora package either).

However, looking at that code made me realize that remote-viewer is going to use the first active ISO domain for the list of files in the foreign menu. Is it the right thing to do when there are multiple ISO domains? Or should it pick the storage domain it's going to use in a different way?

There can be multiple active in the whole setup. You'd need to match the VM's data center and the ISO domain in that data center. Then there can be only one such ISO domain active.

Shira, if you want to make sure it's the same bug as #1313371, I made a f24 scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13729845

(In reply to Michal Skrivanek from comment #8)
> There can be multiple active in the whole setup. You'd need to match the
> VM's data center and the ISO domain in that data center. Then there can be
> only one such ISO domain active.

Makes sense... Too bad /ovirt-engine/api/vms/$uuid only has a link to the VM cluster and no to the overall datacenter :( This means one more collection to take a look at.

(In reply to Christophe Fergeau from comment #2)
> On the libgovirt side, I think we should add a
> OvirtCollection::resources_uuid to use the resource uuid as the hash key
> rather than the resource name [snip]

I filed https://bugzilla.gnome.org/show_bug.cgi?id=765298 for this.

(In reply to Michal Skrivanek from comment #8)
> There can be multiple active in the whole setup. You'd need to match the
> VM's data center and the ISO domain in that data center. Then there can be
> only one such ISO domain active.

I filed https://bugzilla.gnome.org/show_bug.cgi?id=765297 for that.

I think we can close this bug now.