Плохая производительность сети от виртуальной машины KVM

Я запускаю 32-разрядную виртуальную машину Linux на KVM. Хост-машина – это 64-разрядная Linux-машина, подключенная к локальной сети. Попытка переноса файлов с помощью scp с компьютера KVM на сервер в локальной сети дает ужасную производительность, около 500 кБ / с по сравнению с гигабитным Ethernet. Примерно 1% от ожидаемой ставки. Какие-либо предложения?

2 Solutions collect form web for “Плохая производительность сети от виртуальной машины KVM”

Подумайте об использовании virtio . Он позволяет прямое соединение между виртуальной машиной и хостом без необходимости эмулировать (медленное) аппаратное обеспечение. Я измерил высокие показатели производительности сети.

Например, вы можете включить сетевое устройство virtio с помощью параметра командной строки kvm «-net nic, model = virtio».

Если вы используете устройства с блоком virtio, обратите внимание, что новыми именами устройств являются «vda1» и т. Д., Но это не должно быть проблемой, поскольку текущие дистрибутивы Linux обнаруживают разделы в соответствии с их UUID.

Это может быть проблема производительности диска ввода-вывода внутри гостевой системы. Если вы используете образ диска, для достижения лучшей производительности применяются несколько шагов:

Firs, вам придется поиграть с параметром cache конфигурации диска вашего гостя.

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

Кэширование обратной записи будет записывать данные как завершенные, как только данные будут присутствовать в кеше главной страницы. Это безопасно, если вы доверяете своему хозяину. Если ваш хост выйдет из строя или потеряет питание, гость может столкнуться с повреждением данных. При использовании опции -snapshot по умолчанию используется кэширование обратной записи.

Страница хоста можно полностью исключить с помощью cache = none. Это попытается сделать диск IO непосредственно в памяти гостей. QEMU может выполнять внутреннюю копию данных.

Некоторые драйверы блоков плохо работают с cache = writethrough, наиболее заметно qcow2. Если производительность важнее, чем правильность, кеш = writeback следует использовать с qcow2. По умолчанию, если для образа qcow2 не указано явное кэширование, будет использоваться cache = writeback. Для всех остальных типов дисков кеш = writethrough является значением по умолчанию.

Затем вам также придется поиграть с лифтовой elevator=noop ядра: вам нужно будет добавить elevator=noop в командной строке grub linux следующим образом:

 # Edit your /etc/default/grub.conf (on Debian-based distribution) GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=noop" 

Лучшее объяснение этого можно получить по адресу: http://lonesysadmin.net/2008/02/21/elevatornoop/ ; но в нескольких словах ядро ​​хоста linux и гостевое linux-ядро пытаются оптимизировать ввод-вывод, и он, как правило, хуже, чем что-либо для гостя (гость должен оставить эту задачу на хосте).

  • Могу ли я использовать вывод Synaptics в KVM?
  • Socksifying qemu-kvm с использованием tsocks
  • KVM - прямые внешние снимки и соответствующие имена дисков
  • kvm guest Сетевой интерфейс no Аутентификация
  • libvirt qemu не может получить доступ к изображению внутри моего домашнего каталога, даже как root?
  • Не удалось подключиться к виртуальному менеджеру kvm
  • Debian wheezy - зависание при выключении
  • Загрузка EFI на KVM
  • Как перейти от Proxmox к VMWare?
  • Температура центрального процессора в гостевой гостевой системе KVM
  • Как найти IP-адрес виртуальной машины KVM, чтобы я мог использовать SSH?
  • Linux и Unix - лучшая ОС в мире.