On Mon, Sep 15, 2014 at 05:43:30PM +0200, Pavel Hrdina wrote: > On 09/15/2014 05:16 PM, Daniel P. Berrange wrote: > >On Mon, Sep 15, 2014 at 05:12:12PM +0200, Pavel Hrdina wrote: > >>This patch series introduce new cputune event to inform > >>management applications about every change of cputune values > >>for running domains. > >> > >>There is missing documentation for all events so the documentation > >>for this event will be part of the patches to document all events. > > > >Do you have any background on the motivation for this feature ? > > > > This feature is request from oVirt and they would also like to have event > for blkdeviotune. > > >It would help to understand the use case better in order to decide > >whether this is the right approach for the events. Specifically I > >am wondering whether returning all the values in the event is the > >best way. The alternative would be to have a generic "resource > >tunable changed" event where we just specify the type of data that > >changed, and allow the app to then fetch the new values if they > >actually want them. This would let us deal with all the resource > >tunables in a single event, isntead of having to add more events > >for memory tunables, numa tunables, disk I/O, net I/O etc. > > > > This event will return only the values that has been changed, not all values > that we have for cputune. > > Having one "big" event for all tunables is a good idea and with the > typedParameters it should be easy. Let's say that the event would be > generic, then the typedParameter's field could be for cputune evetns: > > "cpu.shares" > "cpu.emulatorpin" > "cpu.vcpu0" > > or for example the blkiodevtune: > > "blkdevio.total_bytes_sec" Yes, it seems like we ought to have an event with keys that are 100% identical to keys used for virConnectGetAllDomainStats. That said, we need to be careful what we guarantee here for events. For example, if someone uses systemd to change the cgroup settings behind libvirt's back we don't currently see that change in libvirt, so we won't emit any event in that scenario. So we should document that we only emit events for changes made via libvirt and will not issue events if apps go directly to cgroups or systemd Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list