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 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 <shadow...@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.tutkow...@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 <w...@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 <punit...@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.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*
