Mouse only usable within single application after mouse click on RHEL 7.6 as a VirtualBox guest

Latest response

Good morning folks,

I've found this thread at the VirtualBox forum. It discusses an issue that occours when you are running RHEL 7.6 as a VirtualBox guest on a Windows or Linux host system.

The issue is that you could use your mouse only within a single application window after you click in that window. The issue appears not when running RHEL 7.5 as a guest. It appears in RHEL 7.6 whether or not the VBox Guest Additions are installed. It happens with the gnome-shell and the classic gnome desktop.

Because it happens when the Guest Additions are not installed, too. I think this might be an issue with RHEL 7.6 and not entirely related to VirtualBox at all. But I do not know that for sure.

Does anyone of you encounter this issue, too? And does any one encounter this issue even on bare metal?

You could reproduce this issue in RHEL 7.6 as a VBox guest as follows:

  1. Start RHEL 7.6
  2. Open a terminal
  3. Click-drag-select text within window
  4. Try to move the terminal, click another application, or anything else outside the doesn't work.

Would be nice if the two communities could work together on this, to solve it.

Best regards,


Yes, I am seeing the same issue with RHEL 7.6 guests. The /var/log/messages file shows error lines similar to BZ 1594177. I have updated VirtualBox to 5.2.23_126798_el7 (test build) but this did not fix the problem.


I have a couple of notes about the mouse issue.

(1) As someone pointed out in this post in the thread you quoted, the kernel version makes the difference. I updated the kernel of a guest running EL7.5 using the 7.6 kernel (and no other packages updated). The guest now has the same mouse problem. Also, on a 7.6 system showing the issue, I test-installed ELRepo's kernel-ml (4.19.x) and kernel-lt (4.4.x). No problem with either kernel.

(2) On a guest exhibiting the issue, just log out and then log back in. The problem seems to go away.

In either case, the GuestAdditions are not involved.


Thanks for sharing your information here. I will try your workaround and the workaround with killing the VBoxClient with drag and drop option as mentioned in this post.

I still hope somebody is able to find the reason that is causing the problem. Sticking with the workaround is somewhat annoying.

Regards, Joerg

Thanks for the workaround. In my case, I couldn't even reach the logout button, but thankfully I have a terminal that starts up at login. For those that find themselves in a similar situation, the command 'kill -9 -1' may be useful. I should know better than to upgrade VirtualBox when I need to get work done...

This exact same behavior also happened to Fedora 28/29 with the introduction of the 4.17.0 kernel, and mysteriously went away with the 4.17.4 kernel. A workaround for Fedora was to simply log out and log back in again, and this [for me] seems to be the case with RHEL 7.6 as well. This is probably a clue for those familiar with the inner workings of relevant packages. is the ticket filed against 4.17.0 which I believe is the same underlying issue, with the same workarounds.


That is a great hint. By looking through the patches applied to kernel 4.17.4, I think I'm getting close to finding the one that actually fixed the issue. I will post more details, hopefully soon.

I picked up one patch (commit 03ae3a9caf4a59edd32b65c89c375a98ce3ea1ef) as the candidate and applied it to the centosplus kernel (kernel-plus). It is available for testing from:

It seems to fix the mouse problem according to my brief testing.

Bug reports filed:

CentOS bug 15570 and RHEL bug 1658669 (private)

Please test the patched kernel if you are able. Feedback welcome.

Hi, Could you give me some help on where to find the patched kernel for RHEL 7.6 and how to install and test it? Then there is a good change that I could take a look at it. But maybe after my vacation this weekend.

Best regards, Joerg

There is no RHEL 7.6 kernel with the patch. However, the centosplus kernel (kernel-plus) is binary compatible with the RHEL kernel. So, could you download and test-install it? It will not delete any of the existing kernels on the system.

@toracat Testing the patched kernel proved to be a few orders of magnitude more difficult than I thought it would be. I finally got there though. The good news is that did not have the mouse problem, so for me the patch fixes that problem.

The bad news is that despite managing to eventually get the kernel-plus-devel and kernel-plus-headers and all the rest installed, and reinstalling development tools that got shredded when I uninstalled previous versions, and despite it appearing that I could successfully compile the VirtualBox guest additions (from 5.2.23 test build), they don't work correctly, I am stuck with a tiny screen. What I don't understand is that copy/paste between the host and guest does work, so the guest additions are partly working.

Could the patch be interfering with screen resize events?

Interestingly, vboxsf driver is working as well, so I can share folders between my CentOS guest and Win7 host. So the only thing not working with the guest additions is the video side of things.

I'm glad to learn that the patch fixed the mouse problem in your testing.

Now, the window issue is something else. It is not due to the patch but rather is related to the kernel-plus itself. Installation of the GuestAdditions involves 3 kernel modules, vboxguest , vboxsf and vboxvideo. What I found so far is that the vboxvideo module does not build under the plus kernel. I am now investigating this.

