[
https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13930540#comment-13930540
]
Nux commented on CLOUDSTACK-6181:
---------------------------------
Marcus,
Your message gets abruptly interrupted after "It kind of seems as though it's",
did you want to add anything else?
And yes, you are correct, this affects data volumes as well, I cannot resize
them, I get the same error. It doesn't seem to matter if the VM is on or off.
At CLI this is what I see (CentOS 6.5, libvirt 0.10.2.29.el6_5.5):
#virsh vol-resize /var/lib/libvirt/images/sparse.raw 6M --allocate
error: failed to get vol '/var/lib/libvirt/images/sparse.raw', specifying
--pool might help
error: Storage volume not found: no storage vol with matching path
#virsh vol-create-as default sparse.raw 1M
Vol sparse.raw created
#virsh vol-resize sparse.raw 6M --allocate --pool default
error: Failed to change size of volume 'sparse.raw' to 6M
error: unsupported flags (0x1) in function storageVolumeResize
# virsh vol-resize sparse.raw 6M --pool default
Size of volume 'sparse.raw' successfully changed to 6M
# qemu-img info /var/lib/libvirt/images/sparse.raw
image: /var/lib/libvirt/images/sparse.raw
file format: raw
virtual size: 6.0M (6291456 bytes)
disk size: 1.0M
With qcow:
# virsh vol-create-as default test.qcow2 1M --format qcow2
Vol test.qcow2 created
# virsh vol-resize test.qcow2 6M --allocate --pool default
error: Failed to change size of volume 'test.qcow2' to 6M
error: unsupported flags (0x1) in function storageVolumeResize
# virsh vol-resize test.qcow2 6M --pool default
Size of volume 'test.qcow2' successfully changed to 6M
> 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)
