cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <w...@widodh.nl>
Subject Re: Libvirt-java 0.5.0 has been released
Date Wed, 25 Sep 2013 06:45:32 GMT


On 09/24/2013 11:39 PM, Yoshikazu Nojima wrote:
> Hi,
> libvirt-java 0.5.1 is released, and I tried to upgrade it to 0.5.1,
>
> diff --git a/pom.xml b/pom.xml
> index a8778f1..1c85bc4 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -81,7 +81,7 @@
>       <cs.reflections.version>0.9.8</cs.reflections.version>
>       <cs.java-ipv6.version>0.10</cs.java-ipv6.version>
>       <cs.replace.properties>build/replace.properties</cs.replace.properties>
> -    <cs.libvirt-java.version>0.5.0</cs.libvirt-java.version>
> +    <cs.libvirt-java.version>0.5.1</cs.libvirt-java.version>
>       <cs.rados-java.version>0.1.3</cs.rados-java.version>
>       <cs.target.dir>target</cs.target.dir>
>       <cs.daemon.version>1.0.10</cs.daemon.version>
> --
> 1.8.3.msysgit.0
>
> but I faced another error.
>
> 24/09/2013 05:27:12 28923 jsvc.exec error: Cannot start daemon
> 24/09/2013 05:27:12 28922 jsvc.exec error: Service exit with a return value of 5
> log4j:WARN No appenders could be found for logger
> (org.apache.commons.httpclient.params.DefaultHttpParams).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig
> for more info.
> java.lang.reflect.InvocationTargetException
>          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>          at java.lang.reflect.Method.invoke(Method.java:616)
>          at org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:177)
> Caused by: java.lang.NoSuchMethodError:
> com.sun.jna.Pointer.nativeValue(Lcom/sun/jna/Pointer;)J
>          at org.libvirt.Library.free(Unknown Source)
>          at org.libvirt.Connect.getCapabilities(Unknown Source)
>          at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.IsHVMEnabled(LibvirtComputingResource.java:4509)
>          at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.configure(LibvirtComputingResource.java:747)
>          at com.cloud.agent.Agent.<init>(Agent.java:161)
>          at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:421)
>          at com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:376)
>          at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:357)
>          at com.cloud.agent.AgentShell.start(AgentShell.java:454)
>          ... 5 more
>

Could it be you have a older version of JNA on your system in the 
classpath which is causing problems?

