On Sun, May 26, 2013 at 09:28:41AM -0400, 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 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. Dan. _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
