Проблемы с сетью Hyper-V Ubuntu при копировании больших объемов данных

Я пытаюсь скопировать большой объем (около 50 ГБ) данных по моей сети с виртуальной машины, размещенной на Hyper-V, под управлением Ubuntu 11.04 (Natty Narwhal) на другой (не виртуальный) хост Ubuntu, который я планирую использовать для тестирования. обновляется до одного из наших веб-приложений. Проблема, с которой я столкнулся, связана с виртуальной машиной, которую я буду называть в дальнейшем «source.host». На этом компьютере работает 64-разрядный сервер Ubuntu с загруженным ядром 2.6.38-8 и компонентами интеграции Microsoft Linux для модулей ядра Hyper-V (hv_utils, hv_timesource, hv_netvsc, hv_blkvsc, hv_storvsc и hv_vmbus). Он использует «синтетический сетевой адаптер» Hyper-V в качестве сетевого интерфейса.

Чтобы сделать копию, я вхожу в систему с данными и запускаю следующие команды (вызовите удаленную машину «destination.host».):

$ cd /path/to/data
$ tar -cvf - datafolder/ | ssh user@destination.host "cat > ~/data.tar"

Это работает какое-то время, а потом внезапно останавливается после переноса где-то с 2-6 ГБ. Терминал на машине source.host отображает Write failed: broken pipe ошибка. Странная часть заключается в следующем: после того, как это произойдет, машина "source.host" больше не сможет общаться с остальной частью сети. Я не могу пинговать никакие другие хосты в сети с машины «source.host», и я не могу пинговать машину «source.host» с любого другого хоста в сети. Я также не могу получить доступ ни к одной из веб-служб, размещенных на "source.host".

Бег ifconfig на «source.host» показывает, что сетевой адаптер работает как обычно с правильным IP-адресом и всем остальным. Я попытался перезапустить сетевую службу с помощью

$ /etc/init.d/networking restart

но проблема никуда не делась. Перезагрузка компьютера позволяет ему снова общаться с сетью - он может пинговать и получать пинг с других хостов, а веб-службы также доступны и могут использоваться в обычном режиме, но повторная попытка копирования приводит к тому же сбою, что требует еще один перезапуск.

В качестве эксперимента попробовал заменить tar - ssh трубопровод вверху с прямым scp:

$ scp -r datafolder/ user@destination.host:~

но безрезультатно

Думая, что проблема может быть связана с заполнением буферов отправки пакетов ядра, я попытался увеличить размер буфера до 12 МБ (по сравнению со 128 КБ по умолчанию) с помощью

# echo 12582911 > /proc/sys/net/core/wmem_max

но это тоже не подействовало.

Я предполагаю, что это может быть проблема с синтетическим сетевым драйвером Microsoft, но я точно не знаю. У кого-нибудь есть предложения?

Заранее большое спасибо!