Sounds good - let's plan on that for 4.5. :)
On Thu, Mar 6, 2014 at 10:15 PM, Punith S wrote:
> yea sure , will target this for 4.5.
>
> thanks
>
>
> On Thu, Mar 6, 2014 at 8:37 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com
> > wrote:
>
> > Just to clarify, Punith: You are correct that ch
yea sure , will target this for 4.5.
thanks
On Thu, Mar 6, 2014 at 8:37 PM, Mike Tutkowski wrote:
> 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 wi
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
Brilliant!
2014-03-06 12:07 GMT+01:00 Wido den Hollander :
>
>
> On 03/06/2014 11:48 AM, Wei ZHOU wrote:
>
>> awesome!
>>
>> Can you implement cpu tuning or network QoS as well ? Thanks!
>>
>>
> Yes, I was planning on adding multiple methods at once with a couple of
> patches.
>
>
> -Wei
>>
>>
On 03/06/2014 11:48 AM, Wei ZHOU wrote:
awesome!
Can you implement cpu tuning or network QoS as well ? Thanks!
Yes, I was planning on adding multiple methods at once with a couple of
patches.
-Wei
2014-03-06 11:42 GMT+01:00 Wido den Hollander :
On 03/05/2014 07:18 PM, Marcus wrote
awesome!
Can you implement cpu tuning or network QoS as well ? Thanks!
-Wei
2014-03-06 11:42 GMT+01:00 Wido den Hollander :
>
>
> 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
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/byte
Hi,
Hypervisor rate limiting is only supported on KVM at the time being. You
are correct that it can get confusing if people use both hypervisor rate
limiting and then QoS of some flavor on the storage side, so CloudStack
only supports a user doing one or the other with a given volume.
As far as
yea mike i agree with you , i was talking with respect to changing iops of
the datadisk on storage side, not with respect to hipervisor level settings,
and like marcus suggested i tried to tie changing the disk iops with
already available resize command but it has some limitations like i said
befo
Exactly...and that shouldn't be too much of a problem.
The "trick" will come into play when we have to take into consideration
"generic" storage properties and that Min and Max IOPS should really be
part of this group.
On Wed, Mar 5, 2014 at 11:59 AM, Marcus wrote:
> Yes, that's what I mean. W
Yes, that's what I mean. When the offering is changed, we need to have
a hook in there that calls the applicable storage driver for the
volume. Then the drivers can be free to implement or not implement.
On Wed, Mar 5, 2014 at 11:36 AM, Mike Tutkowski
wrote:
> Hi Marcus,
>
> In 4.4 I'm adding the
Hi Marcus,
In 4.4 I'm adding the ability to allow admins to specify Min and Max IOPS
for Compute Offerings, as well (support only for XenServer in 4.4).
I agree changing of IOPS should be doable through changing a Disk or
Compute Offering, but this doesn't work right now as the storage framework
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
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
Sent via my BlackBerry from Vodacom - let your email find you!
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
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
ve
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.
(2) call virs
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 n
19 matches
Mail list logo
