<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 30, 2017 at 1:55 PM, Florian Schmid <span dir="ltr">&lt;<a href="mailto:fschmid@ubimet.com" target="_blank">fschmid@ubimet.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div>Hi Yaniv,</div><div><br></div><div>thank you for your answer! I haven&#39;t known, that there is already such a monitoring tool on ovirt.</div><div><br></div><div>We will sure give it a try, but we have already in our environment a monitoring tool, that&#39;s why I wanted to add those values, too.</div><div><br></div><div>How does collectd get this data from libvirt, when the corresponding cgroup values are empty?</div></div></div></blockquote><div><br></div><div>Specifically for IO statistics, VDSM reads the values from libvirt[1]. cgroup limiting is possible if you define it, but is unrelated.</div><div>Also note that 7.3 is a bit ancient, I&#39;m not sure how supported it is with latest 4.1 - which I&#39;m sure will pull new dependencies from 7.4 (for example, libvirt!).</div><div><br></div><div>Y.</div><div>[1] <a href="https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=lib/vdsm/virt/vmstats.py;h=5043e8b3e44457cec99205939472fda14bd130a8;hb=HEAD#l458">https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=lib/vdsm/virt/vmstats.py;h=5043e8b3e44457cec99205939472fda14bd130a8;hb=HEAD#l458</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div><br></div><div>BR Florian</div><div><div><p style="margin-bottom:0cm"><a class="gmail-m_4128667035026864582mceItemAnchor" name="m_4128667035026864582_OBJ_PREFIX_DWT8057_com_zimbra_url"></a><a class="gmail-m_4128667035026864582mceItemAnchor" name="m_4128667035026864582_OBJ_PREFIX_DWT1086_com_zimbra_url"></a><a class="gmail-m_4128667035026864582mceItemAnchor" name="m_4128667035026864582_OBJ_PREFIX_DWT8058_com_zimbra_url"></a> <span style="color:rgb(179,179,179)"></span></p></div></div><br><hr id="gmail-m_4128667035026864582zwchr"><div><b>Von: </b>&quot;Yaniv Kaul&quot; &lt;<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a>&gt;<br><b>An: </b>&quot;Florian Schmid&quot; &lt;<a href="mailto:fschmid@ubimet.com" target="_blank">fschmid@ubimet.com</a>&gt;<br><b>CC: </b>&quot;users&quot; &lt;<a href="mailto:users@ovirt.org" target="_blank">users@ovirt.org</a>&gt;<br><b>Gesendet: </b>Dienstag, 27. Juni 2017 09:08:51<br><b>Betreff: </b>Re: [ovirt-users] Empty cgroup files on centos 7.3 host<br></div><div><div class="gmail-h5"><br><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 26, 2017 at 11:03 PM, Florian Schmid <span dir="ltr">&lt;<a href="mailto:fschmid@ubimet.com" target="_blank">fschmid@ubimet.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I wanted to monitor disk IO and R/W on all of our oVirt centos 7.3 hypervisor hosts, but it looks like that all those files are empty.<br></blockquote><br><div>We have a very nice integration with Elastic based monitoring and logging - why not use it.</div><div>On the host, we use collectd for monitoring.</div><div>See <a href="http://www.ovirt.org/develop/release-management/features/engine/metrics-store/" target="_blank">http://www.ovirt.org/develop/<wbr>release-management/features/<wbr>engine/metrics-store/</a></div><br><div>Y.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For example:<br>
ls -al /sys/fs/cgroup/blkio/machine.<wbr>slice/machine-qemu\\x2d14\\<wbr>x2dHostedEngine.scope/<br>
insgesamt 0<br>
drwxr-xr-x.  2 root root 0 30. Mai 10:09 .<br>
drwxr-xr-x. 16 root root 0 26. Jun 09:25 ..<br>
-r--r--r--.  1 root root 0 30. Mai 10:09 blkio.io_merged<br>
-r--r--r--.  1 root root 0 30. Mai 10:09 blkio.io_merged_recursive<br>
-r--r--r--.  1 root root 0 30. Mai 10:09 blkio.io_queued<br>
-r--r--r--.  1 root root 0 30. Mai 10:09 blkio.io_queued_recursive<br>
-r--r--r--.  1 root root 0 30. Mai 10:09 blkio.io_service_bytes<br>
-r--r--r--.  1 root root 0 30. Mai 10:09 blkio.io_service_bytes_<wbr>recursive<br>
-r--r--r--.  1 root root 0 30. Mai 10:09 blkio.io_serviced<br>
-r--r--r--.  1 root root 0 30. Mai 10:09 blkio.io_serviced_recursive<br>
-r--r--r--.  1 root root 0 30. Mai 10:09 blkio.io_service_time<br>
-r--r--r--.  1 root root 0 30. Mai 10:09 blkio.io_service_time_<wbr>recursive<br>
-r--r--r--.  1 root root 0 30. Mai 10:09 blkio.io_wait_time<br>
-r--r--r--.  1 root root 0 30. Mai 10:09 blkio.io_wait_time_recursive<br>
-rw-r--r--.  1 root root 0 30. Mai 10:09 blkio.leaf_weight<br>
-rw-r--r--.  1 root root 0 30. Mai 10:09 blkio.leaf_weight_device<br>
--w-------.  1 root root 0 30. Mai 10:09 blkio.reset_stats<br>
-r--r--r--.  1 root root 0 30. Mai 10:09 blkio.sectors<br>
-r--r--r--.  1 root root 0 30. Mai 10:09 blkio.sectors_recursive<br>
-r--r--r--.  1 root root 0 30. Mai 10:09 blkio.throttle.io_service_<wbr>bytes<br>
-r--r--r--.  1 root root 0 30. Mai 10:09 blkio.throttle.io_serviced<br>
-rw-r--r--.  1 root root 0 30. Mai 10:09 blkio.throttle.read_bps_device<br>
-rw-r--r--.  1 root root 0 30. Mai 10:09 blkio.throttle.read_iops_<wbr>device<br>
-rw-r--r--.  1 root root 0 30. Mai 10:09 blkio.throttle.write_bps_<wbr>device<br>
-rw-r--r--.  1 root root 0 30. Mai 10:09 blkio.throttle.write_iops_<wbr>device<br>
-r--r--r--.  1 root root 0 30. Mai 10:09 blkio.time<br>
-r--r--r--.  1 root root 0 30. Mai 10:09 blkio.time_recursive<br>
-rw-r--r--.  1 root root 0 30. Mai 10:09 blkio.weight<br>
-rw-r--r--.  1 root root 0 30. Mai 10:09 blkio.weight_device<br>
-rw-r--r--.  1 root root 0 30. Mai 10:09 cgroup.clone_children<br>
--w--w--w-.  1 root root 0 30. Mai 10:09 cgroup.event_control<br>
-rw-r--r--.  1 root root 0 30. Mai 10:09 cgroup.procs<br>
-rw-r--r--.  1 root root 0 30. Mai 10:09 notify_on_release<br>
-rw-r--r--.  1 root root 0 30. Mai 10:09 tasks<br>
<br>
<br>
I thought, I can get my needed values from there, but all files are empty.<br>
<br>
Looking at this post: <a href="http://lists.ovirt.org/pipermail/users/2017-January/079011.html" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>pipermail/users/2017-January/<wbr>079011.html</a><br>
this should work.<br>
<br>
Is this normal on centos 7.3 with oVirt installed? How can I get those values, without monitoring all VMs directly?<br>
<br>
oVirt Version we use:<br>
4.1.1.8-1.el7.centos<br>
<br>
BR Florian<br>
______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/users</a><br>
</blockquote></div></div></div><br></div></div></div></div></div></blockquote></div><br></div></div>