On 28/01/15 14:20, Dan Kenigsberg wrote:
> On Tue, Jan 27, 2015 at 12:03:38PM +0200, Lior Vernia wrote:
>>
>>
>> On 26/01/15 15:45, Dan Kenigsberg wrote:
>>> On Mon, Dec 22, 2014 at 01:40:06PM +0200, Lior Vernia wrote:
Hello users and developers,
Just put up a feature page for the aforementioned feature; in summary,
to report total RX/TX statistics for hosts and VMs in oVirt. This has
been requested several times on the users mailing list, and is
especially useful for accounting in VDI deployments.
You're more than welcome to review the feature page:
http://www.ovirt.org/Features/Cumulative_RX_TX_Statistics
>>>
>>> Sorry for the late review; I have a couple of questions/comments.
>>> - What do you mean by "VDI use cases" in the "Benefit to oVirt sanpshot"
>>> section?
>>> Do you refer to hosting services who would like to charge their
>>> customers based on actual bandwidth usage?
>>
>> Indeed, as well as monitoring utilisation by non-paying users (say
>> inside the same organization). Changed the wording a little, as hosting
>> services are really the prime candidate.
>>
>>> - I've added another motivation: currently-reported rxRate/txRate
>>> can be utterly meaningless.
>>>
>>>
>>> I don't see reference to nasty negative flows: what happens if a host
>>> disappears? Or a VM? I suppose there's always a chance that some traffic
>>> would go unaccounted for. But do you expect to extract this information
>>> somehow? Either way, it should be mentioned as a caveat on the feature
>>> page.
>>>
>>
>> What do you mean by "disappears"? Engine loses connectivity to it?
>
> I meant the case of, say, Engine going down while VMs continue to chug
> bandwidth.
>
> One of these VMs dies (say, the user shuts it down). When Engine wakes
> up, it would find the VM in Down state. I wonder if Vdsm should keep the
> last tx/rx used by this VM so Engine can collect it, and charge the VM
> properly.
>
> A similar case can occur if a host is rebooted while Engine was away.
> But there I see no way to keep trace of the unaccounted-for badwidth.
>
This would require a double failure - first the engine losing
connectivity to the host, then at a later point the host/VM shuts down.
If the engine loses connectivity but the host/VMs remain operational,
then as soon as the engine regains connectivity it'll be brought up to
speed (traffic could be missed if the RX/TX counters on the host/VMs
exactly wrapped around during that period, which is highly unlikely). If
the host/VMs go down without the engine losing connectivity, the engine
should continue to accumulate statistics correctly.
So the problem isn't grave (though I'll document those cases in the
feature page), and the solution won't be trivial. Would you really want
vdsm to track this data? And then engine would have to collect it before
a VM is run or a vNIC is hot-plugged?...
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
