Virtualbox 7.1.10 on RHEL9/Rocky9 fails to auto resize VM display

[pjxt]

Virtualbox 7.1.10 (with or without update to 7.1.10 Guest Additions) on fully updated/patched RHEL9/Rocky9 fails to auto adjust guest VM (ArchLinux) display size when resizing or maximizing window. Previous 7.1.8 (with 7.1.* guest additions) handled this correctly.

Applied after full 'dnf update':
VirtualBox-7.1-7.1.10_169112_el9-1.x86_64.rpm

Applied after full 'pacman -Syu':
VBoxGuestAdditions_7.1.10.iso

[eworm-de]

I guess what you see is not Virtualbox's fault. Latest Mesa dropped support for gallium-xa, which is essential for Xorg's VMware driver. See details in freedesktop issue tracker:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-vmware/-/issues/12

Thus we dropped the driver from Arch repository.

You can restore functionality for your guest by switching the graphics controller to "VBoxSVGA".

[galitsyn-oracle]

Hi @pjxt and @eworm-de,

Please note that for modern (x86_64) Linux guests it is recommended to use VMSVGA graphics. Other graphic adapters are for old/legacy Linux distributions when they not yet had suitable VMSVGA graphics support.

@pjxt, there might be multiple reasons why resizing would not work. What is the guest's Desktop Environment? Could you please show ps -AF | grep -i vbox output?

[eworm-de]

Please note that for modern (x86_64) Linux guests it is recommended to use VMSVGA graphics. Other graphic adapters are for old/legacy Linux distributions when they not yet had suitable VMSVGA graphics support.

Recommended or not... The driver is no longer available with recent Mesa.

@pjxt, there might be multiple reasons why resizing would not work. What is the guest's Desktop Environment? Could you please show ps -AF | grep -i vbox output?

Arch Linux was explicitly mentioned, so pretty sure I gave the correct hints. No need to diagnose further.

[galitsyn-oracle]

Just to clarify. Suggesting to use VBoxSVGA adapter is misleading. VMSVGA should be used for modern x86_64 Linux distributions as mentioned above. When VMSVGA is used for modern Linux guests, the driver mentioned above is not used for guest screen resize.

[eworm-de]

Arch Linux is a modern distribution. It has recent mesa, and xf86-video-vmware is no longer compatible with that and has been dropped.

As far as I know that driver is required for guest screen resize when using VMSVGA. If that's not true... How is it supposed to work?

[galitsyn-oracle]

It was a case in the past when VBoxClient process would use VMWARE_CTRL extension for X11 in order to trigger guest screen resize. Nowadays, VBoxDRMClient process is responsible for this part. It injects resize data directly into guest kernel's DRM stack using vmwgfx specific IOCTL and bypassing X11.

[eworm-de]

Looks like this does not work as expected. I will have to check if that process is running, or what else could go wrong.

[eworm-de]

Could you please show ps -AF | grep -i vbox output?

root         705       1  0 88353  3012   3 22:26 ?        00:00:00 /usr/bin/VBoxDRMClient
root         741       1  0 73226  4856   1 22:26 ?        00:00:00 /usr/bin/VBoxService -f
nepu        1288       1  0  4288  1380   3 22:26 ?        00:00:00 /usr/bin/VBoxClient --clipboard
nepu        1290    1288  0 53987  4552   3 22:26 ?        00:00:00 /usr/bin/VBoxClient --clipboard
nepu        1299       1  0  4288  1372   3 22:26 ?        00:00:00 /usr/bin/VBoxClient --seamless
nepu        1300    1299  0 53827  3348   0 22:26 ?        00:00:00 /usr/bin/VBoxClient --seamless
nepu        1326       1  0  4288  1572   0 22:26 ?        00:00:00 /usr/bin/VBoxClient --draganddrop
nepu        1327    1326  0 53956  3452   0 22:26 ?        00:00:00 /usr/bin/VBoxClient --draganddrop
nepu        1358       1  0  4288  1444   3 22:26 ?        00:00:00 /usr/bin/VBoxClient --vmsvga-session
nepu        1359    1358  0 53873  3840   1 22:26 ?        00:00:00 /usr/bin/VBoxClient --vmsvga-session

[eworm-de]

This is found in journal for vboxdrmclient.service:

