<div dir="ltr"><div><div>VDSM was built from:<br>commit 166138e37e75767b32227746bb671b1dab9cdd5e<br><br></div>Attached is the full vdsm log<br><br></div>I should also note that from engine perspective it sees the master storage domain as locked and the others as unknown. <br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 23, 2013 at 2:49 AM, Dan Kenigsberg <span dir="ltr"><<a href="mailto:danken@redhat.com" target="_blank">danken@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Jan 22, 2013 at 04:02:24PM -0600, Dead Horse wrote:<br>
> Any ideas on this one? (from VDSM log):<br>
> Thread-25::DEBUG::2013-01-22<br>
> 15:35:29,065::BindingXMLRPC::914::vds::(wrapper) client [3.57.111.30]::call<br>
> getCapabilities with () {}<br>
> Thread-25::ERROR::2013-01-22 15:35:29,113::netinfo::159::root::(speed)<br>
> cannot read ib0 speed<br>
> Traceback (most recent call last):<br>
> File "/usr/lib64/python2.6/site-packages/vdsm/netinfo.py", line 155, in<br>
> speed<br>
> s = int(file('/sys/class/net/%s/speed' % dev).read())<br>
> IOError: [Errno 22] Invalid argument<br>
><br>
> Causes VDSM to fail to attach storage<br>
<br>
</div>I doubt that this is the cause of the failure, as vdsm has always<br>
reported "0" for ib devices, and still is.<br>
<br>
Does a former version works with your Engine?<br>
Could you share more of your vdsm.log? I suppose the culprit lies in one<br>
one of the storage-related commands, not in statistics retrieval.<br>
<div><div class="h5"><br>
><br>
> Engine side sees:<br>
> ERROR [org.ovirt.engine.core.bll.storage.NFSStorageHelper]<br>
> (QuartzScheduler_Worker-96) [553ef26e] The connection with details<br>
> 192.168.0.1:/ovirt/ds failed because of error code 100 and error message<br>
> is: general exception<br>
> 2013-01-22 15:35:30,160 INFO<br>
> [org.ovirt.engine.core.bll.SetNonOperationalVdsCommand]<br>
> (QuartzScheduler_Worker-96) [1ab78378] Running command:<br>
> SetNonOperationalVdsCommand internal: true. Entities affected : ID:<br>
> 8970b3fe-1faf-11e2-bc1f-00151712f280 Type: VDS<br>
> 2013-01-22 15:35:30,200 INFO<br>
> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand]<br>
> (QuartzScheduler_Worker-96) [1ab78378] START,<br>
> SetVdsStatusVDSCommand(HostName = kezan, HostId =<br>
> 8970b3fe-1faf-11e2-bc1f-00151712f280, status=NonOperational,<br>
> nonOperationalReason=STORAGE_DOMAIN_UNREACHABLE), log id: 4af5c4cd<br>
> 2013-01-22 15:35:30,211 INFO<br>
> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand]<br>
> (QuartzScheduler_Worker-96) [1ab78378] FINISH, SetVdsStatusVDSCommand, log<br>
> id: 4af5c4cd<br>
> 2013-01-22 15:35:30,242 ERROR<br>
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]<br>
> (QuartzScheduler_Worker-96) [1ab78378] Try to add duplicate audit log<br>
> values with the same name. Type: VDS_SET_NONOPERATIONAL_DOMAIN. Value:<br>
> storagepoolname<br>
><br>
> Engine = latest master<br>
> VDSM = latest master<br>
<br>
</div></div>Since "latest master" is an unstable reference by definition, I'm sure<br>
that History would thank you if you post the exact version (git hash?)<br>
of the code.<br>
<br>
> node = el6<br>
<br>
</blockquote></div><br></div>