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
awesome!
Can you implement cpu tuning or network QoS as well ? Thanks!
-Wei
2014-03-06 11:42 GMT+01:00 Wido den Hollander w...@widodh.nl:
On 03/05/2014 07:18 PM, Marcus wrote:
For the hypervisor version of throttling, we just need
ResizeVolumeCommand to pass the VolumeObjectTO rather
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 w...@widodh.nl:
On 03/05/2014 07:18
Brilliant!
2014-03-06 12:07 GMT+01:00 Wido den Hollander w...@widodh.nl:
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
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,
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 changing storage QoS
dynamically will be a more time-consuming task than adding that kind of
support on the
Sounds good - let's plan on that for 4.5. :)
On Thu, Mar 6, 2014 at 10:15 PM, Punith S punit...@cloudbyte.com 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
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
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
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
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
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
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
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 shadow...@gmail.com wrote:
Yes, that's
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
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
16 matches
Mail list logo
