add blkIoTune support for a specific device at vm creation

Eli Mesika emesika at redhat.com
Sun May 26 18:33:10 UTC 2013



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Doron Fediuck" <dfediuck at redhat.com>, "Mei Liu" <liumbj at linux.vnet.ibm.com>, arch at ovirt.org
> Sent: Sunday, May 26, 2013 6:42:51 PM
> Subject: Re: add blkIoTune support for a specific device at vm creation
> 
> On Sun, May 26, 2013 at 09:28:41AM -0400, Eli Mesika wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > To: "Doron Fediuck" <dfediuck at redhat.com>, "Eli Mesika"
> > > <emesika at redhat.com>
> > > Cc: "Mei Liu" <liumbj at linux.vnet.ibm.com>, arch at ovirt.org
> > > 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" <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.
> > 
> > Right, ant reason why not to use the specParams here ???
> 
> Eli, would you remind me why we need the additional level of indirection
> introduced by specParams? I suspect that just like me, Mei Liu does not
> know the pros and cons.

specparams - Any device specific parameters (for example memory allocation per monitor in video device)

So , in general , it was defined in order to add any special device parameters (saved and managed as JSON)

> 
> Dan.
> 



More information about the Arch mailing list