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