On Jan 19, 2015, at 14:59 , Martin Polednik <[email protected]> wrote:
> Hello, > > Since dealing with SR-IOV, we've discovered the need to persist > number of virtual functions for given virtual functions. The need > is actually split into 2 parts: setting the number and persisting it. > Our talks have pointed to 5 choices in persistence mechanisms: > > * let engine set the number when host becomes operational > * implement mechanism in systemd/udev > * create udev rule set > * persist them inside VDSM > * or actually let the system administrator handle this > > All of these choices except for the last still need the engine to > do the initial set-up. I would like to hear your opinion on persistence > mechanism and splitting the choice of mechanism and means of set-up. > Since persistence is currently mostly required by networking team, > I propose that [1] would be accepted as the means of set-up and in future, > network team would figure out and implement their preferred way of > persistence. I would agree. Since there is no persistent mechanism available at the moment I would go with engine setting that explicitly based on host lifecycle. trying to persist in vdsm is not helping as it anyway should be a different component (systemd?), and pushing such a mechanism to systemd is not feasible in a reasonable timeframe Thanks, michal > > [1] > http://gerrit.ovirt.org/#/c/36216/3 > > Regards, > > mpolednik _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
