Created attachment 1389956 [details] incorrect_cpu.png Description of problem: When second time to deploy HE(redeploy) via cockpit, sometimes, the generating answer file include the incorrect cpu type, then redeploy failed. Version-Release number of selected component (if applicable): cockpit-ws-157-1.el7.x86_64 cockpit-bridge-157-1.el7.x86_64 cockpit-storaged-157-1.el7.noarch cockpit-dashboard-157-1.el7.x86_64 cockpit-157-1.el7.x86_64 cockpit-ovirt-dashboard-0.11.9-0.1.el7ev.noarch cockpit-system-157-1.el7.noarch ovirt-hosted-engine-setup-2.2.9-1.el7ev.noarch ovirt-hosted-engine-ha-2.2.4-1.el7ev.noarch rhvh-4.2.1.2-0.20180201.0+1 rhvm-appliance-4.2-20180125.0.el7.noarch How reproducible: 30% with re-deployment Steps to Reproduce: 1. Clean install latest RHVH4.2.1 with ks(rhvh-4.2.1.2-0.20180201.0+1) 2. Deploy HE via cockpit failed due some reasons 3. Clean the ENV and redeploy 4. Check the generating answer file Actual results: 1. After step4, from the answer file , include the incorrect cpu type: """ OVEHOSTED_VDSM/cpu=str:model_ """ And finally, deplay failed. Expected results: Redeploy HE successfully Additional info:
same as bug 1541328?
Can you provide any other information, Yihui? Is this actually a system with AMD CPUs? I suspect the logic used to check the CPUs is bad somehow if vdsm/libvirt are down, similar to https://bugzilla.redhat.com/show_bug.cgi?id=1528818
(In reply to Ryan Barry from comment #2) > Can you provide any other information, Yihui? > > Is this actually a system with AMD CPUs? Yes, the host is a system with AMD CPUs. I suspect the logic used to check > the CPUs is bad somehow if vdsm/libvirt are down, similar to > https://bugzilla.redhat.com/show_bug.cgi?id=1528818 I aggree. Because when clean the previous ENV, I will stop the libvirtd service. Also, first deployment is always ok.
Tested cockpit-ovirt-0.11.14-0.1 on RHEL7.4 without this issue. Test version: Red Hat Enterprise Linux Server 7.4 Beta (Maipo) ovirt-hosted-engine-ha-2.2.6-1.el7ev.noarch cockpit-ovirt-dashboard-0.11.14-0.1.el7ev.noarch ovirt-hosted-engine-setup-2.2.11-1.el7ev.noarch cockpit-storaged-158-1.el7.noarch cockpit-bridge-157-1.el7.x86_64 cockpit-157-1.el7.x86_64 cockpit-dashboard-158-1.el7.x86_64 cockpit-ws-157-1.el7.x86_64 cockpit-system-157-1.el7.noarch rhvm-appliance-4.2-20180202.0.el7.noarch So, I will change the bug's status to verified.
This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.2 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.