Aug 20 22:34:19 nepu-d5a70936 systemd[1]: Started VirtualBox Guest VMSVGA resize client.
Aug 20 22:34:19 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:19.649910 main     VBoxClient 7.2.0 r170228 (verbosity: 0) linux.amd64 (Aug 14 2025 19:02:36) release log
Aug 20 22:34:19 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:19.649911 main     Log opened 2025-08-20T20:34:19.649906000Z
Aug 20 22:34:19 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:19.651838 main     OS Product: Linux
Aug 20 22:34:19 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:19.652080 main     OS Release: 6.15.8-arch1-2
Aug 20 22:34:19 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:19.652339 main     OS Version: #1 SMP PREEMPT_DYNAMIC Tue, 29 Jul 2025 15:05:00 +0000
Aug 20 22:34:19 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:19.652863 main     Executable: /usr/bin/VBoxDRMClient
Aug 20 22:34:19 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:19.652864 main     Process ID: 4241
Aug 20 22:34:19 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:19.652864 main     Package type: LINUX_64BITS_GENERIC (OSE)
Aug 20 22:34:19 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:19.654458 main     VBoxDRMClient: found compatible device: /dev/dri/renderD128
Aug 20 22:34:19 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:19.656720 main     VBoxDRMClient: starting deferred resize events delivery
Aug 20 22:34:19 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:19.659014 main     VBoxDRMClient: IPC server socket access granted to all users
Aug 20 22:34:19 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:19.908588 Timer    VBoxDRMClient: push screen layout data of 1 display(s) to DRM stack, fPartialLayout=false, rc=VINF_SUCCESS
Aug 20 22:34:21 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:21.198452 IpcCLT-4717 VBoxDRMClient: IPC client connection started
Aug 20 22:34:23 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:23.411537 Timer    VBoxDRMClient: push screen layout data of 1 display(s) to DRM stack, fPartialLayout=false, rc=VINF_SUCCESS
Aug 20 22:34:27 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:27.659326 Timer    VBoxDRMClient: push screen layout data of 1 display(s) to DRM stack, fPartialLayout=false, rc=VINF_SUCCESS
Aug 20 22:34:29 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:29.658703 Timer    VBoxDRMClient: push screen layout data of 1 display(s) to DRM stack, fPartialLayout=false, rc=VINF_SUCCESS
Aug 20 22:34:30 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:30.658954 Timer    VBoxDRMClient: push screen layout data of 1 display(s) to DRM stack, fPartialLayout=false, rc=VINF_SUCCESS
Aug 20 22:34:31 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:31.657638 Timer    VBoxDRMClient: push screen layout data of 1 display(s) to DRM stack, fPartialLayout=false, rc=VINF_SUCCESS
Aug 20 22:34:33 nepu-d5a70936 VBoxDRMClient[4241]: 20:34:33.907167 Timer    VBoxDRMClient: push screen layout data of 1 display(s) to DRM stack, fPartialLayout=false, rc=VINF_SUCCESS

... and the display does not resize.

[galitsyn-oracle]

@eworm-de ,

We do not providing vboxdrmclient.service with the official Guest Additions. Having these messages in system log also looks suspicious. What is the output of sudo rcvboxadd status-kernel? I also noticed that VBoxService is running with non-standard command line flags. If you restart it manually, there is a chance that VBoxDRMClient is no longer DRM master and its resize requests ignored by kernel.

Anyways, is the issue reproducible with the official Guest Additions (downloaded from virtualbox.org) after fresh guest start?

[eworm-de]

I will have the check with some time available and a real keyboard under my fingers.

BTW, we should update the topic to clarify this is a guest issue.

[eworm-de]

We do not providing vboxdrmclient.service with the official Guest Additions.

Ah, yeah... I added that in the Arch Linux package. It's correct that the services in running as root?
How do the guest utils start that when installed from ISO?

Having these messages in system log also looks suspicious.

Hmm, what should the output look like?

What is the output of sudo rcvboxadd status-kernel?

We do not install kernel modules but use the ones from linux. That should be fine for guests, no?

I also noticed that VBoxService is running with non-standard command line flags.

The service is started from (mostly) unmodified client script.

If you restart it manually, there is a chance that VBoxDRMClient is no longer DRM master and its resize requests ignored by kernel.

The service is started at system startup... So again, how is it supposed to be started correctly? I would like to have processes running as systemd services, not rogue ones.

Anyways, is the issue reproducible with the official Guest Additions (downloaded from virtualbox.org) after fresh guest start?

