[libvirt-users] java binding and virtualbox-ose
I'm trying to connect to vbox hypervisor on an Ubuntu 10.04 machine through libvirt java binding (libvirt-java-0.4.6) by simply invoking: Connect conn = new Connect("vbox:///session", false); but I got this exception: libvir: warning : Failed to find the interface: Is the daemon running ? libvir: Remote error : unable to connect to '/var/run/libvirt/libvirt-sock': Connection refused libvir: warning : Failed to find a node driver: Is the libvirtd daemon running ? libvir: Remote error : unable to connect to '/var/run/libvirt/libvirt-sock': Connection refused libvir: warning : Failed to find a secret storage driver: Is the daemon running ? org.libvirt.LibvirtException: Failed to find a secret storage driver: Is the daemon running ? at org.libvirt.ErrorHandler.processError(ErrorHandler.java:28) at org.libvirt.Connect.<init>(Connect.java:195) at VBOX.main(VBOX.java:32) Otherwise, from virsh, I can correctly connect to the vbox hypervisor: $ export LIBVIRT_DEBUG=1 $virsh -c vbox:///session list --all 11:37:18.318: debug : virInitialize:336 : register drivers 11:37:18.318: debug : virRegisterDriver:837 : registering Test as driver 0 11:37:18.318: debug : virRegisterNetworkDriver:675 : registering Test as network driver 0 11:37:18.318: debug : virRegisterInterfaceDriver:706 : registering Test as interface driver 0 11:37:18.318: debug : virRegisterStorageDriver:737 : registering Test as storage driver 0 11:37:18.318: debug : virRegisterDeviceMonitor:768 : registering Test as device driver 0 11:37:18.318: debug : virRegisterSecretDriver:799 : registering Test as secret driver 0 11:37:18.318: debug : virRegisterDriver:837 : registering Xen as driver 1 11:37:18.318: debug : virRegisterDriver:837 : registering OPENVZ as driver 2 11:37:18.336: debug : vboxRegister:83 : VBoxCGlueInit found API version: 3.1.6 (3001006) 11:37:18.336: debug : vboxRegister:100 : VirtualBox API version: 3.1 11:37:18.336: debug : virRegisterDriver:837 : registering VBOX as driver 3 11:37:18.336: debug : virRegisterNetworkDriver:675 : registering VBOX as network driver 1 11:37:18.336: debug : virRegisterStorageDriver:737 : registering VBOX as storage driver 1 11:37:18.336: debug : virRegisterDriver:837 : registering remote as driver 4 11:37:18.336: debug : virRegisterNetworkDriver:675 : registering remote as network driver 2 11:37:18.336: debug : virRegisterInterfaceDriver:706 : registering remote as interface driver 1 11:37:18.336: debug : virRegisterStorageDriver:737 : registering remote as storage driver 2 11:37:18.336: debug : virRegisterDeviceMonitor:768 : registering remote as device driver 1 11:37:18.336: debug : virRegisterSecretDriver:799 : registering remote as secret driver 1 11:37:18.336: debug : virConnectOpenAuth:1337 : name=vbox:///session, auth=0x231638, flags=0 11:37:18.336: debug : do_open:1106 : name "vbox:///session" to URI components: scheme vbox opaque (null) authority (null) server (null) user (null) port 0 path /session 11:37:18.336: debug : do_open:1116 : trying driver 0 (Test) ... 11:37:18.336: debug : do_open:1122 : driver 0 Test returned DECLINED 11:37:18.336: debug : do_open:1116 : trying driver 1 (Xen) ... 11:37:18.336: debug : do_open:1122 : driver 1 Xen returned DECLINED 11:37:18.336: debug : do_open:1116 : trying driver 2 (OPENVZ) ... 11:37:18.336: debug : do_open:1122 : driver 2 OPENVZ returned DECLINED 11:37:18.336: debug : do_open:1116 : trying driver 3 (VBOX) ... 11:37:18.589: debug : vboxOpen:836 : in vboxOpen 11:37:18.589: debug : do_open:1122 : driver 3 VBOX returned SUCCESS 11:37:18.589: debug : do_open:1142 : network driver 0 Test returned DECLINED 11:37:18.589: debug : vboxNetworkOpen:5439 : network initialized 11:37:18.589: debug : do_open:1142 : network driver 1 VBOX returned SUCCESS 11:37:18.589: debug : do_open:1161 : interface driver 0 Test returned DECLINED 11:37:18.589: debug : doRemoteOpen:564 : proceeding with name = vbox:///session 11:37:18.590: debug : remoteIO:8455 : Do proc=66 serial=0 length=28 wait=(nil) 11:37:18.590: debug : remoteIO:8517 : We have the buck 66 0xb7516008 0xb7516008 11:37:18.595: debug : remoteIODecodeMessageLength:7939 : Got length, now need 64 total (60 more) 11:37:18.595: debug : remoteIOEventLoop:8381 : Giving up the buck 66 0xb7516008 (nil) 11:37:18.595: debug : remoteIO:8548 : All done with our call 66 (nil) 0xb7516008 11:37:18.596: debug : remoteIO:8455 : Do proc=1 serial=1 length=56 wait=(nil) 11:37:18.596: debug : remoteIO:8517 : We have the buck 1 0x95eb908 0x95eb908 11:37:18.659: debug : remoteIOEventLoop:8402 : Giving up the buck due to I/O error 1 0x95eb908 (nil) 11:37:18.660: debug : do_open:1161 : interface driver 1 remote returned ERROR 11:37:18.660: debug : do_open:1181 : storage driver 0 Test returned DECLINED 11:37:18.660: debug : vboxStorageOpen:6191 : vbox storage initialized 11:37:18.660: debug : do_open:1181 : storage driver 1 VBOX returned SUCCESS 11:37:18.660: debug : do_open:1201 : node driver 0 Test returned DECLINED 11:37:18.660: debug : doRemoteOpen:564 : proceeding with name = vbox:///session 11:37:18.661: debug : do_open:1201 : node driver 1 remote returned ERROR 11:37:18.661: debug : do_open:1228 : secret driver 0 Test returned DECLINED 11:37:18.661: debug : doRemoteOpen:564 : proceeding with name = vbox:///session 11:37:18.661: debug : do_open:1228 : secret driver 1 remote returned ERROR 11:37:18.661: debug : virConnectNumOfDomains:1714 : conn=0x95a1910 11:37:18.663: debug : virConnectNumOfDefinedDomains:4554 : conn=0x95a1910 11:37:18.664: debug : virConnectListDefinedDomains:4593 : conn=0x95a1910, names=0x95e9b58, maxnames=1 Id Name State ---------------------------------- 11:37:18.666: debug : virDomainLookupByName:1974 : conn=0x95a1910, name=tty 11:37:18.669: debug : virGetDomain:345 : New hash entry 0x95dad48 11:37:18.669: debug : virDomainGetInfo:2825 : domain=0x95dad48, info=0xbfeca708 - tty shut off 11:37:18.673: debug : virDomainFree:2062 : domain=0x95dad48 11:37:18.673: debug : virUnrefDomain:422 : unref domain 0x95dad48 tty 1 11:37:18.673: debug : virReleaseDomain:376 : release domain 0x95dad48 tty 11:37:18.673: debug : virReleaseDomain:392 : unref connection 0x95a1910 2 11:37:18.673: debug : virConnectClose:1355 : conn=0x95a1910 11:37:18.673: debug : virUnrefConnect:259 : unref connection 0x95a1910 1 11:37:18.673: debug : vboxNetworkClose:5448 : network uninitialized 11:37:18.673: debug : vboxStorageClose:6200 : vbox storage uninitialized 11:37:18.673: debug : vboxClose:843 : VBOX: in vboxClose 11:37:18.681: debug : virReleaseConnect:216 : release connection 0x95a1910 even if with some warnings/errors. Do you have any hint? Thank you -- Andrea Turli Ricercatore Direzione Ricerca e Innovazione andrea.turli@eng.it Engineering Ingegneria Informatica spa Via Riccardo Morandi, 32 00148 Roma (RM) Tel. +39 06 8307 4710 Fax +39 06 8307 4200 www.eng.it
2010/11/14 Andrea Turli <andrea.turli@eng.it>:
I'm trying to connect to vbox hypervisor on an Ubuntu 10.04 machine through libvirt java binding (libvirt-java-0.4.6) by simply invoking:
Connect conn = new Connect("vbox:///session", false); but I got this exception:
libvir: warning : Failed to find the interface: Is the daemon running ? libvir: Remote error : unable to connect to '/var/run/libvirt/libvirt-sock': Connection refused libvir: warning : Failed to find a node driver: Is the libvirtd daemon running ? libvir: Remote error : unable to connect to '/var/run/libvirt/libvirt-sock': Connection refused libvir: warning : Failed to find a secret storage driver: Is the daemon running ? org.libvirt.LibvirtException: Failed to find a secret storage driver: Is the daemon running ? at org.libvirt.ErrorHandler.processError(ErrorHandler.java:28) at org.libvirt.Connect.<init>(Connect.java:195) at VBOX.main(VBOX.java:32)
This is a bit tricky and took me a moment to understand. libvirt's error handling can report warnings. This feature is not used often in libvirt, basically only in the virConnectOpen* functions to report missing subdrivers. The Java bindings now have two problems: 1) The error processing in the bindings is done unconditional, it always checks for an error even if the called function succeeded. Also this results in an unnecessary call to the JNA interface for each successful libvirt call. 2) The error processing raises an exception for all error, even for errors with level VIR_ERR_WARNING. This results in the exception you see. The call to virConnectOpen succeeds but libvirt reports a warning about missing sudrivers and the bindings turn this into an exception. You can apply this workaround to the Java bindings code: diff --git a/src/main/java/org/libvirt/ErrorHandler.java b/src/main/java/org/libvirt/ErrorHandler.java index e30291b..de66518 100644 --- a/src/main/java/org/libvirt/ErrorHandler.java +++ b/src/main/java/org/libvirt/ErrorHandler.java @@ -25,7 +25,11 @@ public class ErrorHandler { if (errorCode > 0) { Error error = new Error(vError); libvirt.virResetLastError(); - throw new LibvirtException(error); + + /* FIXME: Don't throw exceptions for VIR_ERR_WARNING level errors */ + if (error.getLevel() == Error.ErrorLevel.VIR_ERR_ERROR) { + throw new LibvirtException(error); + } } } } The actually fix is more involved as it includes making the error processing conditional. Matthias
Matthias, On 11/14/2010 11:47 PM, Matthias Bolte wrote:
2010/11/14 Andrea Turli<andrea.turli@eng.it>:
I'm trying to connect to vbox hypervisor on an Ubuntu 10.04 machine through libvirt java binding (libvirt-java-0.4.6) by simply invoking:
Connect conn = new Connect("vbox:///session", false); but I got this exception:
libvir: warning : Failed to find the interface: Is the daemon running ? libvir: Remote error : unable to connect to '/var/run/libvirt/libvirt-sock': Connection refused libvir: warning : Failed to find a node driver: Is the libvirtd daemon running ? libvir: Remote error : unable to connect to '/var/run/libvirt/libvirt-sock': Connection refused libvir: warning : Failed to find a secret storage driver: Is the daemon running ? org.libvirt.LibvirtException: Failed to find a secret storage driver: Is the daemon running ? at org.libvirt.ErrorHandler.processError(ErrorHandler.java:28) at org.libvirt.Connect.<init>(Connect.java:195) at VBOX.main(VBOX.java:32)
This is a bit tricky and took me a moment to understand.
Thank you for your time.
libvirt's error handling can report warnings. This feature is not used often in libvirt, basically only in the virConnectOpen* functions to report missing subdrivers.
The Java bindings now have two problems:
1) The error processing in the bindings is done unconditional, it always checks for an error even if the called function succeeded. Also this results in an unnecessary call to the JNA interface for each successful libvirt call.
2) The error processing raises an exception for all error, even for errors with level VIR_ERR_WARNING.
This results in the exception you see. The call to virConnectOpen succeeds but libvirt reports a warning about missing sudrivers and the bindings turn this into an exception.
You can apply this workaround to the Java bindings code:
diff --git a/src/main/java/org/libvirt/ErrorHandler.java b/src/main/java/org/libvirt/ErrorHandler.java index e30291b..de66518 100644 --- a/src/main/java/org/libvirt/ErrorHandler.java +++ b/src/main/java/org/libvirt/ErrorHandler.java @@ -25,7 +25,11 @@ public class ErrorHandler { if (errorCode> 0) { Error error = new Error(vError); libvirt.virResetLastError(); - throw new LibvirtException(error); + + /* FIXME: Don't throw exceptions for VIR_ERR_WARNING level errors */ + if (error.getLevel() == Error.ErrorLevel.VIR_ERR_ERROR) { + throw new LibvirtException(error); + } } } }
I've applied this patch and it worked for me. So, do you think we should expect this fix in the next release? if yes, is it already scheduled?
The actually fix is more involved as it includes making the error processing conditional.
Matthias
Thank you again, Andrea -- Andrea Turli Ricercatore Direzione Ricerca e Innovazione andrea.turli@eng.it Engineering Ingegneria Informatica spa Via Riccardo Morandi, 32 00148 Roma (RM) Tel. +39 06 8307 4710 Fax +39 06 8307 4200 www.eng.it
On 11/15/2010 04:58 AM, Andrea Turli wrote:
Matthias,
On 11/14/2010 11:47 PM, Matthias Bolte wrote:
2010/11/14 Andrea Turli<andrea.turli@eng.it>:
I'm trying to connect to vbox hypervisor on an Ubuntu 10.04 machine through libvirt java binding (libvirt-java-0.4.6) by simply invoking:
Connect conn = new Connect("vbox:///session", false); but I got this exception:
libvir: warning : Failed to find the interface: Is the daemon running ? libvir: Remote error : unable to connect to '/var/run/libvirt/libvirt-sock': Connection refused libvir: warning : Failed to find a node driver: Is the libvirtd daemon running ? libvir: Remote error : unable to connect to '/var/run/libvirt/libvirt-sock': Connection refused libvir: warning : Failed to find a secret storage driver: Is the daemon running ? org.libvirt.LibvirtException: Failed to find a secret storage driver: Is the daemon running ? at org.libvirt.ErrorHandler.processError(ErrorHandler.java:28) at org.libvirt.Connect.<init>(Connect.java:195) at VBOX.main(VBOX.java:32)
This is a bit tricky and took me a moment to understand. Thank you for your time. libvirt's error handling can report warnings. This feature is not used often in libvirt, basically only in the virConnectOpen* functions to report missing subdrivers.
The Java bindings now have two problems:
1) The error processing in the bindings is done unconditional, it always checks for an error even if the called function succeeded. Also this results in an unnecessary call to the JNA interface for each successful libvirt call.
2) The error processing raises an exception for all error, even for errors with level VIR_ERR_WARNING.
This results in the exception you see. The call to virConnectOpen succeeds but libvirt reports a warning about missing sudrivers and the bindings turn this into an exception.
You can apply this workaround to the Java bindings code:
diff --git a/src/main/java/org/libvirt/ErrorHandler.java b/src/main/java/org/libvirt/ErrorHandler.java index e30291b..de66518 100644 --- a/src/main/java/org/libvirt/ErrorHandler.java +++ b/src/main/java/org/libvirt/ErrorHandler.java @@ -25,7 +25,11 @@ public class ErrorHandler { if (errorCode> 0) { Error error = new Error(vError); libvirt.virResetLastError(); - throw new LibvirtException(error); + + /* FIXME: Don't throw exceptions for VIR_ERR_WARNING level errors */ + if (error.getLevel() == Error.ErrorLevel.VIR_ERR_ERROR) { + throw new LibvirtException(error); + } } } }
I've applied this patch and it worked for me. So, do you think we should expect this fix in the next release? if yes, is it already scheduled?
The next release has not been scheduled, but I have applied the patch upstream. -- bk
participants (3)
-
Andrea Turli -
Bryan Kearney -
Matthias Bolte