cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <shadow...@gmail.com>
Subject Re: master issue calling volume resize via libvirt - Was: libvirt-java upgrade
Date Tue, 11 Mar 2014 16:36:29 GMT
I see that the Ubuntu Cloud Archive revolves around providing
OpenStack packages. In fact, visiting the page
"https://wiki.ubuntu.com/ServerTeam/CloudArchive" doesn't really give
me any indication of what to do if I just want to upgrade libvirt, it
wants me to choose a version of OpenStack. Are we ok with using that?

On Tue, Mar 11, 2014 at 9:47 AM, Marcus <shadowsor@gmail.com> wrote:
> Now that I think about it a bit more, I'm not really interested in
> hobbling ourselves until 2017 to support libvirt 0.9.8 on ubuntu
> 12.04. It's a bit easier with the RHEL/CentOS model, where they
> deprecate their point releases and increment software versions on each
> point release, so you're more often getting newer software, but it
> will be the same issue soon when CentOS 7 comes out. CentOS 6 will
> still get updates and software bumps, but it will likely get left
> behind eventually.
>
> On Tue, Mar 11, 2014 at 9:27 AM, Marcus <shadowsor@gmail.com> wrote:
>> The hard part is that there are so many libvirt versions and support
>> for very fundamental elements varies wildly. I'd like the community to
>> weigh in on it, I've felt for awhile that we should target a minimum
>> libvirt version in addition to the specific platforms. In a sense we
>> have, as in the past we've added features only as CentOS 6 got updates
>> (it was behind Ubuntu, now it's ahead), but I think it's getting
>> fairly common for people to ditch old, builtin libvirt versions simply
>> because they lack so much functionality. For me the roadblock to
>> saying something like "cloudstack 4.4 requires libvirt 1.0.0 or
>> better" is making sure people have easy access to a newer libvirt on
>> their platform, which sounds like it's not an issue for Ubuntu users.
>>
>> It sounds like there's a new issue with this that Lucian ran into,
>> regarding the allocate flag passed in v.resize. See the last comments
>> on this issue https://issues.apache.org/jira/browse/CLOUDSTACK-6181
>>
>> On Mon, Mar 10, 2014 at 5:10 AM, Wido den Hollander <wido@widodh.nl> wrote:
>>>
>>>
>>> On 03/09/2014 01:19 AM, Marcus wrote:
>>>>
>>>> I imagine the new LTS will have it, but I'm not sure what our OS support
>>>> policy is.
>>>
>>>
>>> Well, I think we should also keep supporting 12.04 since it's not EOL until
>>> 2017.
>>>
>>> But we can always say that we require the Ubuntu Cloud Archive to be used?
>>>
>>> wido
>>>
>>>
>>>> On Mar 8, 2014 11:59 AM, "Wido den Hollander" <wido@widodh.nl> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 03/08/2014 12:32 AM, Marcus wrote:
>>>>>
>>>>>> On Fri, Mar 7, 2014 at 4:30 PM, Marcus <shadowsor@gmail.com>
wrote:
>>>>>>
>>>>>>> Hrm... sent instead of pasted. Commit
>>>>>>>
>>>>>>> commit 3989d6c48118f31464c87c71b6279a11eb13eb35
>>>>>>> Author: Wido den Hollander <wido@widodh.nl>
>>>>>>> Date:   Mon Feb 3 17:04:11 2014 +0100
>>>>>>>
>>>>>>>       kvm: Resize volumes using libvirt
>>>>>>>
>>>>>>> virsh blockresize works on this system, so I can only assume
that the
>>>>>>> libvirt.so.0.9.8 that ships with Ubuntu 12.04 doesn't support
>>>>>>> virStorageVolResize.
>>>>>>>
>>>>>>> # strings /usr/lib/libvirt.so.0.9.8  | grep virStorageVolR
>>>>>>> virStorageVolRef
>>>>>>> virStorageVolRef
>>>>>>> virStorageVolRef
>>>>>>>
>>>>>>
>>>>> Hmm, that's a good one. I'm not able to check this right now, but on
all
>>>>> my test systems I run libvirt 1.0.2 from the Ubuntu Cloud Archive, so
>>>>> that
>>>>> could be the problem.
>>>>>
>>>>> Wido
>>>>>
>>>>>
>>>>>>> On Fri, Mar 7, 2014 at 4:28 PM, Marcus <shadowsor@gmail.com>
wrote:
>>>>>>>
>>>>>>>> Wido,
>>>>>>>>       I'm seeing this in Ubuntu 12.04 after commit
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2014-02-10 01:19:16,793 DEBUG [kvm.resource.LibvirtComputingResource]
>>>>>>>> (agentRequest-Handler-2:null) Volume
>>>>>>>> /mnt/2fe9a944-505e-38cb-bf87-72623634be4a/e47e6501-c8ae-
>>>>>>>> 41a7-9abc-0f7fdad5fb30
>>>>>>>> can be resized by libvirt. Asking libvirt to resize the volume.
>>>>>>>> 2014-02-10 01:19:16,800 WARN  [cloud.agent.Agent]
>>>>>>>> (agentRequest-Handler-2:null) Caught:
>>>>>>>> java.lang.UnsatisfiedLinkError: Error looking up function
>>>>>>>> 'virStorageVolResize': /usr/lib/libvirt.so.0.9.8: undefined
symbol:
>>>>>>>> virStorageVolResize
>>>>>>>> at com.sun.jna.Function.<init>(Function.java:208)
>>>>>>>> at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:536)
>>>>>>>> at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:513)
>>>>>>>> at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:499)
>>>>>>>> at com.sun.jna.Library$Handler.invoke(Library.java:199)
>>>>>>>> at com.sun.proxy.$Proxy0.virStorageVolResize(Unknown Source)
>>>>>>>> at org.libvirt.StorageVol.resize(Unknown Source)
>>>>>>>> at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(
>>>>>>>> LibvirtComputingResource.java:1808)
>>>>>>>> at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.
>>>>>>>> executeRequest(LibvirtComputingResource.java:1331)
>>>>>>>> at com.cloud.agent.Agent.processRequest(Agent.java:501)
>>>>>>>> at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808)
>>>>>>>> at com.cloud.utils.nio.Task.run(Task.java:84)
>>>>>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(
>>>>>>>> ThreadPoolExecutor.java:1145)
>>>>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
>>>>>>>> ThreadPoolExecutor.java:615)
>>>>>>>> at java.lang.Thread.run(Thread.java:744)
>>>>>>>>
>>>>>>>
>>>>
>>>

Mime
View raw message