File transfers (ftp/scp) btwn Linux VBox host and XP VM slow
Posted: 14. May 2009, 17:32
Hello:
I have VirtualBox "v2.2.2 r46594" running on 64bit Linux (Fedora 10, but that shouldn't matter much).
And I have a Windows XP64 VM guest running. I use bridged networking, and have the XP64 IP address,
default router, and DNS name servers all statically set.
From within the XP guest, I can ftp/scp to external sites at speeds you would expect.
From the Linux host, I also can ftp/scp to external sites at speeds you would expect.
But between the Linux host and XP guest, ftp/scp transfers are not going right - it's a start
stop deal. For example, when transferring a 10mb file, a few kilobytes are transferred,
then the transfer pauses for 30, 40, 50 seconds, followed by the next few kilobytes, and
again a pause of 30, 40, 50 seconds; and so on. It basically never completes, and when I do
let it complete (with very small files), the copy on the destination is corrupted (even in FTP
binary mode, for example).
Note that this behavior is the same whether the transfer is initiated from Linux or Windows,
and also the same whether FTP or SCP is used. It is also independent of the FTP or SCP server
in use ... for example, on the XP side I tried Filezilla Clients and Servers and other SCP/FTP servers,
but that doesn't correct the problem. Make sense since if it's independent of the transfer
protocol (FTP versus SCP), then changing the client or server implementation for a particular protocol
(say FTP) won't matter either.
So it would appear something is awry lower in the communications stack between the guest and
VirtualBox host.
For months I could ftp/scp files back and forth between the Linux host and Windows guest
fine (at normal speeds)... but something changed - perhaps when I upgraded to a newer
version of Virtual box when prompted that there was an updated version. Not sure.
I looked around but could not find a recent remedy to this problem (perhaps it exists and
escaped my search efforts). But I thank you in advance for you collective help.
Noel
nmvega _AT_ ComputingArchitects _DOT_ Com
I have VirtualBox "v2.2.2 r46594" running on 64bit Linux (Fedora 10, but that shouldn't matter much).
And I have a Windows XP64 VM guest running. I use bridged networking, and have the XP64 IP address,
default router, and DNS name servers all statically set.
From within the XP guest, I can ftp/scp to external sites at speeds you would expect.
From the Linux host, I also can ftp/scp to external sites at speeds you would expect.
But between the Linux host and XP guest, ftp/scp transfers are not going right - it's a start
stop deal. For example, when transferring a 10mb file, a few kilobytes are transferred,
then the transfer pauses for 30, 40, 50 seconds, followed by the next few kilobytes, and
again a pause of 30, 40, 50 seconds; and so on. It basically never completes, and when I do
let it complete (with very small files), the copy on the destination is corrupted (even in FTP
binary mode, for example).
Note that this behavior is the same whether the transfer is initiated from Linux or Windows,
and also the same whether FTP or SCP is used. It is also independent of the FTP or SCP server
in use ... for example, on the XP side I tried Filezilla Clients and Servers and other SCP/FTP servers,
but that doesn't correct the problem. Make sense since if it's independent of the transfer
protocol (FTP versus SCP), then changing the client or server implementation for a particular protocol
(say FTP) won't matter either.
So it would appear something is awry lower in the communications stack between the guest and
VirtualBox host.
For months I could ftp/scp files back and forth between the Linux host and Windows guest
fine (at normal speeds)... but something changed - perhaps when I upgraded to a newer
version of Virtual box when prompted that there was an updated version. Not sure.
I looked around but could not find a recent remedy to this problem (perhaps it exists and
escaped my search efforts). But I thank you in advance for you collective help.
Noel
nmvega _AT_ ComputingArchitects _DOT_ Com