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