The current libvirtd daemon is a single thread, either handling I/O of making libvirt API calls in response to a RPC message. This is passable when all the libvirt API calls are 'fast'. With any slow blocking calls though it becomes very painful indeed. Even if we add asynchronous operations to libvirt nothing is requiring the client apps to use these, and having done a proof of concept for this, its actually non-trivial.
The solution is to make the libvirtd daemon multi-threaded. This is conceptually easy. We have a single thread which does all I/O with the poll() loop and reading/writing data to/from the wire. When it has a complete RPC message read, it can put it ona job queue. A number of worker threads can be process jobs, which entails making a libvirt API call, and then putting the result back on the I/O send queue for the main thread to process.
I [Dan] has a patch which does this already. The main pain point is that the QEMU driver assumes its only ever accessed by a single thread, so I'll have to put mutex locking into QEMU driver (likewise for LXC, and OpenVZ drivers too). The Xen driver is more or less OK in this respect - aside from a sprinkling of strerror() which isn't re-entrant safe.