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 <shadow...@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 <shadow...@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 <shadow...@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 <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) >>>>>>>>> >>>>>>>> >>>>> >>>>
