<div dir="ltr">Somehow my NFS domain got to be master again.  I went into the database and updated the connections for NFS and I noticed that once I updated the IP for the ISCSI in the &quot;storage_server_connections&quot; table that the interface kept moving &quot;(master)&quot; between the iSCSI and NFS domain...very odd.<div><br></div><div>I did these commands and now NFS is up.</div><div><br></div><div><div>update storage_server_connections set connection=&#39;10.0.0.10:/tank/ovirt/data&#39; where id=&#39;a89fa66b-8737-4bb8-a089-d9067f61b58a&#39;;</div><div>update storage_server_connections set connection=&#39;10.0.0.10:/tank/ovirt/import_export&#39; where id=&#39;521a8477-9e88-4f2d-96e2-d3667ec407df&#39;;</div><div>update storage_server_connections set connection=&#39;192.168.202.245:/tank/ovirt/iso&#39; where id=&#39;fb55cfea-c7ef-49f2-b77f-16ddd2de0f7a&#39;;</div><div>update storage_server_connections set connection=&#39;10.0.0.10&#39; where id=&#39;d6da7fbf-5056-44a7-9fc8-e76a1ff9f525&#39;;</div><div><br></div><div>Once I activated the NFS master domain all my other domains went to active, including iSCSI.</div><div><br></div><div>My concern now is whether the iSCSI domain is usable.  The API path at &quot;/api/storagedomains/4eeb8415-c912-44bf-b482-2673849705c9/storageconnections&quot; shows </div><div><br></div><div>&lt;storage_connections/&gt;</div><div><br></div><div>If I go to edit the iSCSI domain and check the LUN the warning I get is this:</div><div><br></div><div><div>This operation might be unrecoverable and destructive!</div><div>The following LUNs are already in use:</div><div>- 1IET_00010001 (Used by VG: 3nxXNr-bIHu-9YS5-Kfzc-A2Na-sMhb-jihwdt)</div></div><div><br></div><div>That alone makes me very hesitant to approve the operation.  I could use some wisdom if this is safe or not.</div><div><br></div><div>Thanks,</div><div>- Trey</div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 21, 2014 at 3:17 PM, Trey Dockendorf <span dir="ltr">&lt;<a href="mailto:treydock@gmail.com" target="_blank">treydock@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">John,<div><br></div><div>Thanks for reply.  The Discover function in GUI works...it&#39;s once I try and login (Click the array next to target) that things just hang indefinitely.</div><div><br></div><div><div># iscsiadm -m session</div><div>tcp: [2] <a href="http://10.0.0.10:3260" target="_blank">10.0.0.10:3260</a>,1 iqn.2014-04.edu.tamu.brazos.vmstore1:ovirt-data_iscsi</div></div><div><br></div><div><div># iscsiadm -m node</div><div><a href="http://10.0.0.10:3260" target="_blank">10.0.0.10:3260</a>,1 iqn.2014-04.edu.tamu.brazos.vmstore1:ovirt-data_iscsi</div></div><div><br></div><div><div># multipath -ll</div><div>1IET_00010001 dm-3 IET,VIRTUAL-DISK</div><div>size=500G features=&#39;0&#39; hwhandler=&#39;0&#39; wp=rw</div><div>`-+- policy=&#39;round-robin 0&#39; prio=1 status=active</div><div>  `- 8:0:0:1 sdd 8:48 active ready running</div><div>1ATA_WDC_WD5003ABYZ-011FA0_WD-WMAYP0DNSAEZ dm-2 ATA,WDC WD5003ABYZ-0</div><div>size=466G features=&#39;0&#39; hwhandler=&#39;0&#39; wp=rw</div><div>`-+- policy=&#39;round-robin 0&#39; prio=1 status=active</div><div>  `- 3:0:0:0 sdc 8:32 active ready running</div></div><div><br></div><div>The first entry, 1IET_00010001 is the iSCSI LUN.</div><div><br></div><div>The log when I click the array in the interface for the target is this:</div><div><br></div><div><div>Thread-14::DEBUG::2014-10-21 15:12:49,900::BindingXMLRPC::251::vds::(wrapper) client [192.168.202.99] flowID [7177dafe]</div><div>Thread-14::DEBUG::2014-10-21 15:12:49,901::task::595::TaskManager.Task::(_updateState) Task=`01d8d01e-8bfd-4764-890f-2026fdeb78d9`::moving from state init -&gt; state preparing</div><div>Thread-14::INFO::2014-10-21 15:12:49,901::logUtils::44::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=3, spUUID=&#39;00000000-0000-0000-0000-000000000000&#39;, conList=[{&#39;connection&#39;: &#39;10.0.0.10&#39;, &#39;iqn&#39;: &#39;iqn.2014-04.edu.tamu.brazos.)</div><div>Thread-14::DEBUG::2014-10-21 15:12:49,902::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) &#39;/usr/bin/sudo -n /sbin/iscsiadm -m node -T iqn.2014-04.edu.tamu.brazos.vmstore1:ovirt-data_iscsi -I default -p <a href="http://10.0.0.10:3260" target="_blank">10.0.0.10:3260</a>,1 --op=new&#39; (cwd None)</div><div>Thread-14::DEBUG::2014-10-21 15:12:56,684::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) SUCCESS: &lt;err&gt; = &#39;&#39;; &lt;rc&gt; = 0</div><div>Thread-14::DEBUG::2014-10-21 15:12:56,685::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) &#39;/usr/bin/sudo -n /sbin/iscsiadm -m node -T iqn.2014-04.edu.tamu.brazos.vmstore1:ovirt-data_iscsi -I default -p <a href="http://10.0.0.10:3260" target="_blank">10.0.0.10:3260</a>,1 -l&#39; (cwd None)</div><div>Thread-14::DEBUG::2014-10-21 15:12:56,711::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) SUCCESS: &lt;err&gt; = &#39;&#39;; &lt;rc&gt; = 0</div><div>Thread-14::DEBUG::2014-10-21 15:12:56,711::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) &#39;/usr/bin/sudo -n /sbin/iscsiadm -m node -T iqn.2014-04.edu.tamu.brazos.vmstore1:ovirt-data_iscsi -I default -p <a href="http://10.0.0.10:3260" target="_blank">10.0.0.10:3260</a>,1 -n node.startup -v manual --op)</div><div>Thread-14::DEBUG::2014-10-21 15:12:56,767::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) SUCCESS: &lt;err&gt; = &#39;&#39;; &lt;rc&gt; = 0</div><div>Thread-14::DEBUG::2014-10-21 15:12:56,767::lvm::373::OperationMutex::(_reloadvgs) Operation &#39;lvm reload operation&#39; got the operation mutex</div><div>Thread-14::DEBUG::2014-10-21 15:12:56,768::lvm::296::Storage.Misc.excCmd::(cmd) &#39;/usr/bin/sudo -n /sbin/lvm vgs --config &quot; devices { preferred_names = [\\&quot;^/dev/mapper/\\&quot;] ignore_suspended_devices=1 write_cache_state=0 disable_after_error_count=3)</div><div>Thread-14::DEBUG::2014-10-21 15:12:56,968::lvm::296::Storage.Misc.excCmd::(cmd) SUCCESS: &lt;err&gt; = &#39;  No volume groups found\n&#39;; &lt;rc&gt; = 0</div><div>Thread-14::DEBUG::2014-10-21 15:12:56,969::lvm::415::OperationMutex::(_reloadvgs) Operation &#39;lvm reload operation&#39; released the operation mutex</div><div>Thread-14::DEBUG::2014-10-21 15:12:56,974::hsm::2352::Storage.HSM::(__prefetchDomains) Found SD uuids: ()</div><div>Thread-14::DEBUG::2014-10-21 15:12:56,974::hsm::2408::Storage.HSM::(connectStorageServer) knownSDs: {}</div><div>Thread-14::INFO::2014-10-21 15:12:56,974::logUtils::47::dispatcher::(wrapper) Run and protect: connectStorageServer, Return response: {&#39;statuslist&#39;: [{&#39;status&#39;: 0, &#39;id&#39;: &#39;00000000-0000-0000-0000-000000000000&#39;}]}</div><div>Thread-14::DEBUG::2014-10-21 15:12:56,974::task::1185::TaskManager.Task::(prepare) Task=`01d8d01e-8bfd-4764-890f-2026fdeb78d9`::finished: {&#39;statuslist&#39;: [{&#39;status&#39;: 0, &#39;id&#39;: &#39;00000000-0000-0000-0000-000000000000&#39;}]}</div><div>Thread-14::DEBUG::2014-10-21 15:12:56,975::task::595::TaskManager.Task::(_updateState) Task=`01d8d01e-8bfd-4764-890f-2026fdeb78d9`::moving from state preparing -&gt; state finished</div><div>Thread-14::DEBUG::2014-10-21 15:12:56,975::resourceManager::940::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {}</div><div>Thread-14::DEBUG::2014-10-21 15:12:56,975::resourceManager::977::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {}</div><div>Thread-14::DEBUG::2014-10-21 15:12:56,975::task::990::TaskManager.Task::(_decref) Task=`01d8d01e-8bfd-4764-890f-2026fdeb78d9`::ref 0 aborting False</div><div>Thread-13::DEBUG::2014-10-21 15:13:18,281::task::595::TaskManager.Task::(_updateState) Task=`8674b6b0-5e4c-4f0c-8b6b-c5fa5fef6126`::moving from state init -&gt; state preparing</div><div>Thread-13::INFO::2014-10-21 15:13:18,281::logUtils::44::dispatcher::(wrapper) Run and protect: repoStats(options=None)</div><div>Thread-13::INFO::2014-10-21 15:13:18,282::logUtils::47::dispatcher::(wrapper) Run and protect: repoStats, Return response: {}</div><div>Thread-13::DEBUG::2014-10-21 15:13:18,282::task::1185::TaskManager.Task::(prepare) Task=`8674b6b0-5e4c-4f0c-8b6b-c5fa5fef6126`::finished: {}</div><div>Thread-13::DEBUG::2014-10-21 15:13:18,282::task::595::TaskManager.Task::(_updateState) Task=`8674b6b0-5e4c-4f0c-8b6b-c5fa5fef6126`::moving from state preparing -&gt; state finished</div><div>Thread-13::DEBUG::2014-10-21 15:13:18,282::resourceManager::940::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {}</div><div>Thread-13::DEBUG::2014-10-21 15:13:18,282::resourceManager::977::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {}</div><div>Thread-13::DEBUG::2014-10-21 15:13:18,283::task::990::TaskManager.Task::(_decref) Task=`8674b6b0-5e4c-4f0c-8b6b-c5fa5fef6126`::ref 0 aborting False</div></div><div><br></div><div>The lines prefixed with &quot;Thread-13&quot; just repeat over and over only changing the Task value.</div><div><br></div><div>Unsure what could be done to restore things.  The iscsi connection is good and I&#39;m able to see the logical volumes:</div><div><br></div><div><div># lvscan</div><div>  ACTIVE            &#39;/dev/4eeb8415-c912-44bf-b482-2673849705c9/metadata&#39; [512.00 MiB] inherit</div><div>  ACTIVE            &#39;/dev/4eeb8415-c912-44bf-b482-2673849705c9/leases&#39; [2.00 GiB] inherit</div><div>  ACTIVE            &#39;/dev/4eeb8415-c912-44bf-b482-2673849705c9/ids&#39; [128.00 MiB] inherit</div><div>  ACTIVE            &#39;/dev/4eeb8415-c912-44bf-b482-2673849705c9/inbox&#39; [128.00 MiB] inherit</div><div>  ACTIVE            &#39;/dev/4eeb8415-c912-44bf-b482-2673849705c9/outbox&#39; [128.00 MiB] inherit</div><div>  ACTIVE            &#39;/dev/4eeb8415-c912-44bf-b482-2673849705c9/master&#39; [1.00 GiB] inherit</div><div>  inactive          &#39;/dev/4eeb8415-c912-44bf-b482-2673849705c9/aced9726-5a28-4d52-96f5-89553ba770af&#39; [100.00 GiB] inherit</div><div>  inactive          &#39;/dev/4eeb8415-c912-44bf-b482-2673849705c9/87bf28aa-be25-4a93-9b23-f70bfd8accc0&#39; [1.00 GiB] inherit</div><div>  inactive          &#39;/dev/4eeb8415-c912-44bf-b482-2673849705c9/27256587-bf87-4519-89e7-260e13697de3&#39; [20.00 GiB] inherit</div><div>  inactive          &#39;/dev/4eeb8415-c912-44bf-b482-2673849705c9/ac2cb7f9-1df9-43dc-9fda-8a9958ef970f&#39; [20.00 GiB] inherit</div><div>  inactive          &#39;/dev/4eeb8415-c912-44bf-b482-2673849705c9/d8c41f05-006a-492b-8e5f-101c4e113b28&#39; [100.00 GiB] inherit</div><div>  inactive          &#39;/dev/4eeb8415-c912-44bf-b482-2673849705c9/83f17e9b-183e-4bad-ada5-bcef1c5c8e6a&#39; [20.00 GiB] inherit</div><div>  inactive          &#39;/dev/4eeb8415-c912-44bf-b482-2673849705c9/cf79052e-b4ef-4bda-96dc-c53b7c2acfb5&#39; [20.00 GiB] inherit</div><div>  ACTIVE            &#39;/dev/vg_ovirtnode02/lv_swap&#39; [46.59 GiB] inherit</div><div>  ACTIVE            &#39;/dev/vg_ovirtnode02/lv_root&#39; [418.53 GiB] inherit</div></div><div><br></div><div>Thanks,</div><div>- Trey</div><div><br></div><div><br></div></div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 21, 2014 at 2:49 PM, Sandra Taylor <span dir="ltr">&lt;<a href="mailto:jtt77777@gmail.com" target="_blank">jtt77777@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Trey,<br>
Sorry for your trouble.<br>
Don&#39;t know if I can help but I run iscsi here as my primary domain so<br>
I&#39;ve had some experience with it.<br>
I don&#39;t know the answer to the master domain question.<br>
<br>
Does iscsi show connected  using iscsiadm -m session and   -m node  ?<br>
in the vdsm log there should be the iscsiadm commands that were<br>
executed to connect.<br>
Does multipath -ll show anything?<br>
<br>
-John<br>
<div><div><br>
On Tue, Oct 21, 2014 at 3:18 PM, Trey Dockendorf &lt;<a href="mailto:treydock@gmail.com" target="_blank">treydock@gmail.com</a>&gt; wrote:<br>
&gt; I was able to get iSCSI over TCP working...but now the task of adding the<br>
&gt; LUN to the GUI has been stuck at the &quot;spinning&quot; icon for about 20 minutes.<br>
&gt;<br>
&gt; I see these entries in vdsm.log over and over with the Task value changing:<br>
&gt;<br>
&gt; Thread-14::DEBUG::2014-10-21<br>
&gt; 14:16:50,086::task::595::TaskManager.Task::(_updateState)<br>
&gt; Task=`ebcd8e0a-54b1-43d2-92a2-ed9fd62d00fa`::moving from state init -&gt; state<br>
&gt; preparing<br>
&gt; Thread-14::INFO::2014-10-21<br>
&gt; 14:16:50,086::logUtils::44::dispatcher::(wrapper) Run and protect:<br>
&gt; repoStats(options=None)<br>
&gt; Thread-14::INFO::2014-10-21<br>
&gt; 14:16:50,086::logUtils::47::dispatcher::(wrapper) Run and protect:<br>
&gt; repoStats, Return response: {}<br>
&gt; Thread-14::DEBUG::2014-10-21<br>
&gt; 14:16:50,087::task::1185::TaskManager.Task::(prepare)<br>
&gt; Task=`ebcd8e0a-54b1-43d2-92a2-ed9fd62d00fa`::finished: {}<br>
&gt; Thread-14::DEBUG::2014-10-21<br>
&gt; 14:16:50,087::task::595::TaskManager.Task::(_updateState)<br>
&gt; Task=`ebcd8e0a-54b1-43d2-92a2-ed9fd62d00fa`::moving from state preparing -&gt;<br>
&gt; state finished<br>
&gt; Thread-14::DEBUG::2014-10-21<br>
&gt; 14:16:50,087::resourceManager::940::ResourceManager.Owner::(releaseAll)<br>
&gt; Owner.releaseAll requests {} resources {}<br>
&gt; Thread-14::DEBUG::2014-10-21<br>
&gt; 14:16:50,087::resourceManager::977::ResourceManager.Owner::(cancelAll)<br>
&gt; Owner.cancelAll requests {}<br>
&gt; Thread-14::DEBUG::2014-10-21<br>
&gt; 14:16:50,087::task::990::TaskManager.Task::(_decref)<br>
&gt; Task=`ebcd8e0a-54b1-43d2-92a2-ed9fd62d00fa`::ref 0 aborting False<br>
&gt;<br>
&gt; What is there I can do to get my storage back online?  Right now my iSCSI is<br>
&gt; master (something I did not want) which is odd considering the NFS data<br>
&gt; domain was added as master when I setup oVirt.  Nothing will come back until<br>
&gt; I get the master domain online and unsure what to do now.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; - Trey<br>
&gt;<br>
&gt; On Tue, Oct 21, 2014 at 12:58 PM, Trey Dockendorf &lt;<a href="mailto:treydock@gmail.com" target="_blank">treydock@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I had a catastrophic failure of the IB switch that was used by all my<br>
&gt;&gt; storage domains.  I had one data domain that was NFS and one that was iSCSI.<br>
&gt;&gt; I managed to get the iSCSI LUN detached using the docs [1] but now I noticed<br>
&gt;&gt; that somehow my master domain went from the NFS domain to the iSCSI domain<br>
&gt;&gt; and I&#39;m unable to switch them back.<br>
&gt;&gt;<br>
&gt;&gt; How does one change the master?  Right now I am having issues getting<br>
&gt;&gt; iSCSI over TCP to work, so am sort of stuck with 30 VMs down and an entire<br>
&gt;&gt; cluster inaccessible.<br>
&gt;&gt;<br>
&gt;&gt; Thanks,<br>
&gt;&gt; - Trey<br>
&gt;&gt;<br>
&gt;&gt; [1] <a href="http://www.ovirt.org/Features/Manage_Storage_Connections" target="_blank">http://www.ovirt.org/Features/Manage_Storage_Connections</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; Users mailing list<br>
&gt; <a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
&gt; <a href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br>
&gt;<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div>