<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Jul 31, 2017 at 5:54 PM Neil &lt;<a href="mailto:nwilson123@gmail.com">nwilson123@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi guys,<br></div><div><br></div><div>Please could someone assist me, my DC seems to be trying to re-negotiate SPM and apparently it&#39;s failing. I tried to delete an old autogenerated snapshot and shortly after that the issue seemed to start, however after about an hour, the snapshot said successfully deleted, and then SPM negotiated again albeit for a short period before it started trying to re-negotiate again. </div></div></blockquote><div><br></div><div>This is a known issue in old versions, should be improved in 4.1.</div><div><br></div><div>Oved, do you know if there is something we can tune on engine side to avoid</div><div>too eager disconnections when vdsm hartbeat is delayed?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Last week I upgraded from ovirt 3.5 to 3.6, I also upgraded one of my 4 hosts using the 3.6 repo to the latest available from that repo and did a yum update too. </div><div><br></div><div>I have 4 nodes and my ovirt engine is a KVM guest on another physical machine on the network. I&#39;m using an FC SAN with ATTO HBA&#39;s and recently we&#39;ve started seeing some degraded IO. The SAN appears to be alright and the disks all seem to check out, but we are having rather slow IOPS at the moment, which we trying to track down.</div><div><br></div><div><div>ovirt engine CentOS release 6.9 (Final) </div></div></div></blockquote><div> ...</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div></div><div>ovirt-engine-3.6.7.5-1.el6.noarchvdsm-4.16.30-0.el6.x86_64</div></div></div></blockquote><div>... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>vdsm-cli-4.16.30-0.el6.noarch</div></div></div></blockquote><div><br></div><div><div>Using ovirt 3.6 at this time is not a good idea.  You want to use 4.1.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>I&#39;m seeing a rather confusing error in the /var/log/messages on all 4 hosts as follows....<br></div></div><div><br></div><div><div>Jul 31 16:41:36 node01 multipathd: 36001b4d80001c80d0000000000000000: sdb - directio checker reports path is down</div><div>Jul 31 16:41:41 node01 kernel: sd 7:0:0:0: [sdb]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK</div><div>Jul 31 16:41:41 node01 kernel: sd 7:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 00 00 00 00 01 00</div><div>Jul 31 16:41:41 node01 kernel: end_request: I/O error, dev sdb, sector 0</div></div><div><br></div><div>I say confusing, because I don&#39;t have a 3000GB LUN</div><div><br></div><div><div>[root@node01 ~]# fdisk -l | grep 3000</div><div>Disk /dev/sdb: 3000.0 GB, 2999999528960 bytes</div></div><div><br></div><div>I did have one on Friday, last week, but I trashed it and changed it to a 1500GB LUN instead, so I&#39;m not sure if perhaps this error is still trying to connect to the old LUN perhaps?</div></div></blockquote><div><br></div><div>Right. oVirt consume the devices you map to the host, we don&#39;t manage </div><div>adding or removing devices.</div><div><br></div><div>After you unmap a device on the storage, the host still see the old device</div><div>as faulty path; you have to remove it.</div><div><a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/removing_devices.html">https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/removing_devices.html</a><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>My LUNS are as follows...</div><div><br></div><div><div>Disk /dev/sdb: 3000.0 GB, 2999999528960 bytes (this one doesn&#39;t actually exist anymore)</div><div>Disk /dev/sdc: 1000.0 GB, 999999668224 bytes</div><div>Disk /dev/sdd: 1000.0 GB, 999999668224 bytes</div><div>Disk /dev/sde: 1000.0 GB, 999999668224 bytes</div><div>Disk /dev/sdf: 1000.0 GB, 999999668224 bytes</div><div>Disk /dev/sdg: 1000.0 GB, 999999668224 bytes</div><div>Disk /dev/sdh: 1000.0 GB, 999999668224 bytes</div><div>Disk /dev/sdi: 1000.0 GB, 999999668224 bytes</div><div>Disk /dev/sdj: 1000.0 GB, 999999668224 bytes</div><div>Disk /dev/sdk: 1000.0 GB, 999999668224 bytes</div><div>Disk /dev/sdm: 1000.0 GB, 999999668224 bytes</div><div>Disk /dev/sdl: 1000.0 GB, 999999668224 bytes</div><div>Disk /dev/sdn: 1000.0 GB, 999999668224 bytes</div><div>Disk /dev/sdo: 1000.0 GB, 999999668224 bytes</div><div>Disk /dev/sdp: 1000.0 GB, 999999668224 bytes</div><div>Disk /dev/sdq: 1000.0 GB, 999999668224 bytes</div><div>Disk /dev/sdr: 1000.0 GB, 999988133888 bytes</div><div>Disk /dev/sds: 1500.0 GB, 1499999764480 bytes</div><div>Disk /dev/sdt: 1500.0 GB, 1499999502336 bytes</div></div><div><br></div><div>I&#39;m quite low on SAN disk space currently so I&#39;m a little hesitant to migrate VM&#39;s around for fear of the migrations creating too many snapshots and filling up my SAN. </div></div></blockquote><div><br></div><div>Migrating disk of live vms creates one 1g snapshot per disk. after migration is done,</div><div>the old disk is deleted on the source storage domain. You need to remove the snapshot</div><div>manually in 3.6 (removed automatically in 4.1).</div><div><br></div><div>Migrating disk when vms are not running does not require additional space on the source</div><div>storage domain.</div><div><br></div><div>Nir</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>We are in the process of expanding the SAN Array too, but we trying to get to the bottom of the bad IOPS at the moment before adding on addition overhead.</div><div><br></div><div>Ping tests between hosts and engine all look alright, so I don&#39;t suspect network issues.</div><div><br></div><div>I know this is very vague, everything is currently operational, however as you can see in the attached logs, I&#39;m getting lots of ERROR messages.<br></div><div><br></div><div>Any help or guidance is greatly appreciated.</div><div><br></div><div>Thanks.</div><div><br></div><div>Regards.</div><div><br></div><div>Neil Wilson.</div><div><br></div><div><br></div></div>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br>
</blockquote></div></div>