virtualbox.org

I am trying to use VB on a Linux host (amd64) and the guest is WinXP. In loading XP in the VB, I can connect to the LAN drive (QNAP 809pro) and all works fine for a while. In using several applications, the main EXE is on the VM-XP local drive and the data for the app is in the LAN drive (mapped).

I have tried this on 3 different new PC's so I believe the hardware has been ruled out. I have created 2 new VM's to rule out bad VB install.

I will lose connection to the LAN drive when trying to load/save data from the app. I can immediately restart the app and it works as expected as though nothing happend.
(Performing this on a dedicated XP box does not suffer disconnects, only on a VirtualBox-VM)

I have tried the following. It has helped, but there are still random disconnects.
-Hard coded the IP instead of the device name of LAN drive (helped a lot)
-Changed Adapter type from PCnet to Intel and installed latest drivers on XP host. (helped rate of disconnects)
-Changed Attached to to Bridge instead of NAT to make host on same network. (NAT works better on 1 PC, Bridge works better on 2 others)
-Toggled several of the settings above to see if it helped.

I believe I have narrowed it down to the NIC driver in the VM? as changes do make a difference in performance regarding disconnects.
I do not see any drops that I can tell when trying to access internet, or copying files to/from LAN drive. Only when a local app has it' data on the LAN drive
The main culprit in this case is QuickBooks 2009, but I have triggered it on another DB server app where tables existed on the LAN drive. Hard coding the IP as mentioned above did solve this problem for this app, not QB2009.

Any thoughts would be appreciated, as I am trying to sell the idea of using VB and Linux in our office and this is a major stumbling block in the process.

Regards,
Scott.

Host: Ubuntu 8.10 (amd64), I7 processor, 10 gig ram
Guest: XP Pro (4 gig base memory)
VB 2.2.2 r46594, guest additions: latest version
LAN is all 1 GB

I would start diagnostics by manually setting and then adjusting the MTU on the guest. Starting at 1500 and dropping gradually until the unit stops failing. Test for performance and increase if possible. Support for jumbo frames are supported with the Intel drivers in VBox but you need to read chapter 6 to get more info on this.

Could a ask why I need to muck around with the MTU in VM-XP to get this working? Has this worked for others (I have not found other posts supporting this)

Regards,
Scott.

You asked and I gave you a suggestion. As with any network connection collisions can cause delays packet loss which forces retransmissions and other problems. Adjusting the MTU a bit resolves them sometimes. But hey you know more than I do so just don't worry about it.

Perryg wrote:You asked and I gave you a suggestion. As with any network connection collisions can cause delays packet loss which forces retransmissions and other problems. Adjusting the MTU a bit resolves them sometimes.

I appreciated the suggestion, I was just asking if this was a known adjustment, or if you were aware of this fixing issues with others.

Perryg wrote: But hey you know more than I do so just don't worry about it.

Evidently I am a bit more mature as well ...

Regards,
Scott.

Evidently I misunderstood your wording. I also see that you have posted to another section and there is someone else that is having the same problem. Look it is just too easy to manually set the MTU down a bit on the client side. Sometime when forcing packets through at a fast rate they will become lost and a retransmission will need to take place. If this happens too often and at too high a rate, programs like Quickbooks can not deal with it and loose the connection. Similarly restarting this will allow them to take off again just to be met with the same problem. Try setting it at 1490 instead of automatic and then work your way up to 1500. This will allow a slightly lower overhead and can slow or stop packet loss. Just so we are on the same page here the MTU is the maximum transmission unit (size of the packet). You are not changing the speed of the network at all just the size of the packet and by only 10 bytes. If it helps but does not completely solve your issue go down a few bytes at a time until you have it resolved. If it doesn't work then put it back, no harm will have been done to your network.