The code in question is http://teuf.fedorapeople.org/libgovirt-0.0.1.tar.xz and is pretty self-contained (it's not a proper library contrary to what the name implies). It's able to get the list of oVirt VMs using the REST API, and start/stop them, and connect to them if there is no tls involved.

Without non-admin access to RHEV/oVirt API (bug #783087), this feature would essentially bring admin console only.

WRT TLS stuff - all that should be needed is CA certificate that is necessary anyway to verify RHEV-M server identity, everything else can be taken from API or during connection initiation itself.

WRT URI scheme - VM name seems to be unique for whole RHEV setup (RHEV-M complains if I try to create a new VM with duplicate name in different data center) so datacenter does not have to be included in the URI.

WRT Host Subject - it's not needed for connection, when not provided, client just ignores its validation (tested on both remote-viewer and spicec fired by both CLI and XPI).

I've added a bug 807384 for Rest API to provide it nevertheless in order to achieve exactly the same level of security as clients fired up by Admin or User Portal.

For the record, I've started adding this in http://cgit.freedesktop.org/~teuf/virt-viewer/ (crappy history at the moment, history in this repo will be rewritten)

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

(In reply to comment #3)
> WRT Host Subject - it's not needed for connection, when not provided, client
> just ignores its validation (tested on both remote-viewer and spicec fired
> by both CLI and XPI).
> 

Just a clarification about this. SPICE clients will check the certificate of the machine they are connecting to is signed by the CA certificate from the oVirt/RHEV manager. Then it will use this certificate to verify it corresponds to the IP they are connecting to. However, in  some case the server IP may not match the certificate they have (for example when display port != management port). In these cases, the IP verification fails, and a host subject verification is done. If this fails, connection fails. So the host subject is required in some setups.

(In reply to comment #7)
> Just a clarification about this. SPICE clients will check the certificate of
> the machine they are connecting to is signed by the CA certificate from the
> oVirt/RHEV manager. Then it will use this certificate to verify it
> corresponds to the IP they are connecting to. However, in  some case the
> server IP may not match the certificate they have (for example when display
> port != management port).

This is still oversimplified. Client verifies if CN=COMMON_NAME in the Subject of Server Certificate is the same as common name (IP or FQDN) of server it connected to so if it the certificate says:

$ grep Subject: /path/to/server-cert.pem
Subject: O=$ORG,CN=fqdn.example.org

but it is instructed to connect to IP of the server:

$ remote-viewer --ca-file $CA spice://${IP}/?tls-port=${SPORT}

the connection will also fail - and this may happen if hostname of RHEV host is defined by FQDN.

You can see the same effect even on the Web for HTTPS sites that use CNAME and non-wildcard certificates such as https://encrypted.gogle.com/ : try to connect to the domain where the CNAME points: https://www3.l.google.com/ (YMMV depending on google's per-region DNS).

> In these cases, the IP verification fails, and a
> host subject verification is done. If this fails, connection fails. So the
> host subject is required in some setups.

Effectively, my #c3 is totally wrong and host subject is checked on _all_ setups, but some just compy with SSL/TLS good practices and it doesn't need to be provided while for others, the opposite is true.

See also: http://www.ovirt.org/wiki/Features/One_certificate-key_pair_per_NIC

Just one recent discovery of mine: you can tell REST API that you want your results filtered to see equivalent of the view in User Portal - default is what the same user sees in webadmin. It is actually necessary for most cases because if user doesn't have admin rights on setup/DC/cluster, he won't be able to actually see her VMs in administrator mode.

The distinguishing mark is HTTP header "Filter" - if set to "true" ("Filter: true"), API will send UserPortal-like info, otherwise it will be the same as webadmin.

moving to post, as Christophe did the work there and it was released in 0.5.6.

Christophe it would be nice if you could give an update if it fullfills all that RFE. And PM should decide if/when to include that feature so govirt can be added to RHEL etc.

(In reply to comment #12)

> Christophe it would be nice if you could give an update if it fullfills all
> that RFE. And PM should decide if/when to include that feature so govirt can
> be added to RHEL etc.

It's missing host subject support (supported in the REST API, but not handled by libgovirt), but this should not be very hard to add. Apart from this, this should fullfill that RFE.
I guess I should just enable that support in f19 for virt-viewer and gnome-boxes, this would solve this bug at the same time... (though this means we need to import libgovirt).

(In reply to Christophe Fergeau from comment #13)
> (In reply to comment #12)
> It's missing host subject support (supported in the REST API, but not
> handled by libgovirt), but this should not be very hard to add.

This part is fixed in libgovirt 0.1.0 (as well as a few bugs). libgovirt is imported in RHEL7 so this issue will get fixed in RHEL7 at the latest.
If we want this in 6.5, we'll need to get libgovirt added there.

moving to 6.6. The "depend-on" bug 981678 was not approved for 6.5

still missing deps, no acks, no patch merged upstream, let's move it to rhel6.7.

it would be worthwhile to get this merge first upstream and released in fedora before reaching rhel, to get wider exposure first.

(In reply to Marc-Andre Lureau from comment #24)
> still missing deps, no acks, no patch merged upstream, let's move it to
> rhel6.7.

IMO then consider to close/wontfix for el6. I guess that el6 will be phased out more slowly than el5 but by the time 6.7 is out, just a little fraction of user base will still use el6 IMO.

> 
> it would be worthwhile to get this merge first upstream and released in
> fedora before reaching rhel, to get wider exposure first.

It works quite well both in el7 and fc20 so the exposure for the interested is already wide. There are still some gaps (such as connection failure when API CA is recognized but RHEVM/SPICE CA is not) but all of them are just in libgovirt.

(In reply to David Jaša from comment #25)
> > it would be worthwhile to get this merge first upstream and released in
> > fedora before reaching rhel, to get wider exposure first.
> 
> It works quite well both in el7 and fc20 so the exposure for the interested
> is already wide. There are still some gaps (such as connection failure when
> API CA is recognized but RHEVM/SPICE CA is not) but all of them are just in
> libgovirt.

You are right, I am confusing with the ovirt foreign menu support, sorry

Test with: 
virt-viewer-2.0-2.el6.x86_64
libgovirt-0.3.2-1.el6.x86_64

Steps:
1. Prepare rhevm env and a rhel6 guest
2. wget http://rhevm.addr/ca.crt
3. remote-viewer --ovirt-ca-file=ca.crt ovirt://rhevm.addr/guest

(remote-viewer:27104): libgovirt-WARNING **: Passing a full http:// or https:// URI to ovirt_proxy_new() is deprecated

(remote-viewer:27104): libgovirt-WARNING **: Passing an URI ending in /api to ovirt_proxy_new() is deprecated

4. A dialog comes out, after input username and passwd:
username: admin@internal
passwd: XXXXXX

Click "OK" button, can connect the guest.
(remote-viewer:27104): libgovirt-DEBUG: State: complete

(remote-viewer:27104): libgovirt-DEBUG: Ticket: YGCijKeDDP9o

(remote-viewer:27104): libgovirt-DEBUG: could not find XML node 'storage_domain_state'

(remote-viewer:27104): libgovirt-WARNING **: could not find node storage_domain_state
(remote-viewer:27104): libgovirt-DEBUG: could not find XML node 'storage_domain_state'

(remote-viewer:27104): libgovirt-WARNING **: could not find node storage_domain_state
(remote-viewer:27104): libgovirt-DEBUG: could not find XML node 'storage_domain_state'

(remote-viewer:27104): libgovirt-WARNING **: could not find node storage_domain_state


5. If click "Cancel" button, get an error dialog:
"Couldn't open oVirt session: Unauthorized"

(remote-viewer:27158): libsoup-CRITICAL **: soup_auth_authenticate: assertion `username != NULL' failed

(remote-viewer:27158): libgovirt-WARNING **: Error while getting collection: Unauthorized

# echo $?
1

6. After step4, the guest is open, just one display, and no "Change CD" menu in the menu bar.
If open another display, there is a "Change CD" menu on the new display.

So, As the result,
1). There are somen libgovirt-WARNING in console out put, I think it's unnecessary.
2). Step5, if click the cancle button, should close remote-viewer normaly.
3). The "Change CD" menu should works well.

For the 3 problems, should I file bugs for them?

> 3). The "Change CD" menu should works well.

For this problem, there are two scenarios,

 - If configure an iso domain on rhevm, the result is ok.

 - If don't configure the iso domain on rhevm, display 1 will not have  "Change CD" menu. This is the scenario on comment 28.

(In reply to CongDong from comment #28)
> 1). There are somen libgovirt-WARNING in console out put, I think it's
> unnecessary.

The warnings are harmless, they are fixed by

https://git.fedorahosted.org/cgit/virt-viewer.git/commit/?id=45c6fc9b06eab5b51243d4e46e7fd08fb94766c3

and

https://git.gnome.org/browse/libgovirt/commit/?id=fb2bc505022aa82a80cd7d714c04d6cc398b6115

Feel free to file a bug for that.

> 2). Step5, if click the cancel button, should close remote-viewer normally.

Hmm, makes sense. You can file a bug, this will probably be low priority


> > 3). The "Change CD" menu should works well.
> 
> For this problem, there are two scenarios,
> 
>  - If configure an iso domain on rhevm, the result is ok.

Good, this is what this bug is fixing.

> 
>  - If don't configure the iso domain on rhevm, display 1 will not have 
> "Change CD" menu. This is the scenario on comment 28.

The bug is that additional displays get a "Change CD" menu, can you file a bug about this? I'm about to send patches fixing that upstream.

(In reply to Christophe Fergeau from comment #30)
> (In reply to CongDong from comment #28)
> > 1). There are somen libgovirt-WARNING in console out put, I think it's
> > unnecessary.
> 
> The warnings are harmless, they are fixed by
> 
> https://git.fedorahosted.org/cgit/virt-viewer.git/commit/
> ?id=45c6fc9b06eab5b51243d4e46e7fd08fb94766c3
> 
> and
> 
> https://git.gnome.org/browse/libgovirt/commit/
> ?id=fb2bc505022aa82a80cd7d714c04d6cc398b6115
> 
> Feel free to file a bug for that.

File a bug for this : Bug 1201599

> 
> > 2). Step5, if click the cancel button, should close remote-viewer normally.
> 
> Hmm, makes sense. You can file a bug, this will probably be low priority

File a bug for this: Bug 1201604

> 
> 
> > > 3). The "Change CD" menu should works well.
> > 
> > For this problem, there are two scenarios,
> > 
> >  - If configure an iso domain on rhevm, the result is ok.
> 
> Good, this is what this bug is fixing.

So, I will move this to VERIFIED.

> 
> > 
> >  - If don't configure the iso domain on rhevm, display 1 will not have 
> > "Change CD" menu. This is the scenario on comment 28.
> 
> The bug is that additional displays get a "Change CD" menu, can you file a
> bug about this? I'm about to send patches fixing that upstream.

File a bug for this: Bug 1201605

Thanks.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1322.html