[opensuse] VirtualBox 6.0.0 Win7 guest (dir in cmd.exe takes 50% CPU)
All, If any of you are running Win7 guest in virtualbox, I'm trying to nail down an issue and need some help. I basically keep a win7 guest on the server to access over the LAN with the --headless option to use to answer coding questions involving MinGW or VS. I have used this setup since Virtualbox 4. With the update to Virtualbox 6.0.0, the Command Prompt in the Win7 guest is rendered all but unusable. Something has changed that effects the ability to 'redraw' the terminal as lines are output (slowing output to that of a Dot-Matrix printer) Attempting to move the command prompt window (or PowerShell window) similarly results in artifacts left of the desktop which are slowly repainted to complete the move. I'm working the issue on the vbox-users-community list and I could use some additional input. With my setup I launch the Win7 guest while ssh'ed into the host server with: VBoxManage startvm Win7Pro_32bit --type headless (if needed I set the resolution for the guest with) VBoxManage controlvm "Win7Pro_32bit" setvideomodehint 1440 864 32 (I have done it this same way for years) With the install I have with vbox 5.2.22, there is no problem with the Command Prompt 'dir' listing in the Win7 guest. With 6.0.0 it takes 20.5 seconds to list 176 files (do you know how long 20.5 seconds is just waiting for a short directory list to complete is? -- it's really long) So does anyone else use Virtualbox to access headless windows 7 guest via their LAN? If so, open a Command Prompt and change to a directory with a 100 files or so and type 'dir' and let me know if it takes a painfully long time to complete while spiking the CPU usage by 40-50%. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/01/2019 09:53, David C. Rankin wrote:
So does anyone else use Virtualbox to access headless windows 7 guest via their LAN? If so, open a Command Prompt and change to a directory with a 100 files or so and type 'dir' and let me know if it takes a painfully long time to complete while spiking the CPU usage by 40-50%.
I haven't got a VM to play with but I do use Win7 under VBox, yes. Stuff to consider: * For Windows guests, 2D & 3D acceleration are separate options. Both are available. Is either on? Try toggling their status? * Do you have the guest additions installed? If not, try it. * If they are installed, have you upgraded them to match the host version? -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/11/2019 06:13 AM, Liam Proven wrote:
I haven't got a VM to play with but I do use Win7 under VBox, yes.
Stuff to consider: * For Windows guests, 2D & 3D acceleration are separate options. Both are available. Is either on? Try toggling their status? * Do you have the guest additions installed? If not, try it. * If they are installed, have you upgraded them to match the host version?
Liam, Thanks. Yes I've already tried both 2D and 3D acceleration options (makes no difference). Since I use rdesktop to access the guest, the graphics performance isn't really tied to the acceleration models. I have installed and reinstalled the current versions of Guest Additions, no change. (I always update Guest Additions with every host version update) This is a really weird issue that seems tied to how vbox 6.0.6 behaves with the --headless option. It's almost like there was a change to the network communication that now inadvertently synchronously blocks waiting for each redraw request to complete where before it was handled in a non-blocking manner. (I'm guessing here -- but that is about the only code/change based logical guess I can come up with that matches what I'm seeing. It also explains why large block-redraws seems less effected than smaller line-by-line updates of the terminal) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/01/2019 00:45, David C. Rankin wrote:
Thanks. Yes I've already tried both 2D and 3D acceleration options (makes no difference). Since I use rdesktop to access the guest, the graphics performance isn't really tied to the acceleration models.
I'm not so sure about that. Ever since NT 4, the GDI has been deep inside the kernel, and that means it's code that runs in Ring 0, which is the single most performance-critical code for anything running in a VM. If there is no acceleration at all, then the GDI will be doing lots of tight little loops, writing all the pixels individually into emulated VRAM, for every single line and curve on the screen. That's bound to be inefficient.
I have installed and reinstalled the current versions of Guest Additions, no change. (I always update Guest Additions with every host version update)
Sounds good.
This is a really weird issue that seems tied to how vbox 6.0.6 behaves with the --headless option. It's almost like there was a change to the network communication that now inadvertently synchronously blocks waiting for each redraw request to complete where before it was handled in a non-blocking manner.
I have never tried headless mode and I don't have Win7 to hand any more. I can see if I can reproduce it with Win10. I am currently installing the build 1809 update in my VM. After that I will have a look, but I only have Vbox 5.22. I think something about display rendering was a bit broken before anyway as I have not been able to get seamless mode working. It has worked for me before on other versions of Vbox, but in the last year or so, was broken on both Linux and macOS hosts.
(I'm guessing here -- but that is about the only code/change based logical guess I can come up with that matches what I'm seeing. It also explains why large block-redraws seems less effected than smaller line-by-line updates of the terminal)
I don't know. :-( -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/14/2019 06:50 AM, Liam Proven wrote:
I have never tried headless mode and I don't have Win7 to hand any more. I can see if I can reproduce it with Win10. I am currently installing the build 1809 update in my VM. After that I will have a look, but I only have Vbox 5.22.
I think something about display rendering was a bit broken before anyway as I have not been able to get seamless mode working. It has worked for me before on other versions of Vbox, but in the last year or so, was broken on both Linux and macOS hosts.
(I'm guessing here -- but that is about the only code/change based logical guess I can come up with that matches what I'm seeing. It also explains why large block-redraws seems less effected than smaller line-by-line updates of the terminal) I don't know. :-(
This seems to be unique to --headless with windows7 (probably 10) guests. Further strace of the running process shows errors with select/read. strace outputs the following to stderr: $ cat 20190113-202935_win32_err.log strace: Process 1286 attached select(10, [9], NULL, [9], NULL) = 1 (in [9]) read(9, "\372", 1) = 1 select(10, [9], NULL, [9], NULL) = 1 (in [9]) read(9, "\372", 1) = 1 select(10, [9], NULL, [9], NULL) = 1 (in [9]) read(9, "\372", 1) = 1 select(10, [9], NULL, [9], NULL) = 1 (in [9]) read(9, "\372", 1) = 1 select(10, [9], NULL, [9], NULL) = 1 (in [9]) read(9, "\372", 1) = 1 select(10, [9], NULL, [9], NULL) = 1 (in [9]) read(9, "\372", 1) = 1 select(10, [9], NULL, [9], NULL) = 1 (in [9]) read(9, "\372", 1) = 1 ...<snip>... select(10, [9], NULL, [9], NULL) = 1 (in [9]) read(9, "\372", 1) = 1 futex(0x171c1b8, FUTEX_WAKE_PRIVATE, 1) = 1 read(9, "\372", 1) = 1 select(10, [9], NULL, [9], NULL) = 1 (in [9]) read(9, "\372", 1) = 1 select(10, [9], NULL, [9], NULL) = 1 (in [9]) read(9, "\372", 1) = 1 select(10, [9], NULL, [9], NULL) = 1 (in [9]) read(9, "\372", 1) = 1 select(10, [9], NULL, [9], NULL) = 1 (in [9]) read(9, "\372", 1) = 1 ...<snip to end>... Will report further at the end of trouble-shooting on the vbox-users list. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/14/2019 03:16 PM, David C. Rankin wrote:
(I'm guessing here -- but that is about the only code/change based logical guess I can come up with that matches what I'm seeing. It also explains why large block-redraws seems less effected than smaller line-by-line updates of the terminal) I don't know. :-(
This seems to be unique to --headless with windows7 (probably 10) guests. Further strace of the running process shows errors with select/read. strace outputs the following to stderr:
$ cat 20190113-202935_win32_err.log strace: Process 1286 attached select(10, [9], NULL, [9], NULL) = 1 (in [9]) <snip>
Will report further at the end of trouble-shooting on the vbox-users list.
I have been working the issue on the vbox-users list. The problem effects VirtualBox when accessed over ssh, and Windows guests run --headless. The Virtualbox 6.0.0 console coredumps when accessed via ssh, while windows guest run --headless throws select/read error (under strace) bringing the guest to a crawl. With the release of 5.2.24 today by oracle, I built and downgraded both virtualbox-bin and virtualbox-ext-oracle and the problems are completely gone. Further, the release notes state the 5.2 branch will remain supported through 2020 as 6.0 matures. If anyone experiences similar problems with virtualbox when accessed over your LAN, then the 5.2.24 release is an option I have confirmed works (as well as all modules building under Linux 4.20.1, Bash 5 and Readline 8, etc..) I have not tried the now 6.0.2 yet, but as nothing addressed these issues in the changelog, I suspect they remain. Will check this weekend and if fixed will reportback. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
David C. Rankin -
Liam Proven