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 >
