<div dir="ltr"><div>Hello Eric,</div><div> </div><div>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.</div>
<div> </div><div>So just to summarize, this is what I understand would suffice for my Java program to be able to manage VMs through the bindings:</div><div>1. Install QEMU, libvirt daemon and libvirt QEMU driver (no worries about the distribution-specific package names).</div>
<div>2. Run libvirtd (probably with the -d flag?).</div><div>3. Run Java program with same user that ran libvirtd, using the QEMU session (as opposed to system) URI.</div><div> </div><div>Please correct me if I got anything wrong or if I'm missing another dependency.</div>
<div> </div><div>Thanks again, Lior.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 13, 2013 at 6:40 PM, Eric Blake <span dir="ltr"><<a href="mailto:eblake@redhat.com" target="_blank">eblake@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 05/11/2013 06:25 AM, Lior Vernia wrote:<br>
> Hello everyone,<br>
><br>
> I've been reading through the articles on the website trying to understand<br>
> what's needed to use the libvirt Java bindings with a QEMU hypervisor, but<br>
> still have some uncertainties/questions:<br>
><br>
> 1. It is my understanding that libvirtd has to be running on the machine<br>
> hosting the hypervisor. Correct?<br>
<br>
</div>Yes.<br>
<div class="im"><br>
><br>
> 2. For libvirtd to communicate with QEMU, QEMU has to be installed on the<br>
> machine hosting the hypervisor. Correct? I guess what I'm really asking is<br>
> whether the libvirt QEMU "driver" includes the QEMU source code, or rather<br>
> communicates with pre-installed executables.<br>
<br>
</div>If you are running a guest under qemu-kvm, then QEMU _is_ the<br>
hypervisor, so yes, it has to be installed on the host machine.  In<br>
Fedora parlance, if you install the libvirt-daemon-driver-qemu package<br>
on your host machine, that will pull in all the dependencies your host<br>
machine needs to run a guest.  But note that the dependencies are<br>
satisfied by also pulling in the qemu-kvm package (that is, libvirtd<br>
includes a qemu driver, and then that package also pulls in the actual<br>
qemu package).<br>
<div class="im"><br>
><br>
> 3. Assuming the answer to the two former questions is "yes", is there a way<br>
> to bypass libvirtd if the machine hosting the hypervisor is the same as the<br>
> one running the Java code? I'm asking because running libvirtd would<br>
> require privileged permissions, whereas QEMU itself can run with normal<br>
> user permissions. Is that a price I have to pay for the uniform interface<br>
> that libvirt presents?<br>
<br>
</div>WHY would you want to interact with qemu directly?  Yes, you could write<br>
a program that does just that, but then your java program would be<br>
reinventing the work that libvirt already did for you.  You are correct<br>
that the price you pay for uniform access through libvirt is that you<br>
have to use libvirt's interfaces.  However, you are incorrect that you<br>
have to run privileged - it is possible to use the qemu:///session URI<br>
so that you can run an unprivileged libvirtd with no permissions beyond<br>
what the calling user has.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Eric Blake   eblake redhat com    <a href="tel:%2B1-919-301-3266" value="+19193013266">+1-919-301-3266</a><br>
Libvirt virtualization library <a href="http://libvirt.org" target="_blank">http://libvirt.org</a><br>
<br>
</font></span></blockquote></div><br></div>