Bug 806925 - RFE: add new URI scheme (and possibly new command invocation) to connect to RHEV/oVirt-managed VMs
RFE: add new URI scheme (and possibly new command invocation) to connect to R...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-viewer (Show other bugs)
6.3
Unspecified Unspecified
medium Severity medium
: beta
: 6.4
Assigned To: Christophe Fergeau
Virtualization Bugs
Laura Novich
: FutureFeature
Depends On: 783087 807384 867513 981678 1179477
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-26 10:05 EDT by David Jaša
Modified: 2016-01-26 20:54 EST (History)
16 users (show)

See Also:
Fixed In Version: virt-viewer-2.0-1.el6
Doc Type: Release Note
Doc Text:
virt-viewer supports direct access to RHEV-H virtual machines It is now possible to use the Red Hat Enterprise Virtualization Hypervisor to access virtual machines directly using virt-viewer.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-07-22 02:30:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Jaša 2012-03-26 10:05:06 EDT
Description of problem:
similarly as virt-viewer connects to libvirt-managed machines without needing to know underlying configuration details via:
virt-viewer -c hypervisor+transport://user@host/connection vm_name

it would be nice to be able to connect to RHEV-managed VMs via URI scheme tailored for RHEV/oVirt concepts. It could look like:
rhev-viewer -c rhev://user@rhevm_host/datacenter vm_name
or for example:
rhev-viewer -c ovirt://user@ovirt_host/ uuid:VM_UUID

Version-Release number of selected component (if applicable):
0.5.x

CCing Christophe as he has some C code that will bring the same functionality to Gnome Boxes.
Comment 1 Christophe Fergeau 2012-03-26 10:12:27 EDT
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.
Comment 2 David Jaša 2012-03-26 13:48:34 EDT
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.
Comment 3 David Jaša 2012-03-27 12:09:02 EDT
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.
Comment 4 Christophe Fergeau 2012-05-04 03:37:49 EDT
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)
Comment 5 RHEL Product and Program Management 2012-07-10 02:58:54 EDT
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.
Comment 6 RHEL Product and Program Management 2012-07-10 22:00:43 EDT
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.
Comment 7 Christophe Fergeau 2012-07-13 10:38:10 EDT
(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.
Comment 8 David Jaša 2012-07-13 11:05:22 EDT
(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
Comment 11 David Jaša 2012-10-17 11:40:21 EDT
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.
Comment 12 Marc-Andre Lureau 2013-05-09 18:36:18 EDT
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.
Comment 13 Christophe Fergeau 2013-05-13 11:18:13 EDT
(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).
Comment 15 Christophe Fergeau 2013-06-11 11:15:46 EDT
(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.
Comment 22 David Blechter 2013-07-29 12:37:02 EDT
moving to 6.6. The "depend-on" bug 981678 was not approved for 6.5
Comment 24 Marc-Andre Lureau 2014-06-18 13:43:43 EDT
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.
Comment 25 David Jaša 2014-06-18 16:43:13 EDT
(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.
Comment 26 Marc-Andre Lureau 2014-06-18 16:47:40 EDT
(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
Comment 28 CongDong 2015-03-10 23:14:25 EDT
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?
Comment 29 CongDong 2015-03-11 07:01:31 EDT
> 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.
Comment 30 Christophe Fergeau 2015-03-12 11:54:23 EDT
(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.
Comment 31 CongDong 2015-03-12 23:26:21 EDT
(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.
Comment 36 errata-xmlrpc 2015-07-22 02:30:02 EDT
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

Note You need to log in before you can comment on or make changes to this bug.