Hello Eric,
 
Thank you for your thorough answer. Of course if I don't have to run libvirtd as a privileged user, then I don't have any problem with interacting with QEMU through the standard mechanism.
 
So just to summarize, this is what I understand would suffice for my Java program to be able to manage VMs through the bindings:
1. Install QEMU, libvirt daemon and libvirt QEMU driver (no worries about the distribution-specific package names).
2. Run libvirtd (probably with the -d flag?).
3. Run Java program with same user that ran libvirtd, using the QEMU session (as opposed to system) URI.
 
Please correct me if I got anything wrong or if I'm missing another dependency.
 
Thanks again, Lior.


On Mon, May 13, 2013 at 6:40 PM, Eric Blake <eblake@redhat.com> wrote:
On 05/11/2013 06:25 AM, Lior Vernia wrote:
> Hello everyone,
>
> I've been reading through the articles on the website trying to understand
> what's needed to use the libvirt Java bindings with a QEMU hypervisor, but
> still have some uncertainties/questions:
>
> 1. It is my understanding that libvirtd has to be running on the machine
> hosting the hypervisor. Correct?

Yes.

>
> 2. For libvirtd to communicate with QEMU, QEMU has to be installed on the
> machine hosting the hypervisor. Correct? I guess what I'm really asking is
> whether the libvirt QEMU "driver" includes the QEMU source code, or rather
> communicates with pre-installed executables.

If you are running a guest under qemu-kvm, then QEMU _is_ the
hypervisor, so yes, it has to be installed on the host machine.  In
Fedora parlance, if you install the libvirt-daemon-driver-qemu package
on your host machine, that will pull in all the dependencies your host
machine needs to run a guest.  But note that the dependencies are
satisfied by also pulling in the qemu-kvm package (that is, libvirtd
includes a qemu driver, and then that package also pulls in the actual
qemu package).

>
> 3. Assuming the answer to the two former questions is "yes", is there a way
> to bypass libvirtd if the machine hosting the hypervisor is the same as the
> one running the Java code? I'm asking because running libvirtd would
> require privileged permissions, whereas QEMU itself can run with normal
> user permissions. Is that a price I have to pay for the uniform interface
> that libvirt presents?

WHY would you want to interact with qemu directly?  Yes, you could write
a program that does just that, but then your java program would be
reinventing the work that libvirt already did for you.  You are correct
that the price you pay for uniform access through libvirt is that you
have to use libvirt's interfaces.  However, you are incorrect that you
have to run privileged - it is possible to use the qemu:///session URI
so that you can run an unprivileged libvirtd with no permissions beyond
what the calling user has.

--
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org