On 11/13/2013 08:31 AM, Gergely Horváth wrote:
The second problem came when I looked at `iotop`, to see how much IO
read and write is going on. The computer, that was doing the copying
easily had like 20-30 threads writing pieces to the disk. Some of the
threads are obviously "processor emulators" - they been running since
the birth of the VM, but what are these other threads?
These are qemu threads, right? Then asking on the qemu list is a more
appropriate list; my understanding is that qemu creates transient
threads to handle aio requests on an as-needed basis, and that it is
qemu that decides when these threads are needed or not (and not libvirt).
Two questions than, to sum up everything:
* How can I control and maybe decrease the number of threads spawned for
a virtual machine?
I don't know if qemu exposes a knob for limiting the number of aio
helper threads it can spawn, or even if that is a good idea.
* How can I know what is the default IO caching for a VM, and what
caching mechanism/policy should I set to minimise IO latency (i.e. I do
not really care if the data is written to the disk later than the guest
thinks)
What domain XML are you using? Yes, there are different disk cache
policies (writethrough vs. none) which have definite performance vs.
risk tradeoffs according to the amount of IO latency you want the guest
to see; but again, the qemu list may be a better help in determining
which policy is best for your needs. Once you know the policy you want,
then we can help you figure out how to represent it in the domain XML.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org