I don't think we want to return null, it was changed in master because that method was prone to failing coverity scans and requiring a null check. It should just return 'RBD' when needed and then that format should be handled, null should not mean RBD.
On Thu, Mar 19, 2015 at 11:50 PM, Star Guo <st...@ceph.me> wrote: > Yes, I have found the difference between branch 4.4 and branch master: > > > > 4.4: > https://github.com/apache/cloudstack/blob/4.4/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java > > … > > 1844 try { > > 1845 KVMStoragePool pool = > _storagePoolMgr.getStoragePool(spool.getType(), spool.getUuid()); > > 1846 KVMPhysicalDisk vol = pool.getPhysicalDisk(volid); > > 1847 String path = vol.getPath(); > > 1848 String type = getResizeScriptType(pool, vol); > > 1849 > > 1850 if (type == null) { > > 1851 return new ResizeVolumeAnswer(cmd, false, "Unsupported > volume format: pool type '" + pool.getType() + "' and volume format '" + > vol.getFormat() + "'");1852 } else if (type.equals("QCOW2") && > shrinkOk) { > > 1853 return new ResizeVolumeAnswer(cmd, false, "Unable to > shrink volumes of type " + type); > > 1854 } > > 1855 > > 1856 s_logger.debug("Resizing volume: " + path + "," + > currentSize + "," + newSize + "," + type + "," + vmInsta nceName + "," + > shrinkOk);1857 > > 1858 /* libvirt doesn't support resizing (C)LVM devices, and > corrupts QCOW2 in some scenarios, so we have to do these via Bash script > */1859 if (pool.getType() != StoragePoolType.CLVM && > vol.getFormat() != PhysicalDiskFormat.QCOW2) { > > 1860 s_logger.debug("Volume " + path + " can be resized by > libvirt. Asking libvirt to resize the volume.") ; > > 1861 try { > > 1862 Connect conn = LibvirtConnection.getConnection(); > > 1863 StorageVol v = conn.storageVolLookupByPath(path); > > 1864 int flags = 0; > > 1865 > > 1866 if (conn.getLibVirVersion() > 1001000 && > vol.getFormat() == PhysicalDiskFormat.RAW) { > > 1867 flags = 1; > > 1868 } > > 1869 if (shrinkOk) { > > 1870 flags = 4; > > 1871 } > > … > > > > > > > > Master: > https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java > > … > > 1863 try { > > 1864 KVMStoragePool pool = > _storagePoolMgr.getStoragePool(spool.getType(), spool.getUuid()); > > 1865 KVMPhysicalDisk vol = pool.getPhysicalDisk(volid); > > 1866 String path = vol.getPath(); > > 1867 String type = getResizeScriptType(pool, vol); > > 1868 > > 1869 if (pool.getType() != StoragePoolType.RBD) { > > 1870 if (type.equals("QCOW2") && shrinkOk) { > > 1871 return new ResizeVolumeAnswer(cmd, false, "Unable to > shrink volumes of type " + type); > > 1872 } > > 1873 } else { > > 1874 s_logger.debug("Volume " + path + " is on a RBD storage > pool. No need to query for additional information."); > > 1875 } > > 1876 > > 1877 s_logger.debug("Resizing volume: " + path + "," + > currentSize + "," + newSize + "," + type + "," + vmInsta nceName + "," + > shrinkOk); > > 1878 > > 1879 /* libvirt doesn't support resizing (C)LVM devices, and > corrupts QCOW2 in some scenarios, so we have to do these via Bash script > */ > > 1880 if (pool.getType() != StoragePoolType.CLVM && > vol.getFormat() != PhysicalDiskFormat.QCOW2) { > > 1881 s_logger.debug("Volume " + path + " can be resized by > libvirt. Asking libvirt to resize the volume.") ; > > 1882 try { > > 1883 Connect conn = LibvirtConnection.getConnection(); > > 1884 StorageVol v = conn.storageVolLookupByPath(path); > > 1885 int flags = 0; > > 1886 > > 1887 if (conn.getLibVirVersion() > 1001000 && > vol.getFormat() == PhysicalDiskFormat.RAW && pool.getType() != > StoragePoolType.RBD) { > > 1888 flags = 1; > > 1889 } > > … > > > > And then , I check the scripts file: scripts/storage/qcow2/resizevolume.sh ., > backport the feature to my source code. After complie, cover the > cloud-plugin-hypervisor-kvm-4.4.2.jar to MS and kvm agent, then it works. > > > > BTW, in Master the method “private String getResizeScriptType(KVMStoragePool > pool, KVMPhysicalDisk vol)” in LibvirtComputingResource.java should be > return null at the end, and branch 4.4 fix it. > > > > Best Regards, > > Star Guo > > > > -----邮件原件----- > 发件人: Marcus [mailto:shadow...@gmail.com] > 发送时间: 2015年3月20日 13:52 > 收件人: dev@cloudstack.apache.org > 主题: Re: cloudstack 4.4.2 + kvm resize data disk fail on ceph/rbd > > > > It needs to be looked at. Awhile back there was a switch made that began to > leverage libvirt to do volume resizes, but everyone complained about > corruption for qcow2, so it was backed out to use the virsh scripts from > before. It seems libvirt was resizing the 'libvirt volume' but not the block > device in qemu. I've looked at the code both before and after this change, > and it looks like RBD would have thrown 'unsupported' in either case, but > there is also code that would still leverage libvirt to resize RBD if it > didn't fail this check, so it needs a bit of love to get it enabled and > working properly, preferably from someone who has access to RBD to develop > against. You may want to open a jira request for it and include this info. > > > > On Thu, Mar 19, 2015 at 9:55 PM, Star Guo < <mailto:st...@ceph.me> > st...@ceph.me> wrote: > >> Hi, > >> > >> > >> > >> My lab is cloudstack 4.4.2 + kvm + ceph/rbd. I add a volume and attach > >> it to a VM. When I resize the volume, the ui throw fail. > >> > >> And I catch the log in MS as bellow: > >> > >> > >> > >> "2015-03-20 12:48:59,145 DEBUG [c.c.a.t.Request] > >> (AgentManager-Handler-9:null) Seq 7-81346268269410213: Processing: { > >> Ans: , > >> MgmtId: 345052394370, via: 7, Ver: v1, Flags: 10, > >> [{"com.cloud.agent.api.storage.ResizeVolumeAnswer":{"newSize":0,"resul > >> t":fal se,"details":"Unsupported volume format: pool type 'RBD' and > >> volume format 'raw'","wait":0}}] }" > >> > >> > >> > >> Does not support RBD/raw resize now ? > >> > >> > >> > >> Best Regards, > >> > >> Star Guo > >> >
