On 01/19/2012 02:28 PM, Daniel P. Berrange wrote:
On Thu, Jan 19, 2012 at 02:25:55PM +0100, Michal Novotny wrote:
> On 01/19/2012 02:20 PM, Daniel P. Berrange wrote:
>> On Thu, Jan 19, 2012 at 02:13:59PM +0100, Michal Novotny wrote:
>>> This patch introduces a new structure called virErrorsPtr which can get all
>>> the errors that occurred since the connection open. The error callback
function
>>> is being used as many times as necessary. The new public function called
>>> virGetAllErrors() has been introduced to get all the errors that occurred.
>> This impl is effectively an unbounded memory leak, if you consider
>> that applications will keep the same virConnectPtr open more or
>> less forever.
>>
>> In addition any libvirt API that raises multiple errors should be
>> considered broken, so I don't think we should have any such API
>> for querying multiple errors.
>>
>> What is the situation that motivated this new API ?
> This is simple. When you have situation with e.g. disk or domain
> creation. It fails but you don't know why. Sometimes the disk creation
> may fail on insufficient permissions and sometimes there may be not
> enough space etc... The same for domain creation.
But for any single API call into libvirt, there is only one
error that is relevant upon failure. If you are making a
sequence of multiple API calls, you should check each one
for an error, before trying the next call. Not doing so is
simply an application bug
Daniel
I can see your point Daniel and not I don't recall what we were talking
about with Peter exactly. Maybe he can recall so I'll leave it to him
but the truth is that I've been struggling with the reason of failure
and finally just the logging using the LIBVIRT_DEBUG=1 when running the
daemon helped me and I've been stuck before using it since the error was
masked by something AFAIK.
Michal
--
Michal Novotny <minovotn(a)redhat.com>, RHCE, Red Hat
Virtualization | libvirt-php bindings |
php-virt-control.org