add blkIoTune support for a specific device at vm creation
Dan Kenigsberg
danken at redhat.com
Thu May 23 15:36:42 UTC 2013
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.
More information about the Arch
mailing list