On Fri, Jun 08, 2018 at 12:01:48PM -0600, Jim Fehlig wrote: > On 06/08/2018 02:30 AM, Daniel P. Berrangé wrote: > > On Thu, Jun 07, 2018 at 04:23:32PM -0600, Jim Fehlig wrote: > > > On 06/07/2018 09:42 AM, Trapp, Michael wrote: > > > > I fully understand the requirements regarding coding style and the way the changes should be split and discussed in detail, > > > > but may I ask you to provide some general feedback about the basic concept and if this an option at all before we start discussing the details. > > > > > > vhostmd already supports 'vbd' and 'xenstore' as transports for the metric > > > data. Adding another virtio-channel based transport is a great idea IMO. > > > > > > WRT writing the data to the various channels, I suppose it is possible to do > > > that even if there is no (immediate) recipient for the data? The vbd and > > > xenstore transports don't have a protocol so to speak. The data is simply > > > written to the disk or xenstore node regardless if there is someone to > > > consume it. Can the virtio transport work the same? If so, that would > > > alleviate the need for polling all the fds and the static list of > > > epoll_event. In virtio_metrics_update() we could simply connect to all the > > > channels, write the data, close them, and repeat on the next update period > > > (which is every 5sec by default). > > > > Why push it to the guest at a fixed frequency, rather than just letting the > > guest query the host at whatever rate it feels it needs ? > > The other transports work that way, but in those cases the guests use the > same source on the host, e.g. a ramdisk for vbd. For virtio where the source > is a per-guest channel on the host, I suppose it's best to only send the > metrics when the guest asks for them. Yeah I tend to view this use case as being the reverse of QEMU guest agent, rather it is a QEMU host agent. So the guest is the client making calls to a daemon in the host to get info. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list