add blkIoTune support for a specific device at vm creation

[Mei Liu]

On 05/23/2013 11:36 PM, Dan Kenigsberg wrote:
> On Wed, May 22, 2013 at 11:55:26AM -0400, Doron Fediuck wrote:
>> ----- Original Message -----
>>> From: "Mei Liu" <liumbj at linux.vnet.ibm.com>
>>> To: arch at ovirt.org
>>> Cc: dfediuck at redhat.com, wudxw at linux.vnet.ibm.com
>>> Sent: Monday, May 20, 2013 6:07:53 AM
>>> Subject: add blkIoTune support for a specific device at vm creation
>>>
>>> Hi all,
>>> I would like to add blkIoTune support for a specific device at vm creation.
>>>
>>> The code parses the 'blkIoTune' descrption for block devices at vm creation
>>> time and adds iotune tag accordingly.
>>>
>>> e.g.
>>> Adding 'blkIoTune':{'read_bytes_sec': 6120000, 'total_iops_sec': 800} for a
>>> block device will add the following in dom xml for that device.
>>>
>>> <iotune>
>>>        <read_bytes_sec>6120000</read_bytes_sec>
>>>        <total_iops_sec>800</total_iops_sec>
>>> </iotune>
>>>
>>> The patch is under review in http://gerrit.ovirt.org/#/c/14636/ .
>>>
>>> Does the patch meet the requirement of the engine or the whole
>>> architecture? Are the new parameters properly placed?  Any suggestions
>>> are welcomed.
>>>
>>> TIA.
>>>
>>> Best reagrds,
>>> Mei Liu (Rose)
>>>
>>>
>> Hi Mei Liu,
>> Apologies for my late response.
>> Is there an engine implementation for it?
>> This is important enough to be considered on how it works in a cluster
>> on not just on host level. For example, what happens during and after
>> live migration?
> As far as I know, there's nothing written on the Engine side, yet.
>
> And in my opinion, we can aim low, and have a very minimalistic
> implementation, that give a thin GUI for each block device, in where
> these two parameters can be edited, and passed to Vdsm on vmCreate,
> hotplug, and vmUpdateDevice.
>
> Obviously, such an implementation affects only in the vDisk level; the
> io throttling would follow the VM to the destination node, regardless of
> other readers/writers on that host. This is suboptimal; it would be
> cooler to have a policy that provides relative io priority to different
> vDisks/VMs/users. But in my opinion, it can wait for a second phase.
>
> I'm fine with the suggested Engine/Vdsm API (though I'd try to be even
> more just-like-libvirt and call it "iotune"). But I'm no Engine expert
> to judge - the may wnat to hide it in their specParam map.
>
> I'd love to see a feature page written for this, anyway!
>
>
> Dan.
>
Thanks Dan and Doron for your comments.

I agree that we can make it two phases. In the first phase, we provide 
the related VDSM API.

For better discussion, I created a draft wiki 
http://www.ovirt.org/SLA_for_storage_resource . We can further discuss 
the SLA based on this wiki.

Best regards,
Mei Liu(Rose)