Bug 1060573

Created attachment 858287 [details]
working shared spice console

I searched the engine coding for the initiator of that call. It might be inside SetVmTicketVDSCommand.java. The disconnect action is hard coded:

public class SetVmTicketVDSCommand<P extends SetVmTicketVDSCommandParameters> extends VdsBrokerCommand<P> {
    private Guid mVmId = Guid.Empty;
    private String mTicket;
    private int mValidTime; // in seconds
    private String connectionAction = "disconnect";
...

My tests show that if will be an simple and save way to change the default value of connectionAction to "keep". As long as we do not modify libvirt XML to allow crashy session sharing spice server will only allow one single session. The current behaviour won't be changed and we have the possibility to enable shared spice consoles using hooks.

Setting target release to current version for consideration and review. please
do not push non-RFE bugs to an undefined target release to make sure bugs are
reviewed for relevancy, fix, closure, etc.

This is an automated message.
Re-targeting all non-blocker bugs still open on 3.4.0 to 3.4.1.

did you try to use before_vm_set_ticket/after_vm_set_ticket hook instead of vm lifecycle-related hook?

Hm, 

in first instance the before_vm_start hook is to enable shared sessions in QEMU. If it is not available than QEMU will disable shared SPICE sessions automatically. Without this hook we can do what we want whereever it may be, shared sessions will not work.

Everything fine until here: Now to the task to issue new tickets with option "connected=keep". From my understanding this is an attribute of the domain.xml (http://libvirt.org/formatdomain.html) and therefore must be set in the start_vm hook. This parameters will be passed to qemu start command line (and therefore cannot be altered afterwards).

Without any reference scripts for the before_vm_set_ticket/after_vm_set_ticket hook I have no real idea what I can do there. Maybe you can enlighten me.

check vm.py, setTicket(). We pull the graphics element from libvirt, update expiration time and password and set it back using updateDeviceFlags(). I believe this should work for all attributes, you could modify it in before_vm_se_ticket.
I didn't try but it should work…

I'm not sure about the actual support in SPICE though, IIRC it was experimental and not sure if it's exposed. Libvirt docs seems to indicate it allows concurrent access only for VNC using the "sharePolicy" attribute

It would make sense to support sharePolicy properly at least for VNC

This is an automated message.
This Bugzilla report has been opened on a version which is not maintained anymore.
Please check if this bug is still relevant in oVirt 3.5.4.
If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution)
If it's an RFE please update the version to 4.0 if still relevant.

This is an automated message.
This Bugzilla report has been opened on a version which is not maintained
anymore.
Please check if this bug is still relevant in oVirt 3.5.4 and reopen if still
an issue.

This bug is flagged for 3.6, yet the milestone is for 4.0 version, therefore the milestone has been reset.
Please set the correct milestone or add the flag.

Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.

Milan, can you take a look, it should really be fairly simple to just not overwrite existing stuff

I think simply not overwriting the attribute in Vdsm if already set is a reasonable solution.  See the proposed patch.

Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.

Not yet solved, more patches needed.

We can approach the fix in several ways:

- The simplest way is to stop sending disconnect parameter from Engine on graphics ticket update.  This should probably cause no change in the current behavior and would allow setting the parameter in a Vdsm hook as described at the beginning of this bug report.
- A better way would be, in addition to the previous, to add a new API parameter to the create path and introduce a vdc option in Engine to provide the value of that parameter.  Then the Vdsm hook wouldn't be needed.  However SPICE_DEBUG_ALLOW_MC environment variable must be set for QEMU before it is started in order to make connected="keep" actually working.  This means using qemu:commandline in domain XML and thus may not be very welcome in Vdsm.
- Maybe the best way would be, in addition to the previous, to permit setting this option per each VM.  This would require the same changes in Vdsm as the approach above and some more changes in Engine.

In any case, SPICE shared sessions seem to be somewhat experimental feature and we should be cautious when modifying the current behavior. Unless we decide for the simplest way of not sending disconnect parameter from Engine at all, we must coordinate changes in Engine and Vdsm and should think about possible implications a bit more.

We decided to go the simple way: Engine shouldn't send the disconnect parameter anymore and the user can set `connected' attribute in Vdsm hooks. We may think about better support of SPICE shared sessions once libvirt+QEMU support them properly.

*** Bug 1342479 has been marked as a duplicate of this bug. ***

Verified on rhevm-4.0.2-0.2.rc1.el7ev.noarch with host: vdsm-4.18.4-2.el7ev.x86_64.

Added the vdsm hook as per description and restarted vdsm.
Created a vm with spice and started the vm.
Was able to open several consoles with shared session after the connected='keep' flag was added to vm's xml graphics entity as expected.

oVirt 4.0.0 has been released, closing current release.