Sharing a finding with the community... I was having problems with large file writes from a newly VM'd Windows XP guest. The problem appears to be instability in the Parallels 6 NAT (Shared Networking) feature. Symptoms: Following a new conversion from physical, the VM is still running Ghost for backups, and the job writes 175GB to a Windows server that's connected to the same gigabit ethernet switch. The job is written to a series of 4.5GB files, so functionally this is like copying a lot of large files at once. The backup job was failing every time with a "Windows Delayed Write Failure" error message. It never failed at the same point, but never made it past 130GB. Details: I ran Wireshark on the Windows VM to monitor the network traffic. I discovered that the network was failing shortly after a burst of write packets - TCP acknowledgements from the server would never arrive, the VM would retransmit, and eventually timeout the server connection. In fact, there were no incoming packets at all for a period of 102 seconds. After the silent period, the network resumed working normally and acknowledgements arrived from the server, but too late to recover the connection. The interesting part... none of the incoming packets had been "lost"; rather, they were being severely (!) delayed by Parallels networking, though it appeared that all of the outgoing packets had been sent without delay. Every single incoming packet arrived as it should have, including ACKs for each of the VM's retransmission attempts during the silent period (and IP packet ID# sequencing proves these were all the original TCP packets, not server-side retransmissions). I know it sounds like speculation, but trust me on the analysis - I've been doing advanced network troubleshooting for 20 years. This failure is only happening severely once every several hours, so you might never see it during normal use but it's fatal for very long-running jobs. However, I also noticed more frequent but less severe packet loss (events lasting under 0.4 seconds) that may affect general usage - these are recoverable, but cause a brief stall in communication. The workaround: Change the VM configuration to use Bridged Networking (I connected it to the Ethernet adapter) instead of Shared Networking. This bypasses the Network Address Translation (NAT) feature in Parallels and connects the VM directly to the local IP subnet. Why use Shared Networking (NAT) at all? It's on by default, and your network admins love you for it; normally, it's not a bad thing. NAT hides the VMs behind OS X's single IP address; turning it off makes your VM look like a separate computer connected to the network port (consuming another IP address as well). Some corporate networks block multiple devices per-port for security; hotels networks charge for each device separately; and without NAT the pool of available IP addresses depletes twice as fast. But NAT requires extra intelligence to hide the IP addresses, and sometimes it doesn't do the job properly (particularly for some new protocol it's not updated to handle). That's not the problem, but there's definitely some kind of internal problem with NAT that's severely delaying inbound network traffic. Since I don't *need* NAT, turning it off is an easy workaround. The specs: * Parallels 6 6.0.11828 (Rev. 615184, November 2, 2010), newly installed, with current PTools * Mac Mini 2.4GHz, 8GB, fresh installation of OS X 10.6.4 with current patches * Windows XP Media Center SP3 VM with current patches * Ghost 12.0.2.23036 * Server: WinXP MC SP3 w/ current patches * Network: Gigabit w/ 9K jumbo frames enabled end-to-end, but only 1514-byte frames being used here Hopefully, this post saves someone else a lot of hair-pulling. I've submitted case #1038205 with Parallels to log this info. Let me know if you have questions. Cheers, Richard
