Bug 1020408

Summary: PRD34 - [RFE] CFME would like to have RHEV emit events for Remote Console Connect
Product: Red Hat Enterprise Virtualization Manager Reporter: Greg Blomquist <gblomqui>
Component: ovirt-engineAssignee: Oved Ourfali <oourfali>
Status: CLOSED ERRATA QA Contact: meital avital <mavital>
Severity: medium Docs Contact:
Priority: high    
Version: 3.2.0CC: acathrow, ecohen, gblomqui, gklein, iheim, lbopf, lpeer, mavital, michal.skrivanek, oourfali, Rhev-m-bugs, sbonazzo, sherold, yeylon
Target Milestone: ---Keywords: FutureFeature, Improvement
Target Release: 3.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: virt
Fixed In Version: ovirt-3.4.0-beta2 Doc Type: Enhancement
Doc Text:
Red Hat Enterprise Virtualization Manager now raises events when a user connects or disconnects from a virtual machine console session.
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-09 15:00:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1009120, 1078909, 1142926    

Description Greg Blomquist 2013-10-17 15:35:57 UTC
Description of problem:

CFME catches an event from VMWare when users connect via the remote console.  CFME would like to catch a similar event from RHEV.

In talking with Itamar, he described the two instances where an event could be raised as:

1) setvmticket:  when the user clicks the console button in the web UI
2) clientIP field changed:  when the user actually connects

Comment 1 Oved Ourfali 2013-12-08 07:20:53 UTC
Will add a SetVmTicket event, which will be triggered, as mentioned in the bug description, when the user clicks the console button in the web UI.

Comment 2 Michal Skrivanek 2013-12-08 07:42:46 UTC
bear in mind setVmTicket doesn't mean the console is actually opened. You can ask for the ticket but then simply do not open the viewer
Is that good enough?

Comment 3 Greg Blomquist 2013-12-09 14:51:46 UTC
Michal and Oved,

I think that setVmTicket might be enough.  But, I'd like to understand a little more.

Does the user actually take two separate actions?  For instance, 1) request vm ticket, 2) connect to the console?  Or, is this all triggered from the same action in the UI?

If it's all the same action, then I think that setVmTicket is fine.

Comment 4 Michal Skrivanek 2013-12-09 15:47:13 UTC
in UI it's a single action invoking two different things, setVmTicket and then the actual console invocation(or .vv file download expecting user to associate and launch the application with it). In normal circumstances it should always happen together, but it may not if you do this programmatically or if the app launch phase fails

Comment 5 Greg Blomquist 2013-12-09 17:01:50 UTC
That makes sense.  SetVmTicket should be fine, then.

Thanks!

Comment 6 Itamar Heim 2013-12-09 22:30:54 UTC
SetVmTicket is "user requested to access the VM" and we set the ticket.
user may or may not actually connect to the console after that (which can be detected based on the ClientIP field changing iirc)

Comment 7 Oved Ourfali 2013-12-10 06:07:33 UTC
If that's more accurate then I can add a new event for a client IP change, specifying that a user has connected (assuming the address isn't empty).

Comment 8 Michal Skrivanek 2013-12-10 07:04:46 UTC
(In reply to Oved Ourfali from comment #7)
well, it's more accurate but not really reliable as the guest may not be running the guest agent. The ticket should be good enough as long as it's clear what it means (requested access vs actual connect)
Or maybe have two events? Not sure if it's of any use in CFME though

Comment 9 Oved Ourfali 2013-12-10 07:22:55 UTC
I'll just add both of them.
The SetVmTicket log entry today says: user admin@internal initiated console session for VM new_vm1

The new one will say that the user is connected / disconnected.
That way we're covered in all the cases, and CFME can use either both of them, or just one of them.

Comment 12 errata-xmlrpc 2014-06-09 15:00:21 UTC
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.

http://rhn.redhat.com/errata/RHSA-2014-0506.html