cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: Change Volume IOPS on fly without detaching the disk feature.
Date Thu, 06 Mar 2014 15:07:20 GMT
Just to clarify, Punith: You are correct that changing storage QoS
dynamically will be a more time-consuming task than adding that kind of
support on the hypervisor side. That's why I say with the Feature Freeze
date as it is for 4.4 that we should look to address this in 4.5.

Thanks


On Thu, Mar 6, 2014 at 3:42 AM, Wido den Hollander <wido@widodh.nl> wrote:

>
>
> On 03/05/2014 07:18 PM, Marcus wrote:
>
>> For the hypervisor version of throttling, we just need
>> ResizeVolumeCommand to pass the VolumeObjectTO rather than just the
>> volume uuid/path, so that when we change offerings on the agent side
>> we have the info we need to update libvirt with the new iops/bytes
>> settings. We also need the libvirt java bindings to do so, per
>> previous discussion.
>>
>>
> I'm already working on the patch: https://github.com/wido/
> libvirt-java/tree/change-iops
>
> It's not so hard to implement it seems. Hopefully I'll have it ready after
> the weekend.
>
>
>  On Wed, Mar 5, 2014 at 11:12 AM, Marcus <shadowsor@gmail.com> wrote:
>>
>>> Wouldn't this be implemented as just changing disk offerings? The
>>> resizeVolume API call already allows you to switch disk offerings, we
>>> just need to add a hook in there to optionally call the storage driver
>>> (If volume is deployed to a primary storage) to make an update to the
>>> iops properties on the backend storage. Come to think of it, depending
>>> on how storage drivers are implementing the iops/limits feature,
>>> resizeVolume might be breaking this, or simply requiring a reboot to
>>> apply. That is, if the storage driver is setting the iops just once
>>> upon volume creation, it's probably breaking when a user moves a disk
>>> between offerings that may have alternate iops limits (this is
>>> probably not the case for hypervisor throttling, as that's applied
>>> from whatever is current when the VM starts up).
>>>
>>> On Wed, Mar 5, 2014 at 9:58 AM, Mike Tutkowski
>>> <mike.tutkowski@solidfire.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Perhaps I'm not following this correctly, but I'm a bit lost on why we
>>>> are
>>>> talking about changing settings on running VMs.
>>>>
>>>>  From what I understand, you are a representative of a storage vendor
>>>> that
>>>> has a rate-limiting feature. You want to be able to not only set the Max
>>>> IOPS, but also adjust them. Is this true?
>>>>
>>>> If so, I totally agree. SolidFire has control over Min and Max IOPS and
>>>> it
>>>> is on my to-do list to add support into CloudStack to be able to
>>>> dynamically change these values (right now customers do this from the
>>>> SolidFire API or its GUI).
>>>>
>>>> If you would like to work on this feature, that would be great. I'd be
>>>> happy to review your design and code.
>>>>
>>>> One complication is that we are looking at adding support for generic
>>>> key/value pairs for storage plug-ins in 4.5 and this would effectively
>>>> remove the need to have Min and Max IOPS as "special" fields in the
>>>> CloudStack API and GUI.
>>>>
>>>> I'm going to CC Chris Suichll (from NetApp) as he and I have already
>>>> discussed this generic-properties concept. It would be good to get his
>>>> feedback on how we might go about dynamically updating storage-plug-in
>>>> key/value pairs.
>>>>
>>>> Thanks!
>>>> Mike
>>>>
>>>>
>>>> On Wed, Mar 5, 2014 at 3:12 AM, Wido den Hollander <wido@widodh.nl>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> On 03/05/2014 10:12 AM, Wei ZHOU wrote:
>>>>>
>>>>>  I was thinking about it last week.
>>>>>> AFAIK, libvirt-java 0.5.1 does not support change setting on running
>>>>>> vms,
>>>>>> but virsh command line and libvirt API supports it.
>>>>>> so the sulution are
>>>>>> (1) change libvirt-java to support it, and make it released in the
>>>>>> next
>>>>>> version. Maybe Wido can help us.
>>>>>>
>>>>>>
>>>>> Sure! That seems the best way forward. What is currently lacking in the
>>>>> libvirt-java bindings?
>>>>>
>>>>>
>>>>>   (2) call virsh command line.
>>>>>
>>>>>>
>>>>>>
>>>>>>  Please, please, do not do that. That's very hacky. We should really
>>>>> keep
>>>>> using the libvirt-java bindings and stay away from invoking binaries.
>>>>>
>>>>> Wido
>>>>>
>>>>>
>>>>>   -Wei
>>>>>
>>>>>>
>>>>>> 2014-03-05 9:01 GMT+01:00 Punith S <punith.s@cloudbyte.com>:
>>>>>>
>>>>>>   hi guys,
>>>>>>
>>>>>>>
>>>>>>> we are having a fixed max iops for each volume being attached
to the
>>>>>>> instance in managed storage,
>>>>>>> so this a problem where we are making users to pre allocate the
iops
>>>>>>> of
>>>>>>> the
>>>>>>> disk without having an option to change or resize it, similar
to the
>>>>>>> size
>>>>>>> metric.
>>>>>>>
>>>>>>> so i would like to introduce a new feature which enables to change
or
>>>>>>> resize the volume iops on fly without detaching the datadisk
of the
>>>>>>> VM
>>>>>>> with
>>>>>>> zero downtime where performance of the datadisk can be altered
at any
>>>>>>> point
>>>>>>> with the available iops of the primary storage pool, which is
>>>>>>> similar in
>>>>>>> resizing the volume or datadisk of the vm , where in latter we
have
>>>>>>> to
>>>>>>> detach the datadisk.
>>>>>>>
>>>>>>> what do you guys think about this feature ? any feedback ?
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> --
>>>>>>> regards,
>>>>>>>
>>>>>>> punith s
>>>>>>> cloudbyte.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>> --
>>>> *Mike Tutkowski*
>>>> *Senior CloudStack Developer, SolidFire Inc.*
>>>> e: mike.tutkowski@solidfire.com
>>>> o: 303.746.7302
>>>> Advancing the way the world uses the
>>>> cloud<http://solidfire.com/solution/overview/?video=play>
>>>> *(tm)*
>>>>
>>>


-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

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