<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 06/05/2013 05:03 PM, Allon Mureinik
wrote:<br>
</div>
<blockquote
cite="mid:26148712.4071809.1370423021002.JavaMail.root@redhat.com"
type="cite">
<div style="font-family: times new roman, new york, times, serif;
font-size: 12pt; color: #000000">
<div>Hi Mei,</div>
<div><br>
</div>
<div>How are you treating shared disks?</div>
<div>Is the limitation defined per disk (as a total), or per
disk-vm relation?</div>
<div><br>
</div>
</div>
</blockquote>
The existing API in libvirt is to limit the per vm's vDisk. e.g.
hda of VM1<br>
<br>
So the limitation is on per vm's vDisk, if we don't consider quota
for SD in the design (the basic design). That limitation value is
adjusted based on if backend storage(localfs, nfs, glusterfs...) is
heavily used.<br>
<br>
SD's IO bandwidth quota is to constrain the sum of vDisk
limitation's lower bound(min value of limitation, it is similar to
the concept of reserving). These vDisks use the volumes in the SD. <br>
<br>
<br>
<blockquote
cite="mid:26148712.4071809.1370423021002.JavaMail.root@redhat.com"
type="cite">
<div style="font-family: times new roman, new york, times, serif;
font-size: 12pt; color: #000000">
<hr id="zwchr">
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From:
</b>"Mei Liu" <a class="moz-txt-link-rfc2396E" href="mailto:liumbj@linux.vnet.ibm.com"><liumbj@linux.vnet.ibm.com></a><br>
<b>To: </b>"Doron Fediuck" <a class="moz-txt-link-rfc2396E" href="mailto:dfediuck@redhat.com"><dfediuck@redhat.com></a><br>
<b>Cc: </b><a class="moz-txt-link-abbreviated" href="mailto:arch@ovirt.org">arch@ovirt.org</a><br>
<b>Sent: </b>Wednesday, June 5, 2013 11:11:34 AM<br>
<b>Subject: </b>Re: SLA feature for storage I/O bandwidth<br>
<div><br>
</div>
Hi Doron,<br>
After the discussion, we found that the last version of design
is a little complex, so I simplified it and post it to<br>
<div class="moz-forward-container">
<pre><a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.ovirt.org/Features/Design/SLA_for_storage_io_bandwidth" target="_blank">http://www.ovirt.org/Features/Design/SLA_for_storage_io_bandwidth</a></pre>
We want to let MOM in each host decides how to tune the
bandwidth limit of vms in that host instead of letting
engine to make the whole decision based on statistics from
vms in diverse hosts. Maybe we can consider starting from
the basic one in wiki.<br>
<br>
Thanks & best regards,<br>
Mei Liu(Rose)<br>
<br>
-------- Original Message --------
<table class="moz-email-headers-table mceItemTable"
cellpadding="0" cellspacing="0" border="0">
<tbody>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject:
</th>
<td>Re: SLA feature for storage I/O bandwidth</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date:
</th>
<td>Mon, 03 Jun 2013 18:28:46 +0800</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">From:
</th>
<td>Mei Liu <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:liumbj@linux.vnet.ibm.com"
target="_blank"><liumbj@linux.vnet.ibm.com></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">To:
</th>
<td>Doron Fediuck <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:dfediuck@redhat.com" target="_blank"><dfediuck@redhat.com></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">CC:
</th>
<td><a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:arch@ovirt.org" target="_blank">arch@ovirt.org</a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>On 05/29/2013 11:34 PM, Doron Fediuck wrote:
> ----- Original Message -----
>> From: "Mei Liu" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:liumbj@linux.vnet.ibm.com" target="_blank"><liumbj@linux.vnet.ibm.com></a>
>> To: "Dave Neary" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:dneary@redhat.com" target="_blank"><dneary@redhat.com></a>
>> Cc: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:arch@ovirt.org" target="_blank">arch@ovirt.org</a>
>> Sent: Wednesday, May 29, 2013 11:35:12 AM
>> Subject: Re: SLA feature for storage I/O bandwidth
>>
>> On 05/29/2013 03:42 PM, Dave Neary wrote:
>>> Hi Mei Liu,
>>>
>>> On 05/28/2013 10:18 AM, Mei Liu wrote:
>>>> I created a drafted wiki page on design of storage I/O bandwidth SLA in
>>>> the following link:
>>>>
>>>> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.ovirt.org/SLA_for_storage_resource" target="_blank">http://www.ovirt.org/SLA_for_storage_resource</a> .
>>>>
>>>> I will appreciate the efforts if anyone who works on ovirt engine, vdsm
>>>> or mom could give some comments. TIA.
>>> Just out of interest - which version of oVirt are you targeting this
>>> for? Can I assume that it's for post-3.3? Today is officially 3.3.
>>> feature freeze (but we have a release meeting later to discuss that).
>>>
>>> Thanks,
>>> Dave.
>>>
>> Hi Dave,
>> The basic i/o tune functionality for vdsm is almost ready. However,
>> there is nothing written on the Engine side and no policy for automatic
>> tuning is applied yet.
>> I am not sure if the basic functionality can target 3.3.
>>
>>
>> Best regards,
>> Mei Liu
>>
> Hi Mey Liu,
> I'm still going over the wiki, but a few things we need to consider;
> First of all QoS for storage I/O bandwidth is a part of a larger SLA
> policy which may include network QoS, CPU and memory QoS and the quota
> we implement today.
>
> So first of all we need to make sure your design does not conflict
> the other QoS parts, which is what I'm looking into now.
>
> Additionally, using the quota term is confusing as oVirt already has
> quota today, and cpu API has his own quota definition. So please try
> to come up with a different terminology.
>
> I like your idea of setting an initial value but I need some more time
> for it to come up with my insights.
> Also, I completely agree with your concept of letting mom handle
> it in host level. We need to verify it does not break anything related
> to SPM. This is something we need to synchronize with the storage guys.
>
> Looking into the engine area, we should start thinking on how this will
> be supported in the main storage entities and VM / template / instance
> entities. So you may want to add a section on this as well. This leads
> me to think of importing and exporting a VM which may want to maintain
> the defined IO QoS. Any thoughts around it?
>
> Doron
>
Hi Doron,
Thanks for your questions and insightful thoughts. They are really
inspiring.
I updated the design in
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.ovirt.org/Features/Design/SLA_for_storage_io_bandwidth" target="_blank">http://www.ovirt.org/Features/Design/SLA_for_storage_io_bandwidth</a> .
This time, I add storage I/O bandwidth control according to the quota
design and the SLA tries to ensure the reserved bandwidth for vDisks.
It requires the engine to make the tuning decision, since vm uses the
SD volumes may reside on different hosts and only engine can obtain the
global information.
I think this design will not lead to problem when importing or exporting
a VM.
I will appreciate if you can take a look at the new design.
Best regards,
Mei Liu (Rose)
_______________________________________________
Arch mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Arch@ovirt.org" target="_blank">Arch@ovirt.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/arch" target="_blank">http://lists.ovirt.org/mailman/listinfo/arch</a>
</pre>
<br>
<br>
</div>
<br>
<br>
_______________________________________________<br>
Arch mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:Arch@ovirt.org">Arch@ovirt.org</a><br>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/arch">http://lists.ovirt.org/mailman/listinfo/arch</a><br>
</blockquote>
<div><br>
</div>
</div>
</blockquote>
<br>
</body>
</html>