At least we now know that the proposed patch fixes the mouse issue. When the distro kernel is patched, all should be back to normal.

I now have a new set of the centosplus kernel that does not have the vboxvideo build problem.

Download the two rpm packages there and install them (yum localinstall ... ):
(You don't need kernel-header)

Reboot to this kernel. And everything should work now.

Detailed explanation: In VirtuslBox's Makefile for vboxvideo, RHEL 7 kernels were picked up by looking for "el7.x86_64" in the name. The original plus kernel was named "" . As a result, this kernel was not regarded as a "RHEL 7.6 kernel". So in the new version I built the same kernel using "" as the package name. Now Makefile sees this as a RHEL kernel and builds the vboxvideo module.

Thank you, the new kernel works for me, I have all VirtualBox drivers working, screen scaling is working, no mouse weirdness, it's all good.

Fingers crossed these changes can make it to the update channels as soon as possible.

Yes, the whole thing is to get the patch into the RHEL kernel. The plus kernel issue was just a "sideline".

Bad news. A kernel update has just been released (kernel-3.10.0-957.5.1.el7). However, it did not have the patch.

I have updated the patched plus kernel and made it available from the same location:

If you are currently running the plus kernel, please update to this version.

Thank you very much, Akemi ! Very kind of you to provide such a convenient service for us. Much appreciated. :)



I was worried about the same problem.

The environment in which the problem occurred.

  1. Host OS - Windows 10 Pro ver 1809 OSbuild 17763.253

  2. Virtualbox 6.0.4

  3. GuestOS - CentOS7 Desktop (use xWindow)

This update fixes the issue.

Thank you for your hard work. :)

Although I was not able to run the plus kernel, yet. Thank you very much for your effort and service, Akemi!

Just a note to say no recent progress in the filed RHBZ. But it has a keyword "Z-Stream", so I expect the patch will appear in a future 7.6 kernel.

Is there some concern over the patch that is delaying its introduction into the kernel? This issue was pending as a priority for quite a few weeks and failed to make the latest kernel. Seems strange.

This may sound strange but our bug report is being processed faster than the average. I submitted it on 2018-12-12 and the patch was committed on kernel-3.10.0-984.el7 on 2018-12-20. So, it will be in the EL 7.7 kernel. That was "super fast". Then it was added to the "ZStream" on 2019-01-02, meaning the patch will be ported to the EL 7.6 kernel series.

To give you an example for comparison, a kernel bug report with a known patch from was submitted on 2018-08-07 (it was EL 7.5 at that time). The patch was committed on kernel-3.10.0-979.el7 on 2018-12-17 (so, will be in EL 7.7). It does not have the keyword "ZStream". Therefore this one may not be fixed in the 7.6 kernel. I would say the progress of this example is rather "typical" for non-critical bug fixes.

Hello Jörg Kastning, has been created to show the progress of this issue.


Jan Gerrit

Thank you for that information. I'm following the solution article, now. :-)

Hey Jörg, having followed this discussion for some time now ... what about the most easy way to troubleshoot the vbox issues ? Just get rid of ORACLE VirtualBox and Windows - who (still) uses ORACLE/Windows these days ? :D :D - and replace the host with a Linux distro. CentOS, Fedora
or RHEL comes to my mind. Fire up your virtual machines with KVM/QEMU, these tools work as expected. You can use Cockpit to manage, and Virt-Manager to access your machines via a GUI.

Included humoristic points of view are intended !

Cheers :)

Hi Christian,
Would I be able to run Windows guests in KVM/QEMU? Because I still have to use Windows from time to time. :-/

Could you point my nose to some good documentation about this topic?


Hi Jörg,

Of course you can ... simply install Windows in a KVM VM - do it right the way you install other virtual systems. Create a virtual disk, inject the Windows DVD ISO, boot from the ISO and, install Windows. :)


Hi Christian,

For those that are less experienced using KVM/Qemu. Virtualbox or VMWare Workstation all alternatives to run on Windows. The issues are caused by the RHEL 7.6 packaged kernel not by Virtualbox ( :) this time :) ).


Jan Gerrit Kootstra

I know Jan Gerrit ... :) What matters is the combination here - I've been using VirtualBox some
years ago too and I realized that I always found bugs and issues - some of them less and some
of them more impacting the user experience in a negative way. After switching to KVM, it was
no longer the case and that's why I recommend it. But of course, the production machine has
to run a Linux system. Those who prefer to run Windows have to stick with vbox or VMware ...

I am running RHEL 7.6 in a KVM virtual machine on a fedora 29 workstation host and all I can
say is that everything works correctly, right as it should be and without any noticeable issues.


Hi Jörg,

Yesterday you asked me to "point your nose" to some good documentation ... well, there's tons of stuff you can find on the
internet. I usually see everything from the customer's point of view and so I thought about the best way to get you started.