I removed our package, and installed from official Guest Additions ISO, including kernel modules. No luck... Still does not resize.

[galitsyn-oracle]

@eworm-de,

If you modify Guest Additions, you are on your own. Let me try to answer the questions though.

Hmm, what should the output look like?

Having these messages in dmesg is a sign of that in-kernel vboxguest.ko is loaded instead of officially shipped one (as you confirmed). Combination of in-kernel vboxguest.ko + the rest of official Guest Additions might seem to work, but is not recommended to have (in-kernel module is lacking some functionality which Additions would expect to have), so please do not do that.

Ah, yeah... I added that in the Arch Linux package. It's correct that the services in running as root?
How do the guest utils start that when installed from ISO?

Please don't do that as well. Yes, VBoxDRMClient is expected to be ran as root. However, it supposed to be started by VBoxService process which, in turn, is integrated with systemd. Having VBoxDRMClient as a separate systemd service will break things such as Guest Additions upgrade without need to reboot a guest. So, the usual ptocedure is (1) VBoxService is started as a systemd service on system boot, (2) VBoxService then starts VBoxDRMClient (at this point screen resize should already work, for example when you are on graphical login screen) and (3) when user logs-in VBoxClient services are started in context of user session.

I removed our package, and installed from official Guest Additions ISO, including kernel modules. No luck... Still does not resize.

Have you rebooted guest afterwards?

[eworm-de]

If you modify Guest Additions, you are on your own. Let me try to answer the questions though.

Well, we want to provide a way that allows to install updates for everything to be up-to-date, that includes the guest additions. But yeah, understood. Still trying to solve this.

Having these messages in dmesg is a sign of that in-kernel vboxguest.ko is loaded instead of officially shipped one (as you confirmed). Combination of in-kernel vboxguest.ko + the rest of official Guest Additions might seem to work, but is not recommended to have (in-kernel module is lacking some functionality which Additions would expect to have), so please do not do that.

I built and installed the modules shipped with upstream virtualbox:

# cat /sys/module/vbox*/version
7.2.0 r170228
7.2.0 r170228
7.2.0 r170228

Should be ok, no?

Please don't do that as well. Yes, VBoxDRMClient is expected to be ran as root. However, it supposed to be started by VBoxService process which, in turn, is integrated with systemd. Having VBoxDRMClient as a separate systemd service will break things such as Guest Additions upgrade without need to reboot a guest.

I dropped the extra service file. Indeed VBoxDRMClient is started by VBoxService now.

Still... What are you referring to with "is integrated with systemd"? The Virtualbox source tarball does not ship a systemd service file, no? (Again would have to check what happens when installing from ISO.)

So, the usual ptocedure is (1) VBoxService is started as a systemd service on system boot, (2) VBoxService then starts VBoxDRMClient (at this point screen resize should already work, for example when you are on graphical login screen) and (3) when user logs-in VBoxClient services are started in context of user session.

All this should be met now.

● vboxservice.service - VirtualBox Guest Service
     Loaded: loaded (/usr/lib/systemd/system/vboxservice.service; enabled; preset: disabled)
     Active: active (running) since Mon 2025-09-01 13:49:38 CEST; 22min ago
 Invocation: 54e3438ad95b447fb4d89de287d32fed
    Process: 701 ExecStartPre=/usr/bin/modprobe vboxguest (code=exited, status=0/SUCCESS)
    Process: 711 ExecStartPre=/usr/bin/modprobe vboxvideo (code=exited, status=0/SUCCESS)
    Process: 718 ExecStartPre=/usr/bin/modprobe vboxsf (code=exited, status=0/SUCCESS)
   Main PID: 728 (VBoxService)
      Tasks: 15 (limit: 4405)
     Memory: 3.5M (peak: 4.5M)
        CPU: 1.257s
     CGroup: /system.slice/vboxservice.service
             ├─728 /usr/bin/VBoxService -f
             └─741 /usr/bin/VBoxDRMClient

This is what I have in journal now:

