On 05/26/2013 09:28 PM, Eli Mesika wrote:
----- Original Message -----
From: "Dan Kenigsberg" <[email protected]>
To: "Doron Fediuck" <[email protected]>, "Eli Mesika" <[email protected]>
Cc: "Mei Liu" <[email protected]>, [email protected]
Sent: Thursday, May 23, 2013 6:36:42 PM
Subject: Re: add blkIoTune support for a specific device at vm creation
On Wed, May 22, 2013 at 11:55:26AM -0400, Doron Fediuck wrote:
----- Original Message -----
From: "Mei Liu" <[email protected]>
To: [email protected]
Cc: [email protected], [email protected]
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.
Right, ant reason why not to use the specParam
s here ???
No specific reason for doing so. I moved them to specParams.
I'd love to see a feature page written for this, anyway!
Dan.
I have updated the patch in http://gerrit.ovirt.org/#/c/14636/ and put
these parameters in specParams.
Appreciate that you take a look and give suggestions.
_______________________________________________
Arch mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/arch
