cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject RE: [DISCUSS] resizeVolume
Date Wed, 16 Jan 2013 03:34:18 GMT
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.Huang@citrix.com> wrote:

>
>
> > -----Original Message-----
> > From: Marcus Sorensen [mailto:shadowsor@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message