Windows 7 guest hangs reading hard disk

[alexivia]

Hi,

I used to use a Windows XP guest on my MacBook host so I could use some Windows-only software in school projects and works, and I kept using this older version of Windows just because it was lighter to run and because it required less HDD space. But now that I need some software that requires a more recent version of Windows, I created a new VM with Windows 7. The problem is that my new VM sometimes hangs and becomes inoperational! Even in VirtualBox's menu I can't shut it down (a timer appears saying that it will be shutdown, but said timer keeps increasing and it never shuts down). When this happens, if I check the Activity Monitor on the Disk section, it says that it is reading at over 300MB/s!! And it only stops if I force stop the VirtualBox VM process... This happens quite randmly, because even if I just turn the VM on and leave it without oppening anything, after some time the Activity Monitor shows a rising reading activity and then the VM hangs. My Mac keeps pretty responsive, as usual, though.

Host OS: OS X El Capitan 10.11.4 Guest OS: Windows 7 Professional x64 VirtualBox guest settings:

Chipset: PIIX3 I/O APIC: enabled CPUs: 1 PAE/NX: enabled Storage Controller: SATA AHCI without Host I/O Cache, show as SSD

I tried changing the chipset, I even changed from 2 CPUs to 1 (saw in a post that it could cause "over comitment")... I'm getting desperate, because I need to finish my projects. Please help me.

Thank you in advance! Best regards

[alexivia]

I tried booting it in safe mode with command prompt and perform a "chkdsk" and it ran the full scan without a problem, but when it booted again into Windows, few seconds after it hang again... this is what was on the log file:

00:21:21.254519 AHCI#0: Port 0 reset 00:21:21.255615 AHCI#0P0: Cancelled task 13 00:21:25.809882 AHCI#0P0: Canceled trim returned rc=VINF_SUCCESS 00:21:35.992608 RTC: period=0x20 (32) 1024 Hz 00:21:36.644813 RTC: period=0x200 (512) 64 Hz 00:21:50.254713 AHCI#0: Port 0 reset 00:21:50.255831 AHCI#0P0: Cancelled task 27

[Frank Mehnert]

Please attach the complete VBox.log file

[s.arsenyev]

Same problem but with Linux guest (Fedora x86 PAE) with 5.20 Host Windows 10 x64 when I use fstrim -v/ (on xfs on lvm with thin pool discard passthrough enabled) without Guest Additions it work fine (vdi goes to smaller size). If I install Guest Additions (5.20 or 5.16) and there are many deleted files (i.e. after upgrade) guest stall and log start filling --- 00:11:57.526379 AHCI#0: Port 0 reset 00:11:57.527541 AHCI#0P0: Cancelled task 19 00:12:28.487137 AHCI#0: Port 0 reset 00:12:28.488365 AHCI#0P0: Cancelled task 21 00:12:59.447872 AHCI#0: Port 0 reset 00:12:59.449040 AHCI#0P0: Cancelled task 25 00:13:30.471849 AHCI#0: Port 0 reset 00:13:30.473021 AHCI#0P0: Cancelled task 29 00:14:01.497166 AHCI#0: Port 0 reset 00:14:01.498329 AHCI#0P0: Cancelled task 2 00:14:32.456671 AHCI#0: Port 0 reset 00:14:32.457813 AHCI#0P0: Cancelled task 6 00:15:03.417517 AHCI#0: Port 0 reset 00:15:03.418674 AHCI#0P0: Cancelled task 4 ---

[s.arsenyev]

I think it's because of overlapping data move during trim or something similar

Because if I doing backward trimming with pauses it work fine

#!/bin/bash
LEN=536870912
START=$(expr $(df -h --block-size=K / | awk 'NR!=1&&$2!=""{gsub("K","",$2); print $2}') \* 1024)
while [ $START -gt 0 ]; do
START=$(expr $START - $LEN)
if [ $START -lt 0 ]; then
LEN=$(expr 0 - $START)
START=0
fi
echo "fstrim -v -o $START -l $LEN /"
fstrim -v -o $START -l $LEN /
sleep 10
done

After than ordinar trim (fstrim -v /) works fine? but do nothing :)

Same in 5.1 Beta2

[Frank Mehnert]

As long as you don't provide a complete VBox.log file this ticket will be ignored.

[schoeto]

I think I have the same problem.

Virtualbox 5.0.24 (same problem on 5.0.20)

Host

• Siduction Linux, Kernel 4.5.5-towo.1-siduction-amd64

Guest

• Windows 10 (same problem with Windows 7)
• VM on an SSD, BTRFS file system
• guest newly installed in a fresh VDI stored in a directory with BTRFS attribute NOCOW set

When I start up Windows guest, after different time periods the VM hangs endlessly (watched it for minutes) with high disk read activity (100 - 200 MB/s). Disk IO can be seen on VirtualBox HDD icon and with host os tools.

See attached logs.

[Frank Mehnert]

s.arsenyev, I removed the link to Google drive. Please don't post such links here. Again, please attach the VBox.log file from such a VM to this ticket.

