You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Marcus <sh...@gmail.com> on 2014/03/08 00:32:21 UTC
master issue calling volume resize via libvirt - Was: libvirt-java upgrade
On Fri, Mar 7, 2014 at 4:30 PM, Marcus <sh...@gmail.com> wrote:
> Hrm... sent instead of pasted. Commit
>
> commit 3989d6c48118f31464c87c71b6279a11eb13eb35
> Author: Wido den Hollander <wi...@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
>
> On Fri, Mar 7, 2014 at 4:28 PM, Marcus <sh...@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)
Re: master issue calling volume resize via libvirt - Was:
libvirt-java upgrade
Posted by Marcus <sh...@gmail.com>.
Created CLOUDSTACK-6225 and pushed a patch to verify libvirt version
and format before adding the allocate flag.
The bug also mentions the outstanding Ubuntu 12.04 issue.
On Tue, Mar 11, 2014 at 10:50 AM, Nux! <nu...@li.nux.ro> wrote:
> On 11.03.2014 16:46, Marcus wrote:
>>
>> so it looks like preallocation only works 1) on raw volumes, and 2) on
>> certain libvirt versions. I'll see if I can add those checks in,
>> assuming we really want to keep that flag.
>
>
> That is true. Preallocation seems only for raw types.
> This is what I see with libvirt 1.1.1 on RHEL 7 (beta):
>
> [root@1708 ~]# virsh vol-resize test.qcow2 6M --allocate --pool default
> error: Failed to change size of volume 'test.qcow2' to 6M
>
> error: Operation not supported: preallocate is only supported for raw type
> volume
>
> HTH
>
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
Re: master issue calling volume resize via libvirt - Was:
libvirt-java upgrade
Posted by Nux! <nu...@li.nux.ro>.
On 11.03.2014 16:46, Marcus wrote:
> so it looks like preallocation only works 1) on raw volumes, and 2) on
> certain libvirt versions. I'll see if I can add those checks in,
> assuming we really want to keep that flag.
That is true. Preallocation seems only for raw types.
This is what I see with libvirt 1.1.1 on RHEL 7 (beta):
[root@1708 ~]# virsh vol-resize test.qcow2 6M --allocate --pool default
error: Failed to change size of volume 'test.qcow2' to 6M
error: Operation not supported: preallocate is only supported for raw
type volume
HTH
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
Re: master issue calling volume resize via libvirt - Was:
libvirt-java upgrade
Posted by Marcus <sh...@gmail.com>.
so it looks like preallocation only works 1) on raw volumes, and 2) on
certain libvirt versions. I'll see if I can add those checks in,
assuming we really want to keep that flag.
On Tue, Mar 11, 2014 at 10:36 AM, Marcus <sh...@gmail.com> wrote:
> 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 <sh...@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 <sh...@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 <wi...@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" <wi...@widodh.nl> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 03/08/2014 12:32 AM, Marcus wrote:
>>>>>>
>>>>>>> On Fri, Mar 7, 2014 at 4:30 PM, Marcus <sh...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hrm... sent instead of pasted. Commit
>>>>>>>>
>>>>>>>> commit 3989d6c48118f31464c87c71b6279a11eb13eb35
>>>>>>>> Author: Wido den Hollander <wi...@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 <sh...@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)
>>>>>>>>>
>>>>>>>>
>>>>>
>>>>
Re: master issue calling volume resize via libvirt - Was:
libvirt-java upgrade
Posted by Marcus <sh...@gmail.com>.
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 <sh...@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 <sh...@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 <wi...@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" <wi...@widodh.nl> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 03/08/2014 12:32 AM, Marcus wrote:
>>>>>
>>>>>> On Fri, Mar 7, 2014 at 4:30 PM, Marcus <sh...@gmail.com> wrote:
>>>>>>
>>>>>>> Hrm... sent instead of pasted. Commit
>>>>>>>
>>>>>>> commit 3989d6c48118f31464c87c71b6279a11eb13eb35
>>>>>>> Author: Wido den Hollander <wi...@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 <sh...@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)
>>>>>>>>
>>>>>>>
>>>>
>>>
Re: master issue calling volume resize via libvirt - Was:
libvirt-java upgrade
Posted by Marcus <sh...@gmail.com>.
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 <sh...@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 <wi...@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" <wi...@widodh.nl> wrote:
>>>
>>>>
>>>>
>>>> On 03/08/2014 12:32 AM, Marcus wrote:
>>>>
>>>>> On Fri, Mar 7, 2014 at 4:30 PM, Marcus <sh...@gmail.com> wrote:
>>>>>
>>>>>> Hrm... sent instead of pasted. Commit
>>>>>>
>>>>>> commit 3989d6c48118f31464c87c71b6279a11eb13eb35
>>>>>> Author: Wido den Hollander <wi...@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 <sh...@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)
>>>>>>>
>>>>>>
>>>
>>
Re: master issue calling volume resize via libvirt - Was:
libvirt-java upgrade
Posted by Marcus <sh...@gmail.com>.
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 <wi...@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" <wi...@widodh.nl> wrote:
>>
>>>
>>>
>>> On 03/08/2014 12:32 AM, Marcus wrote:
>>>
>>>> On Fri, Mar 7, 2014 at 4:30 PM, Marcus <sh...@gmail.com> wrote:
>>>>
>>>>> Hrm... sent instead of pasted. Commit
>>>>>
>>>>> commit 3989d6c48118f31464c87c71b6279a11eb13eb35
>>>>> Author: Wido den Hollander <wi...@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 <sh...@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)
>>>>>>
>>>>>
>>
>
Re: master issue calling volume resize via libvirt - Was: libvirt-java
upgrade
Posted by Wido den Hollander <wi...@widodh.nl>.
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" <wi...@widodh.nl> wrote:
>
>>
>>
>> On 03/08/2014 12:32 AM, Marcus wrote:
>>
>>> On Fri, Mar 7, 2014 at 4:30 PM, Marcus <sh...@gmail.com> wrote:
>>>
>>>> Hrm... sent instead of pasted. Commit
>>>>
>>>> commit 3989d6c48118f31464c87c71b6279a11eb13eb35
>>>> Author: Wido den Hollander <wi...@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 <sh...@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)
>>>>>
>>>>
>
Re: master issue calling volume resize via libvirt - Was:
libvirt-java upgrade
Posted by Marcus <sh...@gmail.com>.
I imagine the new LTS will have it, but I'm not sure what our OS support
policy is.
On Mar 8, 2014 11:59 AM, "Wido den Hollander" <wi...@widodh.nl> wrote:
>
>
> On 03/08/2014 12:32 AM, Marcus wrote:
>
>> On Fri, Mar 7, 2014 at 4:30 PM, Marcus <sh...@gmail.com> wrote:
>>
>>> Hrm... sent instead of pasted. Commit
>>>
>>> commit 3989d6c48118f31464c87c71b6279a11eb13eb35
>>> Author: Wido den Hollander <wi...@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 <sh...@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)
>>>>
>>>
Re: master issue calling volume resize via libvirt - Was:
libvirt-java upgrade
Posted by Nux! <nu...@li.nux.ro>.
On 08.03.2014 18:58, Wido den Hollander wrote:
> On 03/08/2014 12:32 AM, Marcus wrote:
>> On Fri, Mar 7, 2014 at 4:30 PM, Marcus <sh...@gmail.com> wrote:
>>> Hrm... sent instead of pasted. Commit
>>>
>>> commit 3989d6c48118f31464c87c71b6279a11eb13eb35
>>> Author: Wido den Hollander <wi...@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.
Also checked this in libvirt 0.10.2 (stock EL 6.5) and it has the
resize feature:
strings /usr/lib64/libvirt.so.0.10.2 |grep virStorageVolR
virStorageVolResize
virStorageVolRef
virStorageVolResize
virStorageVolResize
virStorageVolRef
virStorageVolRef
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
Re: master issue calling volume resize via libvirt - Was: libvirt-java
upgrade
Posted by Wido den Hollander <wi...@widodh.nl>.
On 03/08/2014 12:32 AM, Marcus wrote:
> On Fri, Mar 7, 2014 at 4:30 PM, Marcus <sh...@gmail.com> wrote:
>> Hrm... sent instead of pasted. Commit
>>
>> commit 3989d6c48118f31464c87c71b6279a11eb13eb35
>> Author: Wido den Hollander <wi...@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 <sh...@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)