7:34 p.m.
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(a)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
6:47 a.m.
2010/11/14 Andrea Turli <andrea.turli(a)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
5:58 p.m.
Matthias,
On 11/14/2010 11:47 PM, Matthias Bolte wrote:
2010/11/14 Andrea Turli<andrea.turli(a)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(a)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
2:43 a.m.
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(a)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
5045
days inactive
5046
days old
3 comments
3 participants
participants (3)
-
Andrea Turli -
Bryan Kearney -
Matthias Bolte