On 07/24/2014 06:38 PM, Logan Barfield wrote:
I think I've found the cause of the resize failure. When using RBD for
primary storage the disk is not allocated before the VM starts. The resize
operation runs before the disk exists, and instead of failing completely it
just updates the database with the new disk size and returns success.
Deploying the VM in a stopped state doesn't work either, because the disk
isn't created until the VM starts.
Ah, ok. So that's something that has to be fixed there.
I've been able to get a resize operation to work by manually running
deployVM -> wait for ~5 seconds -> resizeVolume. This obviously doesn't
help when passing the 'rootdisksize' parameter to deployVM.
True, true. Weird however that the resize runs prior to the creation of
the drive.
To fix this I think the deployment logic would need to be changed to
allocate the VM's disk before starting it, or to run the resize operation
once the disk has been created. I'm assuming the only reason this issue is
appearing with RBD is due to how templates are deployed from an RBD
snapshot instead of being copied from secondary storage every time.
Thoughts?
Fully agree with you. I think the logic sounds sane.
Wido
Thank You,
Logan Barfield
Tranquil Hosting
On Wed, Jul 23, 2014 at 7:13 PM, Logan Barfield <lbarfi...@tqhosting.com>
wrote:
The change I mentioned appears to fix the resize error. Resizing the root
disk with deployVM still doesn't work however.
To test I created a VM from a 5GB template with "rootdisksize" = "20".
The VM is successfully created, and CloudStack lists the ROOT volume as
20GB, but the RBD volume is still 5GB in size.
Resizing the volume manually via virsh seems to work fine. I'll look
through it again tomorrow.
Thank You,
Logan Barfield
Tranquil Hosting
On Wed, Jul 23, 2014 at 5:49 PM, Logan Barfield <lbarfi...@tqhosting.com>
wrote:
Just an FYI, RBD resizing still fails because libvirt is throwing an
invalid flags error. I'm testing the following patch:
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java:
- if (conn.getLibVirVersion() > 1001000 &&
vol.getFormat() == PhysicalDiskFormat.RAW) {
+ if (conn.getLibVirVersion() > 1001000 &&
vol.getFormat() == PhysicalDiskFormat.RAW && pool.getType() !=
StoragePoolType.RBD) {
flags = 1;
}
If it resolves the issue I'll submit it.
Thank You,
Logan Barfield
Tranquil Hosting
On Tue, Jul 22, 2014 at 4:38 PM, Logan Barfield <lbarfi...@tqhosting.com>
wrote:
Wido,
Excellent. As long as it passes testing we'll be golden.
Thank You,
Logan Barfield
Tranquil Hosting
On Tue, Jul 22, 2014 at 4:30 PM, Wido den Hollander <w...@widodh.nl>
wrote:
On 07/22/2014 10:13 PM, Logan Barfield wrote:
Wido,
I appreciate the confirmation. Would you mind posting an update here
when
you've submitted the patch? As I mentioned in another post we will
probably end up just having to go into production with a non-official
build. We won't be able to wait for 4.5 or 4.4.x unfortunately.
I just pushed a patch: https://git-wip-us.apache.org/
repos/asf?p=cloudstack.git;a=commitdiff;h=
173909e99d85cfcc85b017bc426950f9f16fddf0
That should also apply on 4.4 very easily, a simple cherry-pick should
be sufficient.
Wido
Thank You,
Logan Barfield
Tranquil Hosting
On Tue, Jul 22, 2014 at 4:09 PM, Wido den Hollander <w...@widodh.nl>
wrote:
On 07/22/2014 09:53 PM, Logan Barfield wrote:
I was testing on a recent 4.4 build today and noticed that volume
resizing
for RBD volumes is not working as intended.
In LibvirtComputingResource.java the 'getResizeScriptType()' function
doesn't have logic for type = RBD and format = RAW or QCOW2, so it
returns
'null' and the resize operation fails.
In CLOUDSTACK-6181 there was some discussion regarding RBD support,
and it
was signed off on by Wido (who appears to be the only contributor
actively
supporting Ceph in CloudStack). Was the mentioned functionality just
never
implemented, or am I overlooking something?
So it seems you are right. I can't remember anymore why I signed it
off
(probably because it worked locally), but what you are saying is true.
RBD are block devices which do not exist in kernel space, so a script
can
never check if the volume exists.
The fix is rather simple, since libvirt can resize the volume it's
just a
matter of a few if-statements in LibvirtComputing resouce, I'll get
right
to that, but it will never make it into 4.4. Hopefully 4.4.1
Wido
Thank You,
Logan Barfield
Tranquil Hosting