Although it would be easy to just point you to the QEMU website, I think it might overwhelm you. Like most users you have
started exploring virtualization with VirtualBox. Moving to KVM will be a bit of a learning curve, but once you've figured out
everything, you will never look back. You get many more configuration options, many more features and on top of that way
better performance. I suggest that you start with virt-manager (a GUI for libvirt/qemu) to explore and try out how all works.

Please follow these instructions - first remove VirtualBox including all configuration files completely and restart the system.
Then install these packages to get the complete virtualization toolset, this is valid for CentOS 7.6, Fedora 29 and RHEL 7.6.
Enable the EPEL repository - in case you haven't done it already - to gain access to dkms (dynamic kernel module support).
To avoid pulling in the wrong dependency kernel-debug-devel, I recommend to install the kernel-devel package beforehand.

sudo yum install kernel-devel
sudo yum install kernel-headers
sudo yum install dkms
sudo yum install libguestfs-tools libvirt qemu virt-install virt-manager

Later on you can install and use Cockpit and the necessary plugins to manage the machines from within a web browser GUI.
Now you have everything you need - reboot the system and start exploring your new environment. Hope I could help you. :)


For your convenience Jörg, here are some additional configuration recommendations. :)
Add yourself (user) to the relevant virtualization groups and configure the ACL settings.

sudo usermod -a <your-user-name> -G libvirt
sudo usermod -a <your-user-name> -G qemu

sudo setfacl -R -m u:<your-user-name>:rwx /path-to-virtual-disks
sudo setfacl -R -m u:qemu:rwx /path-to-virtual-disks

The virtual machines run as qemu user and if you want to launch them with GNOME Boxes,
you need to create a new file in your /home/user/.config/gnome-boxes/sources directory.

sudo vi /home/user/.config/gnome-boxes/sources/'QEMU System' Insert this :

name=QEMU System


And Jörg, if you want to manage your environment via Cockpit ... follow these steps :

sudo yum install cockpit cockpit-machines
sudo systemctl enable --now cockpit.socket

That's all for today, enjoy the new virtualization solution, I wish you a nice weekend. :)


Hi Jörg,

No feedback ? Everything clear ? If you have questions or need further assistance ... please just feel free to ask. :)


Hi Christian,
Sorry for my late response. Your posts are absolutely helpful and I'm sure I'll be able to setup the configuration by myself.

At the moment I just don't have the time to do so because I have to work on quite some other topics.

Regardless of my personal choice I hope the bug in the kernel will be fixed anyway. After all VirtualBox is a nice piece of software, too.


I hope so too, Jörg ... experience shows that the developers take important bugs seriously and so,
I assume it will be solved in one of the next kernel updates ... if they consider it to be important. :)


According to a recent post in the referenced VirtualBox forum thread, the RHEL kernel with the fix is scheduled to be released in mid March.

Thanks for the information, Akemi ! :)

Jörg asked, if someone has this issue on bare metal. I have several identical hosts and on one of them I see this bug every time after rebooting. For me the workaround was switching to a text terminal and back to graphics mode or by restarting the X server. And I have seen it on the other hosts too but very occasionally.

I'm only aware of this issue in the context of a virtualized environment, and even then, specific to VirtualBox only.

I can confirm it doesn't happen within the vmplayer! But as I said it happens on physical hosts too. And I can confirm that package is fixing the problem for them too.

Hi everybody ! :)

There's one thing worth mentioning : All users who install packages from external sources have to be aware that they are about
to loose official support from Red Hat when it comes to issues being related to those software packages - especially the kernel !

The kernel is one of the most important components and, it is definitely recommended to stick with the original Red Hat kernel
on production systems generally, not only in enterprise environments. If one installs external kernels, they are doing it on their
own risk.


I have two notes.

One is that, yes, the bug can be reproduced without VirtualBox. This was confirmed by a Red Hat engineer.

Second is about the external kernels. Right, they are not supported by Red Hat. In this particular case, the plus kernel is offered as a temporary solution until the official RHEL kernel with the patch gets released. Hopefully it will happen very soon.

Big news!

kernel-3.10.0-957.10.1.el7 has just been released. I confirm this version has the patch that fixes the mouse issue.

[EDIT] To be more precise, the source code has been released. Please wait for the announcement for the actual release of the binary packages.

Thank you very much for this "hot" update information, Akemi ! Great news indeed ... Have a nice day ! :)


I did a yum update but after the kernel was still 3.10.0-957.5.1. Is there something additional that needs to be done?

Just checked. It has not been announced yet, so may take a while before yum can find it.

Just saw your update in the BZ. I've asked for a moderator to unlock the thread over on as well so that we can post updates when this is finally available.

Hi David,

Thanks for doing that. I did send a PM to @socratis yesterday but he is apparently offline for a while. As soon as it's unlocked, I will add my followup note.