unRAID OS Version: 6.0 beta 12

 

Description: When using a Windows VM under Xen, the network mapped drive keeps dropping connection causing utorrent to report "Unexpected network error occured. (Write to Disk)" Or it can also say read from disk. This is from the mapped drive where it is downloading to disconnecting.

 

How to reproduce:  Fire up a windows VM under XEN, Map a network drive and download a few torrents across the network.

 

Expected results:  The torrents will kick out the same error.

 

Actual results:

 

Other information: Syslog:

Dec 11 05:52:44 Icarus emhttp: read_line: client closed the connection
Dec 11 05:53:47 Icarus emhttp: read_line: client closed the connection
Dec 11 05:54:20 Icarus kernel: vif vif-5-0 vif5.0: Carrier off due to lack of guest response on queue 0
Dec 11 05:54:20 Icarus kernel: br0: port 3(vif5.0) entered disabled state
Dec 11 05:54:20 Icarus kernel: vif vif-5-0 vif5.0: Carrier on again
Dec 11 05:54:20 Icarus kernel: br0: port 3(vif5.0) entered listening state
Dec 11 05:54:20 Icarus kernel: br0: port 3(vif5.0) entered listening state
Dec 11 05:54:35 Icarus kernel: br0: port 3(vif5.0) entered learning state
Dec 11 05:54:50 Icarus kernel: br0: topology change detected, propagating
Dec 11 05:54:50 Icarus kernel: br0: port 3(vif5.0) entered forwarding state
Dec 11 05:54:52 Icarus emhttp: read_line: client closed the connection
Dec 11 05:57:28 Icarus emhttp: read_line: client closed the connection

unRAID OS Version: 6.0 beta 12

 

Description: When using a Windows VM under Xen, the network mapped drive keeps dropping connection causing utorrent to report "Unexpected network error occured. (Write to Disk)" Or it can also say read from disk. This is from the mapped drive where it is downloading to disconnecting.

 

How to reproduce:  Fire up a windows VM under XEN, Map a network drive and download a few torrents across the network.

 

Expected results:  The torrents will kick out the same error.

 

Actual results:

 

Other information: Syslog:

Dec 11 05:52:44 Icarus emhttp: read_line: client closed the connection
Dec 11 05:53:47 Icarus emhttp: read_line: client closed the connection
Dec 11 05:54:20 Icarus kernel: vif vif-5-0 vif5.0: Carrier off due to lack of guest response on queue 0
Dec 11 05:54:20 Icarus kernel: br0: port 3(vif5.0) entered disabled state
Dec 11 05:54:20 Icarus kernel: vif vif-5-0 vif5.0: Carrier on again
Dec 11 05:54:20 Icarus kernel: br0: port 3(vif5.0) entered listening state
Dec 11 05:54:20 Icarus kernel: br0: port 3(vif5.0) entered listening state
Dec 11 05:54:35 Icarus kernel: br0: port 3(vif5.0) entered learning state
Dec 11 05:54:50 Icarus kernel: br0: topology change detected, propagating
Dec 11 05:54:50 Icarus kernel: br0: port 3(vif5.0) entered forwarding state
Dec 11 05:54:52 Icarus emhttp: read_line: client closed the connection
Dec 11 05:57:28 Icarus emhttp: read_line: client closed the connection

 

Can you confirm for me that this only happens when using a Xen-based Windows Virtual Machine?  Do network mapped drives to physical Windows (or other) computers experience this issue?  Is your workaround to restart the VM?

jonp thanx for the reply!

 

I can confirm that this only happens on the Xen VM i have not tried docker or KVM. All network drives have this issue, not just internal to the server. I have no work around, i am currently downloading to an additional data.img file that is mapped as a physical harddrive and once the download is complete i have it moving over across the network. That being said while the downloads are going they stop every few minutes and restart because of this error.

