this is not your final answer - I would start by looking at disk iops - use tools like iostat and sar (sysstat) - find out what your practical iops are - and check if your swap is busy also
I have seen similar behavior with sata drives in a software raid (md), every time a kvm guest was doing a lot of writes the vm's responsiveness lagged quite a bit. I didnt take the time to tweak, we switched to a raid controller with cache, battery and writeback - still the same drives, that helped a lot - my hunch is the caching of writes was the trick. (that was a single quad xeon with 12GB of ram running 2 windows DC's and 5 small application servers, none was all that busy, used a 3ware 9690).
Apparently, if you set cache=NONE for a disk image file on any host filesystem that does not support Direct IO, Virt-Manager will currently give a not very helpful error message saying "Something something... Invalid Argument" and refuse to start the Guest VM.
One example of such a filesystem --that does not support Direct IO-- is the tmpfs. Another such filesystem where maybe you can optionally disable Direct IO is GlusterFS (which I had not heard of before I also hit the same problem as Sergei did and was researching the error.) For tmpfs, not supporting Direct IO seems to be a technical limitation or design conflict at present and I don't know whether it will/can be rectified in future.
In my case, I had put a 3.6 GB Ramdisk for a Win7Pro Guest VM running on CentOS7 and had set cache=NONE for the ramdisk in Virt-Manager. The other options that the tmpfs img used were virtio and raw. The VM would refuse to start with the same/similar error saying "... Invalid Argument".
For technical details and notes directly from the Redhat Engineer and Developer that coded the patch for the feature cache=NONE & maintains (?) Virt-Manager (Daniel Berrange), see the discussion at the following link:
https://bugs.launchpad.net/nova/+bug/959637
To quote Daniel from the URL above:
" > could not open disk image /mnt/vmstore/instances/instance-0000001a/disk: Invalid argument
probably means that the filesystem does not support Direct IO. AFAIK,
all filesystems except tmpfs should support this.."
Also, Daniel continues:
"- So what we'll want todo then, is to [....] do a check whether the
storage volume supports Direct IO. If it does, then use cache=none,
otherwise fallback to cache=writethrough which does not use Direct
I/O, but is still crash safe."
In my case, I was able to verify that setting cache=NONE for the tmpfs img file was NOT starting the VM and showed the error as discussed. It WAS able to successfully start the VM if cache was set to either "Default" or explicitly "Write-through". There is no sense in going with "Write-back" since this filesystem both expendable and was anyways entirely in RAM, so obviously I did not use Write-back.
Hope that helps!
Best Answer
It looks like you might be mixing sysctl syntax and filesystem syntax for these options. Check what the actual path is to the sysfs file you are wanting to write to (is it
/sys/fs/cgroup/blkio/sysdefault/libvirt/qemu/debian1/blkio/throttle/read_bps_device
?).