Very slow Windows guests
-
- Posts: 6
- Joined: 22. Sep 2023, 01:57
Very slow Windows guests
I've seen other discussions about this, but details don't quite match my question...
I have VirtualBox running on 7.0.10, where the host is running Windows 10 Pro. I have a number of guests defined, both Windows and Linux. The Linux guests are fine, but all the Windows guests are struggling with slow performance. For Windows, I have a variety of stuff installed, including a 32-bit Win 10, 2 64-bit Win 10, and a Win 11 installation.
My host machine does have Hyper-V on it, as I was briefly running a VM there. I know that VirtualBox and Hyper-V don't get along, and I had thought I had disabled it, although when I followed info from another discussion, I found that I had missed disabling the Windows Hypervisor, although I have disabled the other components, including Containers, Hyper-V, Virtual Machine Platform and Windows Sandbox. When I disabled the Hypervisor (and rebooted), I'm seeing a little bit improvement in performance, but not a lot. I don't normally leave the Status Bar enabled, and I only discovered that after removing the Hypervisor, and as a result, I'm not seeing any Turtle icons there.
There are times when I briefly get Guest performance that's decent, and other times where things are pretty much frozen -- sometimes inserting Ctrl-Alt-Del is enough to get things moving, other times, I have to resort to a full shutdown of the VM.
I have briefly examined things like video card standards, enabling/disabling of 3D or hardware acceleration, but I'm not convinced that those make much difference. My sense is that my issues are less related to configs of individual VMs than in how I have VirtualBox set up, although it's certainly not impossible that I'm missing a setting that I should be doing with all of my Windows guests. The odd thing is that although my Linux installations (one Ubuntu, one Mint) are slower than what I see if I install those on physical hardware, the responsiveness isn't unacceptably slow, either. Just the Windows guests.
Any ideas of how to resolve this?
I have VirtualBox running on 7.0.10, where the host is running Windows 10 Pro. I have a number of guests defined, both Windows and Linux. The Linux guests are fine, but all the Windows guests are struggling with slow performance. For Windows, I have a variety of stuff installed, including a 32-bit Win 10, 2 64-bit Win 10, and a Win 11 installation.
My host machine does have Hyper-V on it, as I was briefly running a VM there. I know that VirtualBox and Hyper-V don't get along, and I had thought I had disabled it, although when I followed info from another discussion, I found that I had missed disabling the Windows Hypervisor, although I have disabled the other components, including Containers, Hyper-V, Virtual Machine Platform and Windows Sandbox. When I disabled the Hypervisor (and rebooted), I'm seeing a little bit improvement in performance, but not a lot. I don't normally leave the Status Bar enabled, and I only discovered that after removing the Hypervisor, and as a result, I'm not seeing any Turtle icons there.
There are times when I briefly get Guest performance that's decent, and other times where things are pretty much frozen -- sometimes inserting Ctrl-Alt-Del is enough to get things moving, other times, I have to resort to a full shutdown of the VM.
I have briefly examined things like video card standards, enabling/disabling of 3D or hardware acceleration, but I'm not convinced that those make much difference. My sense is that my issues are less related to configs of individual VMs than in how I have VirtualBox set up, although it's certainly not impossible that I'm missing a setting that I should be doing with all of my Windows guests. The odd thing is that although my Linux installations (one Ubuntu, one Mint) are slower than what I see if I install those on physical hardware, the responsiveness isn't unacceptably slow, either. Just the Windows guests.
Any ideas of how to resolve this?
-
- Site Moderator
- Posts: 39156
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: Very slow Windows guests
Please provide a VM log file. Make sure the VM is fully shut down, then right click it in the manager UI. Select "Show Log" and save "VBox.log" (no other file) to a zip file. Attach the zip here.
-
- Posts: 6
- Joined: 22. Sep 2023, 01:57
Re: Very slow Windows guests
Thanks for the feedback. See uploaded file.
-
- Site Moderator
- Posts: 39156
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: Very slow Windows guests
No Hyper-v, good.
What is drive "\\ponderosa" on your PC? If that's a network connection it is likely to be WAYYYYYY slower than a local drive, especially on the IOPS front - and that would explain the poor performance.
For example I have a gigabit home LAN here, meaning around 113MB/s transfer speed - and unknown IOPS since I would never attempt Windows on such a slow drive.
To make matters worse you are also using a snapshot, i.e. so it is effectively accessing two drive images.
What is drive "\\ponderosa" on your PC? If that's a network connection it is likely to be WAYYYYYY slower than a local drive, especially on the IOPS front - and that would explain the poor performance.
For example I have a gigabit home LAN here, meaning around 113MB/s transfer speed - and unknown IOPS since I would never attempt Windows on such a slow drive.
To make matters worse you are also using a snapshot, i.e. so it is effectively accessing two drive images.
-
- Volunteer
- Posts: 5385
- Joined: 14. Feb 2019, 03:06
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Linux, Windows 10, ...
- Location: Germany
Re: Very slow Windows guests
FWIW, the VM in the VBox.log file has been resumed from a Saved state, which is like continuing the guest OS after pausing it, and we cannot guess what happened since the guest OS was really started. Please reproduce the issue with a VM starting from the Power-off state.
-
- Posts: 6
- Joined: 22. Sep 2023, 01:57
Re: Very slow Windows guests
As far as I'm aware, the posted log was done from a shutdown state, not saved.
In the meantime, the question about \\ponderosa is what I need to see. In this context, I had forgotten that I had relocated the VM to networked storage, and in ignoring warnings about performance issues, not realized just how much performace issue could be there.
For the log that I posted, that was the most recent VM that I had relocated to the network, and before I relocated it, it was getting much better performance. In my original post, I noted that only my Windows VMs are having issues, but they're the ones located on the LAN, and the Linux VMs that aren't having issues are still located on the local hard drive.
I'm quite willing to accept that my issues are coming from LAN storage, and not something specific to any of the VMs, nor of VirtualBox configs (other than LAN storage).
The underlying issue is that the host machine that I'm working from is tight on local space, and that I don't have nearly what I need for as many VMs as I happen to be using right now. I'm looking at upgrading this machine, both of moving physical RAM from 16 GB to 32 TB, and upgrading storage from the existing 512 GB SSD to at least 1 TB (and possibly 2 TB if the machine will handle it). RAM will give me the ability of allocating more to VMs (I normally do 4 GB), but I definitely need more capacity to store my VMs locally.
In the meantime, the LAN device that I'm storing on is a near-new Linux installation that runs Mint 21, and has plenty of RAM and storage space. It may be that rather than pushing too hard to get my Windows laptop upgraded (at least immediately), it may be feasible for me to install VirtualBox on the Mint installation, and run at least some of those VMs there.
Thus, the additional question would be that if the VMs are already physically located on the Linux box, is there any reason I should not simply run them from there, under the expectation that a change-over would be a one-time thing, and where I'm deleting the VM defs from the VirtualBox setup on the laptop (and not trying to continually shift between the two hosts)?
Beyond finding the procedures of opening a VM from a different host (including making sure that I have VMs in shutdown state before I start working), are there any considerations to account for in that transition? The Windows laptop is an Intel Core i5 8250U and the Linux box is AMD Ryzen 5 5500U .
Thanks for feedback
ZZ
In the meantime, the question about \\ponderosa is what I need to see. In this context, I had forgotten that I had relocated the VM to networked storage, and in ignoring warnings about performance issues, not realized just how much performace issue could be there.
For the log that I posted, that was the most recent VM that I had relocated to the network, and before I relocated it, it was getting much better performance. In my original post, I noted that only my Windows VMs are having issues, but they're the ones located on the LAN, and the Linux VMs that aren't having issues are still located on the local hard drive.
I'm quite willing to accept that my issues are coming from LAN storage, and not something specific to any of the VMs, nor of VirtualBox configs (other than LAN storage).
The underlying issue is that the host machine that I'm working from is tight on local space, and that I don't have nearly what I need for as many VMs as I happen to be using right now. I'm looking at upgrading this machine, both of moving physical RAM from 16 GB to 32 TB, and upgrading storage from the existing 512 GB SSD to at least 1 TB (and possibly 2 TB if the machine will handle it). RAM will give me the ability of allocating more to VMs (I normally do 4 GB), but I definitely need more capacity to store my VMs locally.
In the meantime, the LAN device that I'm storing on is a near-new Linux installation that runs Mint 21, and has plenty of RAM and storage space. It may be that rather than pushing too hard to get my Windows laptop upgraded (at least immediately), it may be feasible for me to install VirtualBox on the Mint installation, and run at least some of those VMs there.
Thus, the additional question would be that if the VMs are already physically located on the Linux box, is there any reason I should not simply run them from there, under the expectation that a change-over would be a one-time thing, and where I'm deleting the VM defs from the VirtualBox setup on the laptop (and not trying to continually shift between the two hosts)?
Beyond finding the procedures of opening a VM from a different host (including making sure that I have VMs in shutdown state before I start working), are there any considerations to account for in that transition? The Windows laptop is an Intel Core i5 8250U and the Linux box is AMD Ryzen 5 5500U .
Thanks for feedback
ZZ
-
- Site Moderator
- Posts: 39156
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: Very slow Windows guests
32GB I find is a good number on general principles: it means I can give a VM that needs it anything up to 16GB RAM without crippling the host.zed zedmore wrote: ↑26. Sep 2023, 01:18 I'm looking at upgrading this machine, both of moving physical RAM from 16 GB to 32 TB, and upgrading storage from the existing 512 GB SSD to at least 1 TB (and possibly 2 TB if the machine will handle it).
My home PC has 2 x 2TB SSDs installed. It's an old habit, having a system drive and a bulk data drive, though these days they are both the same size and both are SSDs. The secondary SSD is where I locate all my VMs, software installers, ISO images etc. I also have a NAS which I use for backups, but I don't locate VMs there.
If you aren't hard up then I'd say that 2TB SSDs are relatively inexpensive, and two is better than one.
-
- Site Moderator
- Posts: 39156
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: Very slow Windows guests
That's fine as far as VirtualBox is concerned. The easiest way to transfer would be to move the VM folder: if all VDI paths are relative then there should only be minor tweaks involved in moving between Windows and Linux.zed zedmore wrote: ↑26. Sep 2023, 01:18 Thus, the additional question would be that if the VMs are already physically located on the Linux box, is there any reason I should not simply run them from there.
Note however that the CPU is visible to guests, which can affect activation and licensing.
-
- Volunteer
- Posts: 5385
- Joined: 14. Feb 2019, 03:06
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Linux, Windows 10, ...
- Location: Germany
Re: Very slow Windows guests
It's perhaps not important in your case, but just for the sake of correctness:
PS: Eliminating the network storage is most probably the right direction to investigate in.
Search the VBox.log file for "Console: Machine state changed to 'Restoring'" and "SSM:" to see for yourself.zed zedmore wrote: ↑26. Sep 2023, 01:18 As far as I'm aware, the posted log was done from a shutdown state, not saved.
PS: Eliminating the network storage is most probably the right direction to investigate in.
-
- Posts: 6
- Joined: 22. Sep 2023, 01:57
Re: Very slow Windows guests
I'm getting mostly good results by running my guests from the same machine they're stored on, and without a network connection between the guest and the VirtualBox instance running it.
For the transition, there have been a couple of small things to work around. One is that a couple of the VMs have had external storage defined, and of course, those aren't available (certainly not in the same locations), so I've had to disable those. Mostly minor, because I haven't really done anything with those other than proof-of-concept. There's also a matter of matching VirtualBox version numbers, especially with Guest Additons. In Windows, I've been running 7.0.10, and for the moment, on the Linux side, I'm running 6.1.38 from Ubuntu's repositories. I tried setting up Oracle's PPA repository, but had difficulty there, and haven't yet tried straight download of the .deb from Oracle. Thus, in running these machines in 6.1.38, I've had to reinstall the Guest Additions for the proper version, and going further there is a Linux question that is beyond the bounds of a Windows forum.
In the meantime, two of the machines won't start, complaining about an invalid setting 'WAS' for the audio adapters. From what I can tell, that's also a versioning question, probably that both were built in version 7, and I'll have to tinker to get things properly for V6.
For the transition, there have been a couple of small things to work around. One is that a couple of the VMs have had external storage defined, and of course, those aren't available (certainly not in the same locations), so I've had to disable those. Mostly minor, because I haven't really done anything with those other than proof-of-concept. There's also a matter of matching VirtualBox version numbers, especially with Guest Additons. In Windows, I've been running 7.0.10, and for the moment, on the Linux side, I'm running 6.1.38 from Ubuntu's repositories. I tried setting up Oracle's PPA repository, but had difficulty there, and haven't yet tried straight download of the .deb from Oracle. Thus, in running these machines in 6.1.38, I've had to reinstall the Guest Additions for the proper version, and going further there is a Linux question that is beyond the bounds of a Windows forum.
In the meantime, two of the machines won't start, complaining about an invalid setting 'WAS' for the audio adapters. From what I can tell, that's also a versioning question, probably that both were built in version 7, and I'll have to tinker to get things properly for V6.
-
- Site Moderator
- Posts: 20303
- Joined: 30. Dec 2009, 20:14
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Windows, Linux
Re: Very slow Windows guests
The problem with WAS is the new audio controller introduced in 7.0 that didn't exist in 6.1.
If you try to make a new VM with the same kind of OS template in 6.1, the new VM will show what audio controller that OS would have gotten in 6.1. You can then change the audio controller to that kind on the 7.0 host, boot the VM to see the new hardware, then copy the VM to the 6.1 host. The copied VM should then be compatible.
If you don't need audio in the VMs, then simply disabling audio should compatiblize the VM with 6.1.
If you try to make a new VM with the same kind of OS template in 6.1, the new VM will show what audio controller that OS would have gotten in 6.1. You can then change the audio controller to that kind on the 7.0 host, boot the VM to see the new hardware, then copy the VM to the 6.1 host. The copied VM should then be compatible.
If you don't need audio in the VMs, then simply disabling audio should compatiblize the VM with 6.1.
-
- Posts: 6
- Joined: 22. Sep 2023, 01:57
Re: Very slow Windows guests
Finishing off this thread...
I confirm that all of my VMs are behaving nicely when guests and Virtualbox are on the same machine (including a well-provisioned host, with adequate RAM and SSD storage), and no network in-between.
For the guests that were configured in VirtualBox 7, deleting the sound configs was sufficient to get them running, and of course, making sure that the correct version of Guest Additions has been installed.
Although I do want to get to later versions of VirtualBox than are currently in the Ubuntu Jammy repository, I'm satisfied that all my guests are working acceptably.
Thanks to all that submitted the right follow-up questions.
ZZ
I confirm that all of my VMs are behaving nicely when guests and Virtualbox are on the same machine (including a well-provisioned host, with adequate RAM and SSD storage), and no network in-between.
For the guests that were configured in VirtualBox 7, deleting the sound configs was sufficient to get them running, and of course, making sure that the correct version of Guest Additions has been installed.
Although I do want to get to later versions of VirtualBox than are currently in the Ubuntu Jammy repository, I'm satisfied that all my guests are working acceptably.
Thanks to all that submitted the right follow-up questions.
ZZ