[libvirt] [PATCH 0/7] iothread api followups

John Ferlan jferlan at redhat.com
Thu Mar 26 10:34:32 UTC 2015


>> w/r/t patch 7 - while it's a "nice to have" I think its far more
>> relevant to list the Resource(s) associated with the thread than the CPU
>> time used. Listing the Resource was rejected in a much earlier patch
> 
> Actually, the "resources" is a configruation option and I don't see a
> way to change it unless you unplug the disk while CPU time is a
> statistics function that changes a lot.
> 

Correct, but I also think it's more useful to display resources in
IOThreads output.  If I'm a user I would rather know which resources are
assigned to which IOThreads rather than how much CPU Time they're using.
Since CPU Time is a statistic, perhaps it belongs in the stats output
rather than the IOThreads information output. As it stands, I have to
make my own "map" by dumping the xml, looking for the iothreads
attribute in a disk element and then do the correlation.

Again - don't forget to update the libvirt-python and libvirt-perl code.


>> review, so I don't see why listing the CPU time is important and failing
>> in qemuDomainGetIOThreadsLive because we cannot get the that time, but
>> yet deciding later on to not print it if it doesn't exist doesn't make
>> total sense.
> 
> If the VM is offline, then the CPU time is obviously not filled, while
> when it's live we should return it.

You missed my point - if for some reason we fail to get the CPU Time
from the QEMU call - we fail the entire call now.  If the time wasn't
available we don't print it.  So why fail the call just because the time
isn't available (for whatever reason).

It's not all that important, but once done I would hope the bz
associated will also get updated to list the new data column so that
whomever tests and documents this can do so properly.

John




More information about the libvir-list mailing list