Re: [Libvir] PATCH 0/20: Re-factor libvirtd / QEMU driver
On Fri, Jun 22, 2007 at 02:34:05AM +0100, Daniel P. Berrange wrote:
The work to refactor the QEMU driver to use the regular libvirt
driver API
is now complete. The next 20 (!) patches provide fairly fine-grained steps
refactoring the code. Aside from that which adds an event loop, and the
very last one, they should all be pretty much straightforward refactoring
with no functional change.
With this patch series fully applied there is now only a single daemon
which can serve both remote & QEMU drivers in one go, with no deadlock
issues.
BTW, as a rough comparison of the old QEMU impl vs the new one in terms
of performance, here are the timings for listing active guests 10000
times over
Original QEMU code:
time virsh --connect qemu:///system < src/data > /dev/null
real 0m0.963s
user 0m0.246s
sys 0m0.540s
New generic remote code:
time ./src/virsh --connect qemu:///system < src/data > /dev/null
real 0m1.142s
user 0m0.470s
sys 0m0.377s
Which is easily close enough to ignore the difference
New generic remote code using plain TCP localhost:
time ./src/virsh --connect qemu+tcp://localhost/system < src/data > /dev/null
real 0m1.857s
user 0m0.543s
sys 0m0.779s
New generic remote code using TLS localhost:
time ./src/virsh --connect qemu://localhost/system < src/data > /dev/null
real 0m5.031s
user 0m1.814s
sys 0m1.303s
New generic remote code using SSH localhost:
time ./virsh --connect qemu+ssh://localhost/system < data > /dev/null
real 0m5.987s
user 0m0.621s
sys 0m1.147s
So there's a non-trivial hit from doing TLS/SSH. Only 0.25s is accounted
for by the initial handshake / negotiation. Still, small price to pay for
having data security of course...
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|