schoeto, as you are using VBox 5.0.24, the I/O-APIC code cannot be responsible. I wonder if you set up your BTFS drive correctly. I saw the "no-cow" in the name of the file names but still. Any chance to run this VM with the VDI located on a different file system? All these "Port resets" and "Cancelled task" messages look suspicious.

[schoeto]

frank, I do indeed think that this is a problem with VirtualBox on BTRFS (on SSDs). I have no problems running the VMs from a network share or external harddrive (ext4). I do not experience any other major performance issues with my SSD.

Btw. the disk is encrypted underneath using luks.

FYI:

tux@laptop:~$ lsattr /home/tux/Virtualbox/btrfs-no-cow/Windows/Win10
----------------C-- /home/tux/Virtualbox/btrfs-no-cow/Windows/Win10/Snapshots
----------------C-- /home/tux/Virtualbox/btrfs-no-cow/Windows/Win10/Win10.vdi
----------------C-- /home/tux/Virtualbox/btrfs-no-cow/Windows/Win10/Win10.vbox-prev
----------------C-- /home/tux/Virtualbox/btrfs-no-cow/Windows/Win10/Win10.vbox
----------------C-- /home/tux/Virtualbox/btrfs-no-cow/Windows/Win10/Logs


tux@laptop:~$ sudo btrfs fi sh /home/tux/Virtualbox
Label: 'root'  uuid: 89e96241-4bdd-4884-8340-a67e55003937
	Total devices 1 FS bytes used 207.25GiB
	devid    1 size 464.81GiB used 345.71GiB path /dev/mapper/sda3_crypt


tux@laptop:~$ sudo btrfs fi df /home/tux/Virtualbox
Data, single: total=340.65GiB, used=205.50GiB
System, DUP: total=32.00MiB, used=96.00KiB
Metadata, DUP: total=2.50GiB, used=1.74GiB
GlobalReserve, single: total=512.00MiB, used=0.00B


tux@laptop:~$ sudo btrfs fi usage /home/tux/Virtualbox
Overall:
    Device size:		 464.81GiB
    Device allocated:		 345.71GiB
    Device unallocated:		 119.10GiB
    Device missing:		     0.00B
    Used:			 208.99GiB
    Free (estimated):		 254.25GiB	(min: 194.70GiB)
    Data ratio:			      1.00
    Metadata ratio:		      2.00
    Global reserve:		 512.00MiB	(used: 0.00B)

Data,single: Size:340.65GiB, Used:205.50GiB
   /dev/mapper/sda3_crypt	 340.65GiB

Metadata,DUP: Size:2.50GiB, Used:1.74GiB
   /dev/mapper/sda3_crypt	   5.00GiB

System,DUP: Size:32.00MiB, Used:96.00KiB
   /dev/mapper/sda3_crypt	  64.00MiB

Unallocated:
   /dev/mapper/sda3_crypt	 119.10GiB

[schoeto]

Good news!

It seems the problem could be solved for me by switching on the virtual SATA controller setting Use host I/O cache.

So the relevant settings are now:

• System: [x] Enable I/O APIC
• SATA controller: [x] Use host I/O cache
• VDI: [x] Solid-state drive

[s.arsenyev]

Replying to frank:

s.arsenyev, I removed the link to Google drive. Please don't post such links here. Again, please attach the VBox.log file from such a VM to this ticket.

No problem. But There wasn't only file but whole VM before trim command with screen shots. Attachments here is limited. Where better to put such files?

P.S. Revers order some times doesn't help.

[abutler]

I had the same problem with a Windows 10 guest on BTRFS (although I forgot to change COW). Checking use host IO cache indeed did work for me though even without disabling COW.

00:14:10.255218 AHCI#0: Port 0 reset
00:14:10.256264 AHCI#0P0: Cancelled task 2
00:14:10.256275 AHCI#0P0: Cancelled task 4
00:14:10.256278 AHCI#0P0: Cancelled task 6
00:14:10.256281 AHCI#0P0: Cancelled task 8
00:14:10.256284 AHCI#0P0: Cancelled task 9
00:14:10.256287 AHCI#0P0: Cancelled task 10
00:14:10.256289 AHCI#0P0: Cancelled task 12
00:14:10.256292 AHCI#0P0: Cancelled task 14
00:14:10.256294 AHCI#0P0: Cancelled task 15
00:14:10.256297 AHCI#0P0: Cancelled task 16
00:14:10.256300 AHCI#0P0: Cancelled task 17
00:14:10.256302 AHCI#0P0: Cancelled task 18
00:14:10.256305 AHCI#0P0: Cancelled task 19
00:14:10.256307 AHCI#0P0: Cancelled task 21
00:14:10.256310 AHCI#0P0: Cancelled task 22
00:14:10.256313 AHCI#0P0: Cancelled task 23
00:14:10.256315 AHCI#0P0: Cancelled task 24
00:14:10.256318 AHCI#0P0: Cancelled task 25
00:14:10.256320 AHCI#0P0: Cancelled task 26
00:14:10.256323 AHCI#0P0: Cancelled task 27