Hi,
On Thu, November 10, 2016 11:04 am, Piotr Kliczewski wrote:
[snip]
>> Could you explain the above error? I'm not sure I understand what it
>> means. I do, however, know what the following error is about. I
>> attempted to import an OVA file and the file was mode 600 root:root and
>> therefore was not readable by VDSM. Hence the "Errno 13: Permission
>> Denied":
>>
>
> I added the stack traces to the email because I want someone from
> storage and virt to take a look
> at those failures. Maybe both were fixed already.
The second stack trace, I presume, is due to my permission problem. If so
then that's my own doing and not something to fix in oVirt. (Unless my
assumption is incorrect, but at the time the .ova file *was* unreadable).
>>> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
>>> VDSGenericException: VDSErrorException: Failed to GetOvaInfoVDS, error
>>> = [Errno 13] Permission denied:
>>> u'/ovirt/import/openafs-fc23-64.ihtfp.org.ova', code = -32603 (Failed
>>> with error unexpected and code 16)
>>> at
>> [snip]
>>>
>>> both not related to reconnects.
>>
>> Agreed.
>>
>>> I see that from time to time there are connections reset by peer
>>>
>>> 2016-11-04 10:58:43,442 ERROR
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.GetStatsVDSCommand]
>>> (DefaultQuartzScheduler6) [77387d45] Command
>>> 'GetStatsVDSCommand(HostName = ovirt-0,
>>> VdsIdAndVdsVDSCommandParametersBase:{runAsync='true',
>>> hostId='62b75bb9-fbd9-405f-b479-b6ad8cffd5b1',
>>> vds='Host[ovirt-0,62b75bb9-fbd9-405f-b479-b6ad8cffd5b1]'})' execution
>>> failed: VDSGenericException: VDSNetworkException: Connection reset by
>>> peer
>>>
>>> which means that vdsm or the host was stopped. Vdsm log you provided
>>> do not cover this time so I am not able to say what is the cause of
>>> it.
>>
>> Yeah, Nov 4 was approximately the time I was installing the systems, so
>> yes, it's not surprising to see some up and down times around then.
>>
>>>
>>> There are more 'unexpected eof' in the logs but they seems not to be
>>> triggered by the engine. It looks like those connection are triggered
>>> from local host.
>>> This seems to be related to https://bugzilla.redhat.com/1349829
>>
>> Is there something I can do to test/verify this?
>
> It needs to be fixed first. I added it as reference for you.
Thanks. I was more asking if there is some way to verify that this *is*
the bug I'm hitting? Otherwise I have to wait for the fix for this bug
and only then can I see if it actually fixes this issue or if it's
something else.
I'm not sure why not re-using the session would cause an EOF Error.
Thanks,
-derek
--
Derek Atkins 617-623-3745
de...@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
