Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of shadowsor@gmail.com designates
 209.85.128.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <531D9DA6.8050606@widodh.nl>
References: 
 <CALFpzo61NR1nzJVA5KjxypsWzWz6HD1Y19Z5A0dqPE3Po8AwVw@mail.gmail.com>
	<531B6863.5020809@widodh.nl>
	<CALFpzo4JocP8Kg418KrLoPZXZ4twx+Z0uSFP5KTCpKcJVz=1MA@mail.gmail.com>
	<531D9DA6.8050606@widodh.nl>
Date: Tue, 11 Mar 2014 09:27:08 -0600
Message-ID: 
 <CALFpzo5LArp=A8t_GFkbRQnChCVA0M9Mbfp79Ss3=_xV5pqUzA@mail.gmail.com>
Subject: Re: master issue calling volume resize via libvirt - Was:
 libvirt-java upgrade
From: Marcus <shadowsor@gmail.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

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)
>>>>>>
>>>>>
>>
>