GNOME Boxes is using oVirt/RHEV REST API to get the SPICE connection credentials for VMs managed by an oVirt/RHEV instance. When using the console from user portal/admin portal, if the rhev agent is running in the VM, the user is automatically logged into the desktop running into the VM (ie screen is unlocked, or GDM connection is done automatically). I'd like to support this in Boxes, but I don't think it can directly talk to the rhev agent to achieve this, so having support for it in the REST API would be nice.
I think we didn't expose the 'login' verb in the API as we were hoping spice would actually replace our SSO with spice based SSO...
David, is SPICE based SSO still in the plan?
(In reply to Andrew Cathrow from comment #3) > Does boxes have a userid & password that they could pass to the VM? Boxes needs the username/password used to connect to the oVirt web portal (to get access to the REST API). I don't know if this is what is needed.
the VmLogon command is called from user portal today. michal - you will have to close this gap via the rest api anyway for porting the gui over the api...
Merged to u/s master as http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=4b9afadae3d78cc6fdba9ce8b12738dce0715b46
This adds a new method POST with empty payload to http://${ENGINE_FQDN}/api/vms/${VMID}/logon POST /api/vms/${VMID}/logon HTTP/1.1 Host: ${ENGINE_FQDN} Content-Type: application/json Content-Length: 2 {}
Hi, can you please describe flow for this action? I have vm with rhel or windows with guest agent(if SSO under vm must be enable/disable) I run it and it's coming to stage where I need to enter credentials, on this stage I can use logon action? And if yes, it use the same credentials as engine? Thanks
(In reply to Artyom from comment #10) > Hi, can you please describe flow for this action? > I have vm with rhel or windows with guest agent(if SSO under vm must be > enable/disable) I run it and it's coming to stage where I need to enter > credentials, on this stage I can use logon action? And if yes, it use the > same credentials as engine? > Thanks Well you have to setup the VM to be able to do SSO, by installing the required plugins. On Windows you use the RHEV Guest Tools iso and install simply everything (that's the default, as far as I know) The VM of course must be connected to the same Auth Domain (e.g. Active Directory) or you have to have at least the same user/password combination when the VM is not joined to a Domain. The first stage which has to work (for testing) is that you can use the UserPortal to automatically log you in to the guest VM, when this does not work, then you have a problem with your setup already. Once that works you can now use the RestAPI to log you in on the VM as well. HTH
I see that I need rhevm-guest-agent-pam-rhev-cred rhevm-guest-agent-gdm-plugin-rhevcred packages, but I can't found anything similar for ovirt, if we have this packages also for ovirt? Thanks
(In reply to Artyom from comment #12) > I see that I need rhevm-guest-agent-pam-rhev-cred > rhevm-guest-agent-gdm-plugin-rhevcred packages, but I can't found anything > similar for ovirt, if we have this packages also for ovirt? > Thanks I don't know where you get those names from however these are not correct and I have never encountered them. You would need to install rhevm-guest-agent-gdm-plugin and rhevm-guest-agent-pam-module In case of EL5, which does not support SSO, those packages won't be present.
I take it from redhat documentation, but it old name I think. Also packages rhevm-guest-agent-gdm-plugin and rhevm-guest-agent-pam-module not included in ovirt repos. If I will take this packages from rhevm repos it will work also for ovirt 3.5?
Of course are they not in the oVirt repos... These are the RHEVM guest agents. If you want to use the upstream guest agent then you need to install: ovirt-guest-agent-common ovirt-guest-agent-gdm-plugin ovirt-guest-agent-pam-module
Returning back to ASSIGNED cause QE is currently blocked due to BZ #1141541 Please return back to ON_QA when fix is provided
A separate bug marked as a blocker is enough, the verification of this bug indeed depends on it, however there's no reason to reopen the feature (well, yet:) As per discussion in bug 1131541 the bits delivered here seem to work fine
Moved to assign because this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1141541
see comment #17 (bug 1141541)
Verified on rhevm-3.5.0-0.21.el6ev.noarch Work with internal and also with ActiveDirectory domain.
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/RHSA-2015-0158.html
*** Bug 955261 has been marked as a duplicate of this bug. ***