On Fri, Sep 16, 2016 at 10:49 AM, Michal Skrivanek < michal.skriva...@redhat.com> wrote:
> > > On 15 Sep 2016, at 18:18, Nir Soffer <nsof...@redhat.com> wrote: > > > > Hi all, > > > > Vdsm reports apparentsize and truesize disk stats [1] when getting > > vms stats (every 15 seconds?). These values are update every > > 60 seconds in vdsm. > > > > To collect the values, we run risky storage apis in vdsm virt thread > > pool, and we want to avoid this [2] since one slow or broken domain > > can cause the entire virt thread pool to get stuck and cause vms > > using other (healthy) storage domain to become non responsive. > > > > These can also break block storage thin provisioned disks, since they > > depend also on the virt thread pool. So one bad NFS storage domain > > can cause vms using only block storage to be paused. > > > > If both of these values are not used by anyone, we would like to > > stop reporting them. > > there are only 2 consumers of the monitoring, engine and mom. > git grep reveals that “apparentsize" is used only for importing HE. > “truesize" too, but additionally it is used in engine storage code as an > actual size of the disk > > > > > If the values are used, we need to find a safer way to report them, > > probably in storage thread pool, or maybe we can get these values > > from libvirt using bulk sampling. > > you could have been able to drop apparentsize right away, but the HE > import code is expecting that field and won’t be happy if it is missing > The monitoring code would work but fill in 0 for the actual size > Returning always 0 can be nice prank for the storage team :-) Looking in bulk stats, we already have the required info from libvirt: {'bcfa00d3-78a7-40c9-990e-5ffac8886ce0': {'balloon.current': 1048576L, 'balloon.maximum': 1048576L, 'block.0.allocation': 0L, 'block.0.fl.reqs': 0L, 'block.0.fl.times': 0L, 'block.0.name': 'hdc', 'block.0.physical': 0L, 'block.0.rd.bytes': 152L, 'block.0.rd.reqs': 4L, 'block.0.rd.times': 539801L, 'block.0.wr.bytes': 0L, 'block.0.wr.reqs': 0L, 'block.0.wr.times': 0L, 'block.1.allocation': 131005952L, 'block.1.capacity': 8589934592L, 'block.1.fl.reqs': 68L, 'block.1.fl.times': 1894725112L, 'block.1.name': 'vda', 'block.1.path': '/rhev/data-center/f9374c0e-ae24-4bc1-a596-f61d5f05bc5f/5f35b5c0-17d7-4475-9125-e97f1cdb06f9/images/c54e7894-b1dc-4f23-9ff5-1836259adc6d/133db162-6c6a-4e82-baae-9ae0e7e3885d', 'block.1.physical': 1073741824L, 'block.1.rd.bytes': 123849728L, 'block.1.rd.reqs': 7979L, 'block.1.rd.times': 10655381303L, 'block.1.wr.bytes': 16762880L, 'block.1.wr.reqs': 455L, 'block.1.wr.times': 6021639149L, 'block.2.allocation': 0L, 'block.2.capacity': 21474836480L, 'block.2.fl.reqs': 0L, 'block.2.fl.times': 0L, 'block.2.name': 'vdb', 'block.2.path': '/rhev/data-center/f9374c0e-ae24-4bc1-a596-f61d5f05bc5f/bb85ee2f-d674-489f-9377-3eb1f176e8fb/images/b59304f3-d19d-40dd-9f04-8c2df37ef6d3/4df47a96-8a1b-436e-8a3e-3a638f119b48', 'block.2.physical': 21474836480L, 'block.2.rd.bytes': 1389056L, 'block.2.rd.reqs': 331L, 'block.2.rd.times': 160943568L, 'block.2.wr.bytes': 0L, 'block.2.wr.reqs': 0L, 'block.2.wr.times': 0L, 'block.count': 3, 'cpu.system': 19090000000L, 'cpu.time': 53480823390L, 'cpu.user': 4650000000L, 'net.0.name': 'vnet0', 'net.0.rx.bytes': 2595857L, 'net.0.rx.drop': 0L, 'net.0.rx.errs': 0L, 'net.0.rx.pkts': 39957L, 'net.0.tx.bytes': 17041L, 'net.0.tx.drop': 0L, 'net.0.tx.errs': 0L, 'net.0.tx.pkts': 177L, 'net.count': 1, 'state.reason': 1, 'state.state': 1, 'vcpu.0.state': 1, 'vcpu.0.time': 43040000000L, 'vcpu.0.wait': 0L, 'vcpu.current': 1, 'vcpu.maximum': 16}} So we can extract the values from the stats cache matching them using drive.path. We are already doing this for block.*.rd.bytes etc. Francesco, what do you think? > > > > > Please update if these values are used in engine/dwh. > > > > [1] https://github.com/oVirt/vdsm/blob/master/lib/vdsm/virt/ > vmstats.py#L364 > > [2] https://gerrit.ovirt.org/59801 > > > > Nir > > _______________________________________________ > > Devel mailing list > > Devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > >
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel