Hi,
Update from my side as well. I've re-submitted my patches as the first
series got refused (with good feedback though!)
On my Github[0] the patches can be found which I sent last weekend.
I've those make it into 0.5.0 I can also implement the resizing for RBD
images in CloudStack.
Wido
[0]: https://github.com/wido/libvirt-java/commits/snapshot-resize-migrate
On 01/16/2013 04:34 AM, Marcus Sorensen wrote:
Just an update (will post this on the feature request as well). With the
tests patch Ryan provided today, I think we're ready to merge this in. That
is unless it's going to cause problems for the license issues currently
being worked out, but this is pretty much all new stuff so I don't expect
it to cause conflicts.
On Jan 9, 2013 11:16 AM, "Alex Huang" <alex.hu...@citrix.com> wrote:
-----Original Message-----
From: Marcus Sorensen [mailto:shadow...@gmail.com]
Sent: Tuesday, January 08, 2013 10:56 AM
To: cloudstack-dev@incubator.apache.org
Subject: [DISCUSS] resizeVolume
Guys,
I've pushed this as a new branch called 'resizevolume', in order to
collaborate with a few of you on it. I have several questions on how to
proceed, due to refactoring efforts. I'm hoping that the experts in those
efforts can collaborate.
1) Wido, would you be interested in looking at adding RBD resize to
LibvirtComputingResource? The resize for CLVM and QCOW2 is done via
scripts/storage/qcow2/resizevolume.sh at the moment, since the libvirt
bindings won't support volBlockResize until you get 0.5.0 out (and even
then I'm not sure if it will support anything more than just informing
the
hypervisor/guest of the change, which is also in the script).
2) I'm not sure exactly how this will be affected by the storage
refactor,
but I'm sure it will be. I looked for examples in the createVolume on
javelin, but it seems that the storage refactor is still early on, and
per
Edison's update only works for a few template commands at the moment. I
thought it best to get this in as a fully fleged member of the storage
API
so that when the work is done on the storage commands, this will get
looked
at as well. So if everything looks good otherwise, I'd like to not block
on
the storage refactor unless this is just going to be scrapped when that
comes along.
I'm sure it will be impacted but check it in and we'll fix it on this end
as we merge storage refactor into cloudstack code.
3) I've implemented resize for Xen, but only tested with local storage
SR.
The SR in devcloud doesn't seem to support online resize, and I'm not
familiar enough with the Xen setup to really figure out if that's just a
byproduct of how the SR was created, whether it's a Xen limitation in
DevCloud, or what. If someone more familiar with Xen wants to take a peek
it would be appreciated, however I'm not really considering it a blocker
if
nobody does. For now resize works offline (or with data disk detached)
and
fails with warning that VM needs to be stopped or data disk detached.
I'm not sure xen actually supports online resize. It didn't when we
started. I'll see if I can get some answers for you.
4) Can someone who is working with the api refactoring take this into
account? I think I'd prefer it go in before the refactor, or if it
doesn't
that someone help me make any modifications necessary, so that it's not
broken at any point in master.
