[ https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13930398#comment-13930398 ]
Nux commented on CLOUDSTACK-6181: --------------------------------- Marcus, I reinstalled with latest resize-root branch and things look much better. I can deploy instance with custom size, but I still have problems resizing offline volume: > resize volume id=6a390882-fc56-4435-ba1d-30b31b7a6565 size=26 .Async job 6696da3b-87dd-4891-a025-3b0d4bfb1896 failed Error 530, Unexpected exception accountid = 27a1b192-a905-11e3-b654-9660573836d5 cmd = org.apache.cloudstack.api.command.user.volume.ResizeVolumeCmd created = 2014-03-11T14:12:39+0000 jobid = 6696da3b-87dd-4891-a025-3b0d4bfb1896 jobprocstatus = 0 jobresult: errorcode = 530 errortext = Unexpected exception jobresultcode = 530 jobresulttype = object jobstatus = 2 userid = 27a1b85e-a905-11e3-b654-9660573836d5 On the server I see this: ==> /var/log/cloudstack/agent/agent.log <== 2014-03-11 14:07:00,657 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:null) Request:Seq 1-1838031597920584509: { Cmd , MgmtId: 165340524328661, via: 1, Ver: v1, Flags: 100011, [{"com.cloud.agent.api.storage.ResizeVolumeCommand":{"path":"6a390882-fc56-4435-ba1d-30b31b7a6565","pool":{"id":2,"uuid":"29d6d3ac-1805-3501-89e4-9287e05f2398","host":"192.168.203.67","path":"/primary","port":2049,"type":"NetworkFilesystem"},"vmInstance":"i-2-3-VM","newSize":21474836480,"currentSize":8589934592,"shrinkOk":false,"wait":0}}] } 2014-03-11 14:07:00,657 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:null) Processing command: com.cloud.agent.api.storage.ResizeVolumeCommand 2014-03-11 14:07:00,714 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-2:null) Resizing volume: /mnt/29d6d3ac-1805-3501-89e4-9287e05f2398/6a390882-fc56-4435-ba1d-30b31b7a6565,8589934592,21474836480,QCOW2,i-2-3-VM,false 2014-03-11 14:07:00,714 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-2:null) Volume /mnt/29d6d3ac-1805-3501-89e4-9287e05f2398/6a390882-fc56-4435-ba1d-30b31b7a6565 can be resized by libvirt. Asking libvirt to resize the volume. ==> /var/log/libvirt/libvirtd.log <== 2014-03-11 14:07:00.716+0000: 5449: error : storageVolumeResize:1793 : unsupported flags (0x1) in function storageVolumeResize But virt-resize does work from the cli: virsh # vol-resize /mnt/29d6d3ac-1805-3501-89e4-9287e05f2398/6a390882-fc56-4435-ba1d-30b31b7a6565 20G Size of volume '6a390882-fc56-4435-ba1d-30b31b7a6565' successfully changed to 20G virsh # vol-info /mnt/29d6d3ac-1805-3501-89e4-9287e05f2398/6a390882-fc56-4435-ba1d-30b31b7a6565 Name: 6a390882-fc56-4435-ba1d-30b31b7a6565 Type: file Capacity: 20.00 GiB Allocation: 240.38 MiB > Root resize > ----------- > > Key: CLOUDSTACK-6181 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6181 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Storage Controller, UI > Affects Versions: 4.4.0 > Environment: KVM/libvirt/CentOS, Xenserver > Reporter: Nux > Labels: disk, resize, template > Fix For: 4.4.0 > > > Rationale: > Currently the root size of an instance is locked to that of the template. > This creates unnecessary template duplicates, prevents the creation of a > market place, wastes time and disk space and generally makes work more > complicated. > Real life example - a small VPS provider might want to offer the following > sizes (in GB): > 10,20,40,80,160,240,320,480,620 > That's 9 offerings. > The template selection could look like this, including real disk space used: > Windows 2008 ~10GB > Windows 2008+Plesk ~15GB > Windows 2008+MSSQL ~15GB > Windows 2012 ~10GB > Windows 2012+Plesk ~15GB > Windows 2012+MSSQL ~15GB > CentOS ~1GB > CentOS+CPanel ~3GB > CentOS+Virtualmin ~3GB > CentOS+Zimbra ~3GB > CentOS+Docker ~2GB > Debian ~1GB > Ubuntu LTS ~1GB > In this case the total disk space used by templates will be 828 GB, that's > almost 1 TB. If your storage is expensive and limited SSD this can get > painful! > If the root resize feature is enabled we can reduce this to under 100 GB. -- This message was sent by Atlassian JIRA (v6.2#6252)