> with libvirt 0.5.1, I received following error:
>
> 24/09/2013 05:26:13 28823 jsvc.exec error: Cannot start daemon
> 24/09/2013 05:26:13 28822 jsvc.exec error: Service exit with a return value of 5
> log4j:WARN No appenders could be found for logger
> (org.apache.commons.httpclient.params.DefaultHttpParams).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig
> for more info.
> java.lang.reflect.InvocationTargetException
>          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>          at java.lang.reflect.Method.invoke(Method.java:616)
>          at org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:177)
> Caused by: java.lang.UnsupportedClassVersionError:
> org/libvirt/LibvirtException : Unsupported major.minor version 51.0
>          at java.lang.ClassLoader.defineClass1(Native Method)
>          at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
>          at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>          at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
>          at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
>          at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
>          at java.security.AccessController.doPrivileged(Native Method)
>          at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
>          at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
>          at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
>          at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
>          at java.lang.Class.forName0(Native Method)
>          at java.lang.Class.forName(Class.java:188)
>          at com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:370)
>          at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:357)
>          at com.cloud.agent.AgentShell.start(AgentShell.java:454)
>          ... 5 more
>
>
>
> 2013/9/22 Wido den Hollander <wido@widodh.nl>:
>>
>>
>> On 09/21/2013 09:38 AM, Hugo Trippaers wrote:
>>>
>>> Ahh ok.
>>>
>>> Any idea how long that is going to take? At the moment our automated build
>>> are basically non functional as they all fail to build and thus also don't
>>> kickoff the downstream builds like the noredist build. Can we revert to an
>>> older version of libvirt in the meantime to work around this issue?
>>>
>>
>> I hope to get it done this week, but it is out of my hands.
>>
>> Reverting to libvirt-java 0.4.9 would be possible, but we would also have to
>> revert my VNC listen port patch since that already uses the new 0.5.0 API.
>>
>> Wido
>>
>>
>>> Cheers,
>>>
>>> Hugo
>>>
>>>
>>> On Sep 21, 2013, at 3:28 PM, Wido den Hollander <wido@widodh.nl> wrote:
>>>
>>>>
>>>>
>>>> On 09/21/2013 09:15 AM, Hugo Trippaers wrote:
>>>>>
>>>>> Hey Wido,
>>>>>
>>>>> Did they publish the updated jar with the same version number? If that
>>>>> is the case maven will not take care of it as by definition release
>>>>> artefacts will be cached indefinitely and never be replaced. Only snapshot
>>>>> dependencies will be updated.
>>>>>
>>>>
>>>> They didn't publish a new JAR yet. They want some feedback on 0.5.0 first
>>>> if it technically works, if so, they will release 0.5.1 which is Java 6
>>>> compatible.
>>>>
>>>> Wido
>>>>
>>>>> Cheers,
>>>>>
>>>>> HUgo
>>>>>
>>>>>
>>>>>
>>>>> On Sep 21, 2013, at 3:03 PM, Wido den Hollander <wido@widodh.nl>
wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 09/17/2013 08:35 PM, Mike Tutkowski wrote:
>>>>>>>
>>>>>>> I'm not familiar with how we package these binding classes in
>>>>>>> CloudStack.
>>>>>>>
>>>>>>> Is there a new JAR I need to download or source code?
>>>>>>>
>>>>>>
>>>>>> Sorry, forgot this one! Nothing to do on your side. Maven will take
>>>>>> care of this.
>>>>>>
>>>>>> The RPM and DEB packaging will automatically include these bindings.
>>>>>>
>>>>>> Wido
>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Sep 16, 2013 at 2:19 PM, Wido den Hollander <wido@widodh.nl>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09/16/2013 07:46 PM, Min Chen wrote:
>>>>>>>>
>>>>>>>>> I got the following test failure in building master:
>>>>>>>>>
>>>>>>>>> Running com.cloud.hypervisor.kvm.**resource.**
>>>>>>>>> LibvirtComputingResourceTest
>>>>>>>>> Tests run: 3, Failures: 0, Errors: 2, Skipped: 1, Time
elapsed:
>>>>>>>>> 0.059 sec
>>>>>>>>> <<< FAILURE!
>>>>>>>>> testCreateVMFromSpecLegacy(**com.cloud.hypervisor.kvm.**
>>>>>>>>> resource.LibvirtComputi
>>>>>>>>> ngResourceTest)  Time elapsed: 0.018 sec  <<<
ERROR!
>>>>>>>>> java.lang.**UnsupportedClassVersionError:
>>>>>>>>> org/libvirt/LibvirtException :
>>>>>>>>> Unsupported major.minor version 51.0
>>>>>>>>>           at java.lang.ClassLoader.**defineClass1(Native
Method)
>>>>>>>>>           at java.lang.ClassLoader.**defineClassCond(ClassLoader.**
>>>>>>>>> java:631)
>>>>>>>>>           at
>>>>>>>>> java.lang.ClassLoader.**defineClass(ClassLoader.java:**615)
>>>>>>>>>           at java.security.**SecureClassLoader.defineClass(**
>>>>>>>>> SecureClassLoader.java:141)
>>>>>>>>>           at java.net.URLClassLoader.**defineClass(URLClassLoader.**
>>>>>>>>> java:283)
>>>>>>>>>           at
>>>>>>>>> java.net.URLClassLoader.**access$000(URLClassLoader.**java:58)
>>>>>>>>>           at java.net.URLClassLoader$1.run(**URLClassLoader.java:197)
>>>>>>>>>           at java.security.**AccessController.doPrivileged(**Native
>>>>>>>>> Method)
>>>>>>>>>           at
>>>>>>>>> java.net.URLClassLoader.**findClass(URLClassLoader.java:**190)
>>>>>>>>>           at
>>>>>>>>> java.lang.ClassLoader.**loadClass(ClassLoader.java:**306)
>>>>>>>>>           at sun.misc.Launcher$**AppClassLoader.loadClass(**
>>>>>>>>> Launcher.java:301)
>>>>>>>>>           at
>>>>>>>>> java.lang.ClassLoader.**loadClass(ClassLoader.java:**247)
>>>>>>>>>           at
>>>>>>>>>
>>>>>>>>> com.cloud.hypervisor.kvm.**resource.**LibvirtComputingResourceTest.**
>>>>>>>>> testCreateVM
>>>>>>>>> FromSpecLegacy(**LibvirtComputingResourceTest.**java:64)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Wido, is this related to this libvirt change?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I think so. I'll test this tomorrow, but I think the RedHat
guys
>>>>>>>> build the
>>>>>>>> bindings with Java 7 since they all work on a recent Fedora
version.
>>>>>>>>
>>>>>>>> Wido
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> -min
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 9/16/13 4:28 AM, "Wido den Hollander" <wido@widodh.nl>
wrote:
>>>>>>>>>
>>>>>>>>>    On 09/16/2013 12:51 PM, Wei ZHOU wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Thanks Wido.
>>>>>>>>>>>
>>>>>>>>>>> Do you know the minimal requirement of libvirt
if we use
>>>>>>>>>>> libvirt-java
>>>>>>>>>>> 0.5.0
>>>>>>>>>>> ?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> There shouldn't be a difference in the required libvirt
version. I
>>>>>>>>>> implemented a couple of methods in the bindings which
were already
>>>>>>>>>> in
>>>>>>>>>> libvirt for a long time, but the bindings was just
missing them.
>>>>>>>>>>
>>>>>>>>>> Wido
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 2013/9/16 Wido den Hollander <wido@widodh.nl>
>>>>>>>>>>>
>>>>>>>>>>>    Hi,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I worked with the RedHat guys last week to
get libvirt-java 0.5.0
>>>>>>>>>>>> released
>>>>>>>>>>>> which has some nice new features for us:
>>>>>>>>>>>>
>>>>>>>>>>>> - Supports different XML on destination host
during migration
>>>>>>>>>>>> - Supports resizing volumes
>>>>>>>>>>>> - Supports more snapshot functionalities
>>>>>>>>>>>>
>>>>>>>>>>>> I took the liberty to depend on 0.5.0 in
master and also merge in
>>>>>>>>>>>> the
>>>>>>>>>>>> code
>>>>>>>>>>>> for the VNC listen, we now no longer listen
on 0.0.0.0 for VNC,
>>>>>>>>>>>> which
>>>>>>>>>>>> was a
>>>>>>>>>>>> security issue imho.
>>>>>>>>>>>>
>>>>>>>>>>>> The reason I'm bringing this to the list
is that we can simplify
>>>>>>>>>>>> some
>>>>>>>>>>>> code
>>>>>>>>>>>> around resizing volumes and snapshotting
where we currently have
>>>>>>>>>>>> some
>>>>>>>>>>>> nasty
>>>>>>>>>>>> scripts to do the work.
>>>>>>>>>>>>
>>>>>>>>>>>> See my commits in libvirt-java:
>>>>>>>>>>>> http://www.libvirt.org/git/?p=****<http://www.libvirt.org/git/?p=**>
>>>>>>>>>>>>
>>>>>>>>>>>> libvirt-java.git;a=summary<htt**p://www.libvirt.org/git/?p=**
>>>>>>>>>>>> libvirt-java.gi <http://www.libvirt.org/git/?p=libvirt-java.gi>
>>>>>>>>>>>> t;a=summary>
>>>>>>>>>>>>
>>>>>>>>>>>> So keep in mind libvirt-java has some new
features!
>>>>>>>>>>>>
>>>>>>>>>>>> Wido
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>>

Mime
View raw message