<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 6, 2017 at 9:46 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="HOEnZb"><div class="h5">On Mon, Mar 6, 2017 at 10:11 AM, Piotr Kliczewski <<a href="mailto:pkliczew@redhat.com">pkliczew@redhat.com</a>> wrote:<br>
><br>
><br>
> On Mon, Mar 6, 2017 at 8:23 AM, Dan Kenigsberg <<a href="mailto:danken@redhat.com">danken@redhat.com</a>> wrote:<br>
>><br>
>> On Sun, Mar 5, 2017 at 9:50 PM, Piotr Kliczewski <<a href="mailto:pkliczew@redhat.com">pkliczew@redhat.com</a>><br>
>> wrote:<br>
>> ><br>
>> ><br>
>> > On Sun, Mar 5, 2017 at 8:29 AM, Dan Kenigsberg <<a href="mailto:danken@redhat.com">danken@redhat.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Piotr, could you provide more information?<br>
>> >><br>
>> >> Which setupNetworks action triggers this problem? Any idea which lock<br>
>> >> did we use to take and when did we drop it?<br>
>> ><br>
>> ><br>
>> > I though that this [1] would make sure that setupNetworks is exclusive<br>
>> > operation on a host which seems not to be the case.<br>
>> > In the logs I saw following message sent:<br>
>> ><br>
>> ><br>
>> > {"jsonrpc":"2.0","method":"<wbr>Host.setupNetworks","params":{<wbr>"networks":{"VLAN200_Network":<wbr>{"vlan":"200","netmask":"255.<wbr>255.255.0","ipv6autoconf":<wbr>false,"nic":"eth0","bridged":"<wbr>false","ipaddr":"192.0.3.1","<wbr>dhcpv6":false,"mtu":1500,"<wbr>switch":"legacy"}},"bondings":<wbr>{},"options":{"<wbr>connectivityTimeout":120,"<wbr>connectivityCheck":"true"}},"<wbr>id":"3f7f74ea-fc39-4815-831b-<wbr>5e3b1c22131d"}<br>
>> ><br>
>> > Few seconds later there was:<br>
>> ><br>
>> ><br>
>> > {"jsonrpc":"2.0","method":"<wbr>Host.getAllVmStats","params":{<wbr>},"id":"67d510eb-6dfc-4f67-<wbr>97b6-a4e63c670ff2"}<br>
>> ><br>
>> > and still while we were calling pings there was:<br>
>> ><br>
>> ><br>
>> > {"jsonrpc":"2.0","method":"<wbr>StoragePool.getSpmStatus","<wbr>params":{"storagepoolID":"<wbr>8cc227da-70e7-4557-aa01-<wbr>6d8ddee6f847"},"id":"d4d04c7c-<wbr>47b8-44db-867b-770e1e19361c"}<br>
>> ><br>
>> > My assumption was that those calls should not happen and calls them<br>
>> > selves<br>
>> > could be corrupted or their responses.<br>
>> > What do you think?<br>
>> ><br>
>> > [1]<br>
>> ><br>
>> > <a href="https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/network/host/HostSetupNetworksCommand.java#L285" rel="noreferrer" target="_blank">https://github.com/oVirt/<wbr>ovirt-engine/blob/master/<wbr>backend/manager/modules/bll/<wbr>src/main/java/org/ovirt/<wbr>engine/core/bll/network/host/<wbr>HostSetupNetworksCommand.java#<wbr>L285</a><br>
>><br>
>> I suspect that getVmStats and getSpmStatus simply do not take the<br>
>> hostmonitoring lock, and I don't see anything wrong in that.<br>
>><br>
>> Note that during 006_migration, we set only a mere migration network,<br>
>> not the management network. This operation should not interfere with<br>
>> Engine-Vdsm communication in any way; I don't yet understand why you<br>
>> suspect that it does.<br>
><br>
><br>
> My assumption here is that I saw this failure 2 times and both were during<br>
> setupNetworks.<br>
> The pattern is that always a call fails which "should not" occur during such<br>
> operation.<br>
><br>
<br>
</div></div>It is fair to suspect an interaction with setupNetworks, but let us<br>
put some substance into it.<br>
What is the mode of failure of the other command?<br>
</blockquote></div><br></div><div class="gmail_extra">I am not sure what do you mean. Can you please explain?<br></div><div class="gmail_extra"><br></div></div>