On Wed, 19 Apr 2017 12:50:36 +0100
"Daniel P. Berrange" <berra...@redhat.com> wrote:
> On Wed, Apr 19, 2017 at 01:41:47PM +0200, Cornelia Huck wrote:
> > On Thu, 20 Apr 2017 00:57:08 +0800
> > ZhiPeng Lu <lu.zhip...@zte.com.cn> wrote:
> >
> > > diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json
> > > index a02dbf2..60111dc 100644
> > > --- a/qga/qapi-schema.json
> > > +++ b/qga/qapi-schema.json
> > > @@ -1042,3 +1042,37 @@
> > > 'data': { 'path': 'str', '*arg': ['str'], '*env': ['str'],
> > > '*input-data': 'str', '*capture-output': 'bool' },
> > > 'returns': 'GuestExec' }
> > > +##
> > > +# @GuestNetworkInterfaceStat:
> > > +#
> > > +# @rx_bytes: received bytes of interface
> > > +#
> > > +# @rx_packets: received packets of interface
> > > +#
> > > +# @rx_errs: received error packets of interface
> > > +# @rx_drop: received drop packets of interface
> > > +#
> > > +# Since: 2.10
> > > +##
> > > +{ 'struct': 'GuestNetworkInterfaceStat',
> > > + 'data': {'rx_bytes': 'uint64',
> > > + 'rx_packets': 'uint64',
> > > + 'rx_errs': 'uint64',
> > > + 'rx_drop': 'uint64',
> > > + 'tx_bytes': 'uint64',
> > > + 'tx_packets': 'uint64',
> > > + 'tx_errs': 'uint64',
> > > + 'tx_drop': 'uint64'
> > > + } }
> > > +##
> > > +# @guest-network-get-interface-stat:
> > > +#
> > > +# Get list of interface stat
> > > +#
> > > +# Returns: List of GuestNetworkInterfaceStat on success.
> > > +#
> > > +# Since: 2.10
> > > +##
> > > +{ 'command': 'guest-network-get-interface-stat',
> > > + 'data': {'bus': 'int64', 'slot': 'int64', 'function':
> > > 'int64','netname':'str'},
> > > + 'returns': ['GuestNetworkInterfaceStat'] }
> >
> > Disregarding the question whether this command should be added to the
> > guest agent (I'll leave that to others to discuss), I don't think it's
> > a good idea to enshrine pci identifiers here, as it means that we would
> > need to add a new interface for every non-pci network device.
> >
> > Can you use a more general device identifier interface? It's fine to
> > only support pci for now (as that is likely your use case anyway), but
> > there should be a way to extend this in the future.
>
> It would be better to match the identification approach uses for the
> existing guest-network-get-interfaces command, which is based on MAC
> address. Arguably the stats data could just be added to this existnig
> command instead of adding a new command.
Agreed, that sounds like a better choice.
