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 <w...@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" <w...@widodh.nl> wrote: >> >>> >>> >>> On 03/08/2014 12:32 AM, Marcus wrote: >>> >>>> On Fri, Mar 7, 2014 at 4:30 PM, Marcus <shadow...@gmail.com> wrote: >>>> >>>>> Hrm... sent instead of pasted. Commit >>>>> >>>>> commit 3989d6c48118f31464c87c71b6279a11eb13eb35 >>>>> Author: Wido den Hollander <w...@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 <shadow...@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) >>>>>> >>>>> >> >
