[qemu] Потери пакетов между хостовой и гостевой системой

другую модель nic попробуй

и еще подняться в этой виртуалке с live-cd чтобы сравнить с виндой.
Допиши -boot d -cdrom live-cd.iso

пробывал линух запускать там, таже история, потери есть

щаз поставил модель ника pcnet

--- 192.168.5.3 ping statistics ---
685 packets transmitted, 617 received, 9% packet loss, time 69289ms
rtt min/avg/max/mdev = 0.078/0.214/14.307/0.757 ms

пакеты очень странно пропадают, обычно так выглядит на физичиских серверах когда кто то выдергивает провод тоесть «все» нормально идет, а потом резко сразу куча потеряных, потом опять норм...и так повторяеться

и еще прикол нашел
если её не пинговать минут 5
а потом начать пинговать, то первые 10-20 пакетов почти 100% лост
а потом вроде оживает...
как будто вирт интерфейс спать уходит...странная ситуация...
мб что из за sysctl ?
вот что у меня в нем прописано отличное от стандартного

net.core.somaxconn=65536
#net.ipv4.tcp_no_metrics_save = 0
net.ipv4.tcp_fin_timeout = 30
#net.ipv4.tcp_keepalive_time = 600
#net.ipv4.tcp_orphan_retries = 4
#net.ipv4.tcp_tw_recycle = 1
#net.core.netdev_max_backlog = 5000
net.ipv4.tcp_syncookies = 1
#net.ipv4.tcp_max_syn_backlog = 2048
#net.ipv4.tcp_reordering = 20
#net.ipv4.tcp_congestion_control = cubic
#net.ipv4.tcp_sack = 0
#net.ipv4.tcp_synack_retries = 2
#net.core.rmem_max = 33554432
#net.core.wmem_max = 33554432
#net.ipv4.tcp_rmem = 8192 1048576 33554432
#net.ipv4.tcp_wmem = 8192 1048576 33554432
#net.ipv4.tcp_mem = 33554432 33554432 33554432
net.netfilter.nf_conntrack_max = 524288
net.ipv4.ip_local_port_range = 1800 65400
#net.ipv4.neigh.default.gc_thresh1 = 8192
#net.ipv4.neigh.default.gc_thresh2 = 8192
#net.ipv4.neigh.default.gc_thresh3 = 8192

а скока у тебя виртуалок? может у них маки пересекаются.

БЛЯХА...точно!! спасибо =)))

web:~# arp -a
fragw1.gatewayrouter.net (217.20.117.1) at 00:12:44:2d:cc:00 [ether] on eth0
? (192.168.5.3) at 52:54:00:12:34:56 [ether] on qemu0
? (192.168.5.2) at 52:54:00:12:34:56 [ether] on qemu0

> /usr/bin/qemu -enable-kvm -cpu $CPU \

-no-hpet -smp 1 -m $MEM \

-vnc :2 -net nic,vlan=0,model=rtl8139 -net tap,vlan=0 -localtime \

-hda $HDA -hdb $HDB &

sed 's/model=rtl8139/model=virtio/g'
sed 's/-hda/-drive file=$HDA,if=virtio,media=disk,boot=on/g'
sed 's/&/-daemonize/g'

так будет гораздо лучше.

а винда virtio держит?

Ты тестил сетевой virtio? Оно раньше глючило, рекомендовали e1000 юзать, по тестам не сильно медленнее было.

для винды (как и для Linux) нужны специальные драйвера, ссылка на неофициальную сборку есть на сайте kvm. Официально виндовые драйвера распространяются RedHat только среди подписчиков RHN (=кто заплатил деньги за RHEL), но пиратские копии есть в сети :).

Драйвера работают (пробовал с XP и вынь7), глюков не заметил, тестов не проводил. Но как-то сложно ожидать что специально заточенный virtio будет медленнее эмуляции железки.

Но как-то сложно ожидать что специально заточенный virtio будет медленнее эмуляции железки.

Ну почему же :). http://www.mail-archive.com/kvm@vger.kernel.org/msg27049.html

Сам не проверял, лень.

IMHO ту проблему поднял человек мягко говоря не слишком понимающий что он делает, не смотря на то что у него стоит «gentoo unstable».

Во-первых он запускает kvm через libvirt и потом жалуется (да, это типа должно быть удобно. Может если надо админить десяток виртуалок и удобно, но она не даёт доступа ко всем опциям qemu/kvm которые можно подкрутить. И к тому же почему-то запускает виртуалку из-под root, что странно с точки зрения безопасности).

Во-вторых этот умник меряет не скорость соединения хоста с гостем, а скорость соединения гостя с внешним миром. Так что проблема может вовсе не в гостевом драйвере virtio.

В общем — ламер :)

0_о
я тоже под рутом запускаю... виртуалку =)))
но мне не нужна куча виртуалок =)

а зачем? /dev/kvm и tap-устройства для бриджа должны принадлежать группе «kvm» — вот члены этой группы и должны иметь право запускать виртуалки на файлах-дисках которые им принадлежат.