Hide Forgot
Description of problem: Documentation should be updated forth to "hosted_storage trying to import the storage domain with incorrect host id". You may see in https://bugzilla.redhat.com/show_bug.cgi?id=1408602#c10 and in https://bugzilla.redhat.com/show_bug.cgi?id=1322849#c18, the problematic issue being worked around with solution described in those comments, but it is missing in documentation in https://access.redhat.com/solutions/2351141. Please add this WA to documentation. Version-Release number of selected component (if applicable): 3.5 environment, which consisted of two hosts: alma03 - 3.5's RHEL6.7: ovirt-host-deploy-1.3.2-1.el6ev.noarch qemu-kvm-rhev-0.12.1.2-2.479.el6_7.5.x86_64 vdsm-4.16.38-1.el6ev.x86_64 sanlock-2.8-2.el6_5.x86_64 mom-0.4.1-4.el6ev.noarch ovirt-hosted-engine-ha-1.2.10-1.el6ev.noarch libvirt-client-0.10.2-54.el6_7.6.x86_64 ovirt-hosted-engine-setup-1.2.6.1-1.el6ev.noarch Linux version 2.6.32-431.76.1.el6.x86_64 (mockbuild@x86-032.build.eng.bos.redhat.com) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) ) #1 SMP Tue Nov 1 14:24:00 EDT 2016 Linux 2.6.32-431.76.1.el6.x86_64 #1 SMP Tue Nov 1 14:24:00 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux Server release 6.7 (Santiago) alma04 - 3.5's RHEVH7.2 hypervisor for RHEV 3.5 (RHEV Hypervisor - 7.2 - 20160219.0.el7ev): qemu-kvm-rhev-2.3.0-31.el7_2.7.x86_64 vdsm-4.16.35-2.el7ev.x86_64 ovirt-node-plugin-hosted-engine-0.2.0-18.0.el7ev.noarch ovirt-node-branding-rhev-3.2.3-31.el7.noarch rhevm-sdk-python-3.5.6.0-1.el7ev.noarch mom-0.4.1-4.el7ev.noarch ovirt-node-selinux-3.2.3-31.el7.noarch ovirt-host-deploy-offline-1.3.0-3.el7ev.x86_64 ovirt-hosted-engine-setup-1.2.6.1-1.el7ev.noarch ovirt-node-plugin-vdsm-0.2.0-26.el7ev.noarch ovirt-node-plugin-cim-3.2.3-31.el7.noarch ovirt-node-plugin-snmp-3.2.3-31.el7.noarch sanlock-3.2.4-1.el7.x86_64 libvirt-client-1.2.17-13.el7_2.3.x86_64 ovirt-node-plugin-rhn-3.2.3-31.el7.noarch ovirt-node-3.2.3-31.el7.noarch ovirt-hosted-engine-ha-1.2.10-1.el7ev.noarch ovirt-host-deploy-1.3.2-1.el7ev.noarch Linux version 3.10.0-327.10.1.el7.x86_64 (mockbuild@x86-021.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC) ) #1 SMP Sat Jan 23 04:54:55 EST 2016 Linux 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23 04:54:55 EST 2016 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Virtualization Hypervisor release 7.2 (20160219.0.el7ev) How reproducible: 100% Steps to Reproduce: 1.Upgrade HE environment from 3.5 to 3.6.10. 2. 3. Actual results: Documentation is missing work around from https://bugzilla.redhat.com/show_bug.cgi?id=1322849#c18. Expected results: Add WA to documentation. Additional info:
Can you update the KBase on this?
Can you please reply to this bug?
Marina has offloaded this to me. I prefer we do the host_id/spm_vds_id alignment in a different KCS and link it to the Upgrade KCS. Because we have some other solutions which could also make use of it, for example [1]. I think this technical problem can cause other issues, so all those can point to the same steps to fix the ids. And this would be a big too big and complex to add to that already "heavy" solution. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1417518 I should have a draft ready by Monday 27th.
How does this look like? Any suggestions? https://access.redhat.com/solutions/2981731 If it's good enough we can link other solutions to it too, not just the object of this BZ.
(In reply to Germano Veit Michel from comment #4) > How does this look like? Any suggestions? > > https://access.redhat.com/solutions/2981731 > > If it's good enough we can link other solutions to it too, not just the > object of this BZ. Germano, The KCS[2] looks great. However - it is very technical and without much background for the customer, I would say. We should make the issue more clear when to use + add a statement, recommending to contact RH before executing. Next, I understand, your new KCS[2] is trying to solve the problem of the HE host always having host id 1, when restoring HE environment, which conflicts with other hosts, right? But then I am not sure where exactly in KCS[1] we should put those instructions. Which host should have host id 1 in this process? Lastly, do I understand correctly, that current documentation(after 3.6) workarounds this problem by asking to put HE host id 1 in maintenance prior to taking a backup??? (not sure I like it, or at least we should add some explanation there why it is important.) [1] https://access.redhat.com/solutions/2351141 [2] https://access.redhat.com/solutions/2981731
Reading this: https://bugzilla.redhat.com/show_bug.cgi?id=1322849#c28 I think I understand better - this request addresses the addition of new hosts to the existing HE environment. Still not clear to me when should we apply the KCS[2] above.
Also, changing the title to something that makes more sense to me. I hope I understand the problem correctly.
(In reply to Marina from comment #6) > Reading this: > https://bugzilla.redhat.com/show_bug.cgi?id=1322849#c28 > > I think I understand better - this request addresses the addition of new > hosts to the existing HE environment. > Still not clear to me when should we apply the KCS[2] above. Hi Marina, I also linked KCS[2] in Step 11 of KCS[1]. I'll also link KCS[2] to another KCS of mine and we may link it to others in the future. I think KCS[2] can be applied to several distinct problems, that's why I made it highly technical and not tied to a single problem. But yes we can make KCS[2] more user friendly, I'll work on it. Maybe KCS[2] should actually be an Article and not a Solution. Also, should we hide those SQL statements? It's read-only but if we hide them the customer will really need to open a support case even if they know how to do it. What do you think? And title change looks appropriate to me.
Marina, both KCS look good to me. Clearing the NEEDINFO.
Content published in downstream guide. To be reviewed for docs style separately.