I am running a 32-bit Linux virtual machine on KVM. The host machine is a 64-bit Linux machine connected to a LAN. Attempting to transfer files with scp from the KVM machine to a server on the LAN gives abysmal performance, about 500kB/s over gigabit Ethernet. Around 1% of the expected rate. Any suggestions?


Consider using virtio. It allows a direct connection between the VM and the host without the need to emulate (slow) hardware. I measured high network performance improvements with it.

For example, you can enable the virtio network device by the kvm command line parameter "-net nic,model=virtio".

If you are using the virtio block devices, please note that the new device names are then "vda1" etc., but this should be not a problem since current Linux distributions detect the partitions according to their UUIDs.

  • Wow! Simply, wow! Why is this not the default? Note that specifying this option overrides the defaults, -net nic -net user. Remember to add -net user after the virtio option. – casualunixer Mar 26 '12 at 23:58
  • note for the future: virtio was default when I created the VM in virt-manager, but I had to change the MAC and for some reason, THAT defaults to rtl and not virtio. Maybe a bug? – Apache Oct 2 '19 at 0:07

It might be a problem of the Disk I/O performance inside the guest. If you are using a disk image, few steps apply to have better performance :

Firs, you will have to play around with the cache option of the disk configuration of your guest.

By default, writethrough caching is used for all block device. This means that the host page cache will be used to read and write data but write notification will be sent to the guest only when the data has been reported as written by the storage subsystem.

Writeback caching will report data writes as completed as soon as the data is present in the host page cache. This is safe as long as you trust your host. If your host crashes or loses power, then the guest may experience data corruption. When using the -snapshot option, writeback caching is used by default.

The host page can be avoided entirely with cache=none. This will attempt to do disk IO directly to the guests memory. QEMU may still perform an internal copy of the data.

Some block drivers perform badly with cache=writethrough, most notably, qcow2. If performance is more important than correctness, cache=writeback should be used with qcow2. By default, if no explicit caching is specified for a qcow2 disk image, cache=writeback will be used. For all other disk types, cache=writethrough is the default.

Then, you will also have to play around with elevator option of the kernel : you will have to append elevator=noop at your grub linux command line like this :

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

A better explaination of this is available at : http://lonesysadmin.net/2008/02/21/elevatornoop/ ; but in a few words, the host linux kernel and the guest linux kernel both try to optimize I/O and it tends to be worse than anything for the guest (the guest should leave this task to the host).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.