Martin Sivák has posted comments on this change.

Change subject: Collect current QoS settings for IO devices and report through 
RunningVmStats
......................................................................


Patch Set 6:

(4 comments)

I can't persist the data when I change them, because libvirt can change the 
values. I can't do this only when MOM asks for it, because MOM asks for 
everything every 10 seconds (which is more often than in this patch).

The only thing I can do is to change the period to about 60s, because that is 
probably enough for our purposes.

Unless you give me a way to collect libvirt data in less cpu intensive way, I 
can't change this to get reliable data so it really does not matter.

I understand that parsing XML is hard, but the xml is the official libvirt API. 
And as far as I know, vdsm does not refresh the xml by itself so I can't just 
traverse the DOM of already parsed document.

http://gerrit.ovirt.org/#/c/28712/6/lib/vdsm/config.py.in
File lib/vdsm/config.py.in:

Line 189:         ('vm_sample_vcpu_pin_window', '2', None),
Line 190: 
Line 191:         ('vm_sample_cpu_tune_interval', '15', None),
Line 192: 
Line 193:         ('vm_sample_io_tune_interval', '15', None),
> Since we need to parse the full domain XML at each run ( :( ), any chance t
MOM reevaluates its rules every 10 seconds by default. But I guess we could 
increase this to once per minute or so.
Line 194: 
Line 195:         ('trust_store_path', '@TRUSTSTORE@',
Line 196:             'Where the certificates and keys are situated.'),
Line 197: 


http://gerrit.ovirt.org/#/c/28712/6/vdsm/virt/vm.py
File vdsm/virt/vm.py:

Line 331:             infos['vcpuLimit'] = nodeList[0].childNodes[0].data
Line 332: 
Line 333:         return infos
Line 334: 
Line 335:     def _sampleIoTune(self):
> But why every 2 seconds? How often these values may change?
Where do you see two seconds? The default was 15.
Line 336:         info = []
Line 337: 
Line 338:         try:
Line 339:             lastXMLDesc = self._vm._dom.XMLDesc(0)


Line 338:         try:
Line 339:             lastXMLDesc = self._vm._dom.XMLDesc(0)
Line 340:         except libvirt.libvirtError:
Line 341:             self._log.exception("Error while collecting ioTune for 
%s",
Line 342:                                 self._vm.name)
> This may flood the logs - is there anything useful in this traceback?
Not being able to colelct data from libvirt is a serious issue. That is what 
the logs are for.
Line 343:             return None
Line 344: 
Line 345:         devxml = _domParseStr(lastXMLDesc).childNodes[0] \
Line 346:             .getElementsByTagName('devices')[0]


Line 607:         self._getDiskStats(stats)
Line 608:         self._getDiskLatency(stats)
Line 609:         self._getBalloonStats(stats)
Line 610:         self._getVmJobs(stats)
Line 611:         self._getIoTuneStats(stats)
> +1
All the following calls are QoS code as well.

But if it makes you happy..
Line 612: 
Line 613:         vmNumaNodeRuntimeMap = 
numaUtils.getVmNumaNodeRuntimeInfo(self._vm)
Line 614:         if vmNumaNodeRuntimeMap:
Line 615:             stats['vNodeRuntimeInfo'] = vmNumaNodeRuntimeMap


-- 
To view, visit http://gerrit.ovirt.org/28712
To unsubscribe, visit http://gerrit.ovirt.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ie4fab132b60ce6ae2285115034f3d1ffcdca9e9d
Gerrit-PatchSet: 6
Gerrit-Project: vdsm
Gerrit-Branch: master
Gerrit-Owner: Martin Sivák <msi...@redhat.com>
Gerrit-Reviewer: Dan Kenigsberg <dan...@redhat.com>
Gerrit-Reviewer: Federico Simoncelli <fsimo...@redhat.com>
Gerrit-Reviewer: Francesco Romani <from...@redhat.com>
Gerrit-Reviewer: Martin Sivák <msi...@redhat.com>
Gerrit-Reviewer: Michal Skrivanek <michal.skriva...@redhat.com>
Gerrit-Reviewer: Nir Soffer <nsof...@redhat.com>
Gerrit-Reviewer: automat...@ovirt.org
Gerrit-Reviewer: oVirt Jenkins CI Server
Gerrit-HasComments: Yes
_______________________________________________
vdsm-patches mailing list
vdsm-patches@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-patches

Reply via email to