<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><br></div><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>ebay-cors-filter-1.0.1-0.1.ovirt.el6.noarch<br></div><div>ovirt-engine-3.6.7.5-1.el6.noarch</div><div>ovirt-engine-backend-3.6.7.5-1.el6.noarch</div><div>ovirt-engine-cli-3.6.2.0-1.el6.noarch</div><div>ovirt-engine-dbscripts-3.6.7.5-1.el6.noarch</div><div>ovirt-engine-extension-aaa-jdbc-1.0.7-1.el6.noarch</div><div>ovirt-engine-extensions-api-impl-3.6.7.5-1.el6.noarch</div><div>ovirt-engine-jboss-as-7.1.1-1.el6.x86_64</div><div>ovirt-engine-lib-3.6.7.5-1.el6.noarch</div><div>ovirt-engine-restapi-3.6.7.5-1.el6.noarch</div><div>ovirt-engine-sdk-python-3.6.7.0-1.el6.noarch</div><div>ovirt-engine-setup-3.6.7.5-1.el6.noarch</div><div>ovirt-engine-setup-base-3.6.7.5-1.el6.noarch</div><div>ovirt-engine-setup-plugin-ovirt-engine-3.6.7.5-1.el6.noarch</div><div>ovirt-engine-setup-plugin-ovirt-engine-common-3.6.7.5-1.el6.noarch</div><div>ovirt-engine-setup-plugin-vmconsole-proxy-helper-3.6.7.5-1.el6.noarch</div><div>ovirt-engine-setup-plugin-websocket-proxy-3.6.7.5-1.el6.noarch</div><div>ovirt-engine-tools-3.6.7.5-1.el6.noarch</div><div>ovirt-engine-tools-backup-3.6.7.5-1.el6.noarch</div><div>ovirt-engine-userportal-3.6.7.5-1.el6.noarch</div><div>ovirt-engine-vmconsole-proxy-helper-3.6.7.5-1.el6.noarch</div><div>ovirt-engine-webadmin-portal-3.6.7.5-1.el6.noarch</div><div>ovirt-engine-websocket-proxy-3.6.7.5-1.el6.noarch</div><div>ovirt-engine-wildfly-8.2.1-1.el6.x86_64</div><div>ovirt-engine-wildfly-overlay-8.0.5-1.el6.noarch</div><div>ovirt-host-deploy-1.4.1-1.el6.noarch</div><div>ovirt-host-deploy-java-1.4.1-1.el6.noarch</div><div>ovirt-image-uploader-3.6.0-1.el6.noarch</div><div>ovirt-iso-uploader-3.6.0-1.el6.noarch</div><div>ovirt-release34-1.0.3-1.noarch</div><div>ovirt-release35-006-1.noarch</div><div>ovirt-release36-3.6.7-1.noarch</div><div>ovirt-setup-lib-1.0.1-1.el6.noarch</div><div>ovirt-vmconsole-1.0.2-1.el6.noarch</div><div>ovirt-vmconsole-proxy-1.0.2-1.el6.noarch</div></div><div><br></div><div>node01 (CentOS 6.9)</div><div><div>vdsm-4.16.30-0.el6.x86_64</div><div>vdsm-cli-4.16.30-0.el6.noarch</div><div>vdsm-jsonrpc-4.16.30-0.el6.noarch</div><div>vdsm-python-4.16.30-0.el6.noarch</div><div>vdsm-python-zombiereaper-4.16.30-0.el6.noarch</div><div>vdsm-xmlrpc-4.16.30-0.el6.noarch</div><div>vdsm-yajsonrpc-4.16.30-0.el6.noarch</div></div><div>gpxe-roms-qemu-0.9.7-6.16.el6.noarch<br></div><div><div>qemu-img-rhev-0.12.1.2-2.479.el6_7.2.x86_64</div><div>qemu-kvm-rhev-0.12.1.2-2.479.el6_7.2.x86_64</div><div>qemu-kvm-rhev-tools-0.12.1.2-2.479.el6_7.2.x86_64</div><div>libvirt-0.10.2-62.el6.x86_64<br></div><div>libvirt-client-0.10.2-62.el6.x86_64</div><div>libvirt-lock-sanlock-0.10.2-62.el6.x86_64</div><div>libvirt-python-0.10.2-62.el6.x86_64</div><div>node01 was upgraded out of desperation after I tried changing my DC and cluster version to 3.6, but then found that none of my hosts could be activated out of maintenance due to an incompatibility with 3.6 (I&#39;m still not sure why as searching seemed to indicate Centos 6.x was compatible. I then had to remove all 4 hosts, and change the cluster version back to 3.5 and then re-add them. When I tried changing the cluster version to 3.6 I did get a complaint about using the &quot;legacy protocol&quot; so on each host under Advanced, I changed them to use the JSON protocol, and this seemed to resolve it, however once changing the DC/Cluster back to 3.5 the option to change the protocol back to Legacy is no longer shown.<br></div></div><div><br></div><div><div>node02 (Centos 6.7)</div><div><div>vdsm-4.16.30-0.el6.x86_64</div><div>vdsm-cli-4.16.30-0.el6.noarch</div><div>vdsm-jsonrpc-4.16.30-0.el6.noarch</div><div>vdsm-python-4.16.30-0.el6.noarch</div><div>vdsm-python-zombiereaper-4.16.30-0.el6.noarch</div><div>vdsm-xmlrpc-4.16.30-0.el6.noarch</div><div>vdsm-yajsonrpc-4.16.30-0.el6.noarch</div></div></div><div><div>gpxe-roms-qemu-0.9.7-6.14.el6.noarch</div><div>qemu-img-rhev-0.12.1.2-2.479.el6_7.2.x86_64</div><div>qemu-kvm-rhev-0.12.1.2-2.479.el6_7.2.x86_64</div><div>qemu-kvm-rhev-tools-0.12.1.2-2.479.el6_7.2.x86_64</div><div>libvirt-0.10.2-54.el6_7.6.x86_64<br></div><div>libvirt-client-0.10.2-54.el6_7.6.x86_64</div><div>libvirt-lock-sanlock-0.10.2-54.el6_7.6.x86_64</div><div>libvirt-python-0.10.2-54.el6_7.6.x86_64</div></div><div><br></div><div>node03 CentOS 6.7</div><div><div><div>vdsm-4.16.30-0.el6.x86_64</div><div>vdsm-cli-4.16.30-0.el6.noarch</div><div>vdsm-jsonrpc-4.16.30-0.el6.noarch</div><div>vdsm-python-4.16.30-0.el6.noarch</div><div>vdsm-python-zombiereaper-4.16.30-0.el6.noarch</div><div>vdsm-xmlrpc-4.16.30-0.el6.noarch</div><div>vdsm-yajsonrpc-4.16.30-0.el6.noarch</div></div><div><div>gpxe-roms-qemu-0.9.7-6.14.el6.noarch</div><div>qemu-img-rhev-0.12.1.2-2.479.el6_7.2.x86_64</div><div>qemu-kvm-rhev-0.12.1.2-2.479.el6_7.2.x86_64</div><div>qemu-kvm-rhev-tools-0.12.1.2-2.479.el6_7.2.x86_64</div></div><div><div>libvirt-0.10.2-54.el6_7.6.x86_64</div><div>libvirt-client-0.10.2-54.el6_7.6.x86_64</div><div>libvirt-lock-sanlock-0.10.2-54.el6_7.6.x86_64</div><div>libvirt-python-0.10.2-54.el6_7.6.x86_64</div></div><div><br></div></div><div>node04 (Centos 6.7)</div><div><div>vdsm-4.16.20-1.git3a90f62.el6.x86_64</div><div>vdsm-cli-4.16.20-1.git3a90f62.el6.noarch</div><div>vdsm-jsonrpc-4.16.20-1.git3a90f62.el6.noarch</div><div>vdsm-python-4.16.20-1.git3a90f62.el6.noarch</div><div>vdsm-python-zombiereaper-4.16.20-1.git3a90f62.el6.noarch</div><div>vdsm-xmlrpc-4.16.20-1.git3a90f62.el6.noarch</div><div>vdsm-yajsonrpc-4.16.20-1.git3a90f62.el6.noarch</div></div><div><div>gpxe-roms-qemu-0.9.7-6.15.el6.noarch</div><div>qemu-img-0.12.1.2-2.491.el6_8.1.x86_64</div><div>qemu-kvm-0.12.1.2-2.491.el6_8.1.x86_64</div><div>qemu-kvm-tools-0.12.1.2-2.503.el6_9.3.x86_64</div></div><div><div>libvirt-0.10.2-60.el6.x86_64</div><div>libvirt-client-0.10.2-60.el6.x86_64</div><div>libvirt-lock-sanlock-0.10.2-60.el6.x86_64</div><div>libvirt-python-0.10.2-60.el6.x86_64</div></div><div><br></div><div>I&#39;m seeing a rather confusing error in the /var/log/messages on all 4 hosts as follows....</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><br></div><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. 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>