Few clarifications:

* in remote-viewer and spicy, the only way to pass a combo to the guest is to add shift key to is, like alt+shift+sysrq+s. Even then, the combo is passed to both client and guest

* old spice-client can issue the combos using its now-deprecated sticky alt feature

I don't think we can intercept sysrq combinations, so we'd need a send-key menu, or sticky keys to implement this...

(In reply to comment #1)
> Few clarifications:
> 
> * in remote-viewer and spicy, the only way to pass a combo to the guest is
> to add shift key to is, like alt+shift+sysrq+s. Even then, the combo is
> passed to both client and guest


lowering severity since it is not critical for the normal usage, no crash/leak etc either. Furthermore you found a solution to the issue.

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.

We could add a menu item to the "Send key" menu, but that's only really feasible if we want to support a small number of these magic sysrq combinations.  if we had to add an item for each possible magic sysrq combination, that menu would get rather huge. Which combinations do we want to support?

On the other hand, the workaround mentioned above (including Shift) doesn't appear to work here (with a Fedora 19 host)

Iirc virtualbox handles that by having scroll lock (iirc)  act as alt when pressed in a key combination.
spicec used to handle that using a sticky alt (hold alt for 5 seconds, release it, and then press the rest of the key combination).

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.

Otoh, if you disable sysrq on client side, it is working. Thus I would consider this as notabug, as this is certainly not a good idea to try a sysrq on both client and guest at the same time. Somebody disagree with that?

(In reply to Marc-Andre Lureau from comment #9)
> Otoh, if you disable sysrq on client side, it is working. Thus I would
> consider this as notabug, as this is certainly not a good idea to try a
> sysrq on both client and guest at the same time. Somebody disagree with that?

Sure.

Would it make sense to have keyboard shortcuts for sysrq key combos similar to ctrl-alt-end for ctrl-alt-del - so that user can press e.g. alt+pause/break+<key>? If so, we could transform the bug so such a RFE.

imho, someone doing sysrq with a guest should know that it is intercepted by client first. I don't see the need for extra shortcuts for something that is very much only for hackers (I even never use sysrq myself!).

closing as worksforme, feel free to reopen if you have valid reasons..

(In reply to Marc-Andre Lureau from comment #9)
> Otoh, if you disable sysrq on client side, it is working.

Fwiw, no idea how you disable sysrq on client side, this would probably deserve some documentation, or a kb article...

(In reply to David Jaša from comment #10)
> Would it make sense to have keyboard shortcuts for sysrq key combos similar
> to ctrl-alt-end for ctrl-alt-del - so that user can press e.g.
> alt+pause/break+<key>? If so, we could transform the bug so such a RFE.

Imo it would be nice to have.

I just google:

http://en.wikipedia.org/wiki/Magic_SysRq_key

There are also alternate way to do sysrq,

I disagree having keymaps/translation by default, we should have 1-1 whenever possible. In this case, the combination works when the client side is configured to permit it.

(In reply to Marc-Andre Lureau from comment #15)
> I just google:
> 
> http://en.wikipedia.org/wiki/Magic_SysRq_key
> 

For anyone reading this bug

https://en.wikipedia.org/wiki/Magic_SysRq_key#Configuration

"The feature is controlled both by a compile-time option in the kernel configuration, CONFIG_MAGIC_SYSRQ, and a sysctl kernel parameter, kernel.sysrq. To be able to use this functionality the CONFIG_MAGIC_SYSRQ option has to be enabled at kernel compile time.

The SysRq key can be disabled with the following command:

echo 0 > /proc/sys/kernel/sysrq

To re-enable:

echo 1 > /proc/sys/kernel/sysrq"

> There are also alternate way to do sysrq,
> 
> I disagree having keymaps/translation by default, we should have 1-1
> whenever possible. In this case, the combination works when the client side
> is configured to permit it.

Except that this cannot be configured by regular users. And if this is our 'official' answer for people asking how to achieve that, this imo should be documented.