[
https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14325724#comment-14325724
]
Nux edited comment on CLOUDSTACK-6181 at 2/18/15 11:19 AM:
-----------------------------------------------------------
Ok, done some tests. Env: ACS 4.5 RC3, CentOS 6 stock hypervisors.
Live resizing a live ROOT volume from cloudmonkey left me with a corrupted
(beyond fsck) volume; it is still readable but the VM OS (CentOs 6) does not
function properly, can't even login, though surprisingly still boots.
While doing this resize I noticed in the hypervisors the command used is solely
qemu-img, eg:
/usr/bin/qemu-img resize
/var/lib/libvirt/images/5b99dd72-7ac2-4e78-85bd-47c82b65ebea
So while /usr/share/cloudstack-common/scripts/storage/qcow2/resizevolume.sh
seems to invoke "virsh blockresize" I have not seen it in the processes, the
solution here would be to avoid "qemu-img resize" for live VMs (?).
Of course, just to be sure, if I live resize the ROOT volume (of a new machine
obviously) via "virsh blockresize" manually, then not only it doesn't get
corrupted, but the OS instantly sees the modification. Why can't we just use
solely "virsh blockresize" for live VMs?
All in all, the resize operation is very valuable, without it we can't
upgrade/downgrade machines and I'd rather keep it, even with the current risks.
People just need to be aware of the problem or apply Loic's patch?
Thoughts?
was (Author: nuxro):
Ok, done some tests. Env: ACS 4.5 RC3, CentOS 6 stock hypervisors.
Live resizing a live ROOT volume from cloudmonkey left me with a corrupted
(beyond fsck) volume; it is still readable but the VM OS (CentOs 6) does not
function properly, can't even login, though surprisingly still boots.
While doing this resize I noticed in the hypervisors the command used is solely
qemu-img, eg:
/usr/bin/qemu-img resize
/var/lib/libvirt/images/5b99dd72-7ac2-4e78-85bd-47c82b65ebea
So while /usr/share/cloudstack-common/scripts/storage/qcow2/resizevolume.sh
seems to invoke "virsh blockresize", the solution here would be to avoid
"qemu-img resize" for live VMs.
Of course, just to be sure, if I live resize the ROOT volume (of a new machine
obviously) via "virsh blockresize" manually, then not only it doesn't get
corrupted, but the OS instantly sees the modification. Why can't we just use
solely "virsh blockresize" for live VMs?
All in all, the resize operation is very valuable, without it we can't
upgrade/downgrade machines and I'd rather keep it, even with the current risks.
People just need to be aware of the problem or apply Loic's patch?
Thoughts?
> 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.3.4#6332)