Sep 01 13:49:38 nepu-0cb25072 systemd[1]: Starting VirtualBox Guest Service...
Sep 01 13:49:38 nepu-0cb25072 systemd[1]: Started VirtualBox Guest Service.
Sep 01 13:49:38 nepu-0cb25072 VBoxService[728]: 11:49:38.097619 main     VBoxService 7.2.0 r170228 (verbosity: 0) linux.amd64 (Sep  1 2025 11:27:36) release log
Sep 01 13:49:38 nepu-0cb25072 VBoxService[728]: 11:49:38.097620 main     Log opened 2025-09-01T11:49:38.097616000Z
Sep 01 13:49:38 nepu-0cb25072 VBoxService[728]: 11:49:38.097686 main     OS Product: Linux
Sep 01 13:49:38 nepu-0cb25072 VBoxService[728]: 11:49:38.097702 main     OS Release: 6.16.4-arch1-1
Sep 01 13:49:38 nepu-0cb25072 VBoxService[728]: 11:49:38.097716 main     OS Version: #1 SMP PREEMPT_DYNAMIC Thu, 28 Aug 2025 19:49:53 +0000
Sep 01 13:49:38 nepu-0cb25072 VBoxService[728]: 11:49:38.097729 main     Executable: /usr/bin/VBoxService
Sep 01 13:49:38 nepu-0cb25072 VBoxService[728]: 11:49:38.097730 main     Process ID: 728
Sep 01 13:49:38 nepu-0cb25072 VBoxService[728]: 11:49:38.097730 main     Package type: LINUX_64BITS_GENERIC (OSE)
Sep 01 13:49:38 nepu-0cb25072 VBoxService[728]: 11:49:38.101547 main     7.2.0 r170228 started. Verbose level = 0
Sep 01 13:49:38 nepu-0cb25072 VBoxService[741]: 11:49:38.103407 main     VBoxClient 7.2.0 r170228 (verbosity: 0) linux.amd64 (Sep  1 2025 11:27:36) release log
Sep 01 13:49:38 nepu-0cb25072 VBoxService[741]: 11:49:38.103408 main     Log opened 2025-09-01T11:49:38.103405000Z
Sep 01 13:49:38 nepu-0cb25072 VBoxService[741]: 11:49:38.103546 main     OS Product: Linux
Sep 01 13:49:38 nepu-0cb25072 VBoxService[741]: 11:49:38.103551 main     OS Release: 6.16.4-arch1-1
Sep 01 13:49:38 nepu-0cb25072 VBoxService[741]: 11:49:38.103553 main     OS Version: #1 SMP PREEMPT_DYNAMIC Thu, 28 Aug 2025 19:49:53 +0000
Sep 01 13:49:38 nepu-0cb25072 VBoxService[741]: 11:49:38.103554 main     Executable: /usr/bin/VBoxDRMClient
Sep 01 13:49:38 nepu-0cb25072 VBoxService[741]: 11:49:38.103554 main     Process ID: 741
Sep 01 13:49:38 nepu-0cb25072 VBoxService[741]: 11:49:38.103555 main     Package type: LINUX_64BITS_GENERIC (OSE)
Sep 01 13:49:38 nepu-0cb25072 VBoxService[741]: 11:49:38.103659 main     VBoxDRMClient: found compatible device: /dev/dri/renderD128
Sep 01 13:49:38 nepu-0cb25072 VBoxService[741]: 11:49:38.104090 main     VBoxDRMClient: starting deferred resize events delivery
Sep 01 13:49:38 nepu-0cb25072 VBoxService[741]: 11:49:38.104568 main     VBoxDRMClient: IPC server socket access granted to all users
Sep 01 13:49:38 nepu-0cb25072 VBoxService[728]: 11:49:38.108065 automount vbsvcAutomounterMountIt: Successfully mounted 'share' on '/media/sf_share'
Sep 01 13:49:38 nepu-0cb25072 VBoxService[741]: 11:49:38.357513 Timer    VBoxDRMClient: push screen layout data of 1 display(s) to DRM stack, fPartialLayout=false, rc=VINF_SUCCESS
Sep 01 13:49:41 nepu-0cb25072 VBoxService[741]: 11:49:41.019036 IpcCLT-1332 VBoxDRMClient: IPC client connection started
Sep 01 13:49:46 nepu-0cb25072 VBoxService[741]: 11:49:46.105031 Timer    VBoxDRMClient: push screen layout data of 1 display(s) to DRM stack, fPartialLayout=false, rc=VINF_SUCCESS
Sep 01 13:49:48 nepu-0cb25072 VBoxService[741]: 11:49:48.856508 Timer    VBoxDRMClient: push screen layout data of 1 display(s) to DRM stack, fPartialLayout=false, rc=VINF_SUCCESS
[...]

Still no luck.

Have you rebooted guest afterwards?

Yes.