On 11.12.18, 00:41, "Jim Fehlig" <jfehlig@xxxxxxxx> wrote:
On 12/7/18 11:12 AM, Michael Trapp wrote:
> There is no need to keep the dump_virtio code in a separate library.
> Revert libserialclient changes and move the code to libmetrics.
>
> ---
>
> vm-dump-metrics tries to access the metrics disk without a check of the
> transport methods because the access is located in the libmetrics
> constructor this can't be changed in vm-dump-metrics.
Yeah, it is tough to change the constructor without changing the library
behavior in some small way.
>
> libmetrics.c:
> void __attribute__ ((constructor)) libmetrics_init(void)
> ...
> if (read_mdisk(mdisk) != 0) {
> libmsg("%s(): Unable to read metrics disk\n", __func__);
>
> Whith virtio transport we can't expect a metrics disk and should avoid the
> error. One option is to remove read_mdisk() from the constructor, initialize
> mdisk->sum and rely on the read_mdisk() call in read_mdisk_sum().
I never liked the idea of this library and as I recall protested its addition to
vhostmd many, many years ago :-). I preferred a simple app (aka vm-dump-metrics)
that would simply dump an XML doc of metrics and let the consumer do with it as
they please. Do you use the library, or only vm-dump-metrics?
We don't use the library, vm-dump-metrics is sufficient for our use case and
in addition, with vm-dump-metrics we don't care about changes like a new transport method
> This should be discussed and fixed in another patch.
While we're on the topic, I'll discuss it briefly here, but yes needs to be
fixed in a separate patch.
I can think of two options for a fix. Option 1, as you suggest, is to remove
read_mdisk() from the constructor. IMO, mdisk->sum should be left at 0 as
initialized by mdisk_alloc(). We'd need to fixup dump_metrics() to handle that,
similar to get_metrics().
Option 2 is adjust the constructor to try populating the metric_disk structure
with read_mdisk() first, then with virtio, and only fail if both are
unavailable. One upshot of this approach is that the get*_metric APIs would work
with virtio by adjusting get_metrics() to handle disk or virtio transport. One
downside of this approach is abusing the poorly named "metric_disk" structure.
I.e. we'd be populating the structure from virtio instead of a disk. In
hindsight "metric_source" or "metric_block" or "metric_packet" or about anything
else would have been a better name than "metric_disk" :-).
I tend to prefer option 2 since the get*_metric APIs would work with virtio
transport. Do you have a preference, or alternative option?
Option 2 would also provide virtio support in libmetrics but from my perspective there
is no need to have libmetrics available with the vhostmd package.
If it's an option to deprecate libmetrics, I would vote for option 1 and in a next step the
mdisk access could be replaced with a simple dump of the content of the block device.
Regards
Michael
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
