[libvirt-users] Pre-requisites to use Java bindings with QEMU
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? 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. 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? Yours, Lior.
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
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
to bypass libvirtd if the machine hosting the hypervisor is the same as
way 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
On 05/15/2013 09:57 AM, Lior Vernia wrote:
Hello Eric,
[Please don't top-post on technical lists]
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).
Correct.
2. Run libvirtd (probably with the -d flag?).
No need to do this manually; connecting to a qemu:///session URI will do it automatically under the hood on your behalf.
3. Run Java program with same user that ran libvirtd, using the QEMU session (as opposed to system) URI.
Correct.
Please correct me if I got anything wrong or if I'm missing another dependency.
Nope, it sounds like you got it. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (2)
-
Eric Blake -
Lior Vernia