/usr/bin/tail -n 42 -f /var/log/syslog 2>&1
Dec 31 07:58:23 Icarus kernel: vif vif-3-0 vif3.0: Carrier off due to lack of guest response on queue 0
Dec 31 07:58:23 Icarus kernel: br0: port 3(vif3.0) entered disabled state
Dec 31 07:58:23 Icarus kernel: vif vif-3-0 vif3.0: Carrier on again
Dec 31 07:58:23 Icarus kernel: br0: port 3(vif3.0) entered listening state
Dec 31 07:58:23 Icarus kernel: br0: port 3(vif3.0) entered listening state
Dec 31 07:58:33 Icarus kernel: mdcmd (54): spindown 0
Dec 31 07:58:38 Icarus kernel: br0: port 3(vif3.0) entered learning state
Dec 31 07:58:53 Icarus kernel: br0: topology change detected, propagating
Dec 31 07:58:53 Icarus kernel: br0: port 3(vif3.0) entered forwarding state
Dec 31 07:59:59 Icarus emhttp: read_line: client closed the connection
Dec 31 08:01:00 Icarus emhttp: read_line: client closed the connection
Dec 31 08:02:01 Icarus emhttp: read_line: client closed the connection
Dec 31 08:03:02 Icarus emhttp: read_line: client closed the connection
Dec 31 08:04:03 Icarus emhttp: read_line: client closed the connection
Dec 31 08:05:05 Icarus emhttp: read_line: client closed the connection
Dec 31 08:06:06 Icarus emhttp: read_line: client closed the connection
Dec 31 08:07:07 Icarus emhttp: read_line: client closed the connection
Dec 31 08:08:08 Icarus emhttp: read_line: client closed the connection
Dec 31 08:09:09 Icarus emhttp: read_line: client closed the connection
Dec 31 08:10:11 Icarus emhttp: read_line: client closed the connection
Dec 31 08:11:12 Icarus emhttp: read_line: client closed the connection
Dec 31 08:12:13 Icarus emhttp: read_line: client closed the connection
Dec 31 08:13:15 Icarus emhttp: read_line: client closed the connection
Dec 31 08:14:16 Icarus emhttp: read_line: client closed the connection
Dec 31 08:15:17 Icarus emhttp: read_line: client closed the connection
Dec 31 08:16:19 Icarus emhttp: read_line: client closed the connection
Dec 31 08:17:20 Icarus emhttp: read_line: client closed the connection
Dec 31 08:18:22 Icarus emhttp: read_line: client closed the connection
Dec 31 08:19:23 Icarus emhttp: read_line: client closed the connection
Dec 31 08:20:25 Icarus emhttp: read_line: client closed the connection
Dec 31 08:21:26 Icarus emhttp: read_line: client closed the connection
Dec 31 08:22:27 Icarus emhttp: read_line: client closed the connection
Dec 31 08:23:29 Icarus emhttp: read_line: client closed the connection
Dec 31 08:24:30 Icarus emhttp: read_line: client closed the connection
Dec 31 08:25:31 Icarus emhttp: read_line: client closed the connection
Dec 31 08:26:32 Icarus emhttp: read_line: client closed the connection
Dec 31 08:27:34 Icarus emhttp: read_line: client closed the connection
Dec 31 08:28:35 Icarus emhttp: read_line: client closed the connection
Dec 31 08:29:37 Icarus emhttp: read_line: client closed the connection
Dec 31 08:30:38 Icarus emhttp: read_line: client closed the connection
Dec 31 08:31:39 Icarus emhttp: read_line: client closed the connection
Dec 31 08:32:40 Icarus emhttp: read_line: client closed the connection

jonp thanx for the reply!

 

I can confirm that this only happens on the Xen VM i have not tried docker or KVM. All network drives have this issue, not just internal to the server. I have no work around, i am currently downloading to an additional data.img file that is mapped as a physical harddrive and once the download is complete i have it moving over across the network. That being said while the downloads are going they stop every few minutes and restart because of this error.

 

What drivers are you using in Windows for the virtual network interface?  Are these GPLPV?  Have you tried switching?

 

When this occurs, do you have to restart the VM to resolve or just remap the drive?  Do you lose all network connectivity or just the mapped drive?

 

Do you have any non-Windows VMs that are exhibiting the same issue with networking?

 

Many possibilities on where this issue could be coming from within the Xen stack...

They are the GPLPV drivers , havent tried removing them.... I dont have to do anything when it happens as it is self correcting. I lose all network connectivity for about 30 seconds, then everything comes back up. Only using windows VM's and the other VM is only running plex which does not have the problem, (you really gotta torrent across the network for it to break).

They are the GPLPV drivers , havent tried removing them.... I dont have to do anything when it happens as it is self correcting. I lose all network connectivity for about 30 seconds, then everything comes back up. Only using windows VM's and the other VM is only running plex which does not have the problem, (you really gotta torrent across the network for it to break).

 

The fact that you're not experiencing this issue with the Linux guest is proof enough for me to point to the GPLPV drivers for Windows as the culprit here (or something in between them and the Xen kernel; who actually knows who's to blame for it).  I would consider removing the GPLPV drivers and just use the QEMU emulated drivers like realtek and see if that resolves the issue.

 

The problem with Xen's GPLPV drivers for Windows is that they are written and maintained by a 3rd party outside the Xen project itself.  I have had LOTS of issues with the GPLPV drivers in Windows.  None of the various ones I have found ever delivered the full functionality that I want / expect of a VM.  KVM's VirtIO drivers for Windows have worked flawlessly for me ever since I started using them a while back.