This appeared when we ran our job for he deployment for second time before before we failed with unclean HE SD. Now running from scratch again with provisioning of all our hosts. Will update if I will hit the same issue for first time of running deployment.
Please refrain from pasting such long logs, only the relevant sections. Can you describe the steps to reproduce, if any?
As I told in previous comment it happened after second run of hosted-engine --deploy when in the first attempt we failed on uncleaned SD. When I ran our job from scratch where we cleaned HE storages before and provisioned all the machines I didn't didn't hit the issue again. So most probably it will happen when you are running this command for second time.
Did it work if you use the cleanup script?
Haven't tried if you mean ovirt-hosted-engine-cleanup. But in the first attempt hosted engine wasn't deployed cause of unclean SD. I cleaned up this SD manually and run everything from scratch with provisioning of machines and so.. and didn't hit this issue again.
(In reply to Petr Balogh from comment #5) > Haven't tried if you mean ovirt-hosted-engine-cleanup. But in the first > attempt hosted engine wasn't deployed cause of unclean SD. I cleaned up this > SD manually and run everything from scratch with provisioning of machines > and so.. and didn't hit this issue again. Following official documentation, SHE deployments should be made only on clean environment.
(In reply to Nikolai Sednev from comment #6) > > Following official documentation, SHE deployments should be made only on > clean environment. True, although Hosted-engine can be redeployed successfully after a failed deployment using the ovirt-hosted-engine-cleanup tool. (In reply to Petr Balogh from comment #5) > Haven't tried if you mean ovirt-hosted-engine-cleanup. But in the first > attempt hosted engine wasn't deployed cause of unclean SD. I cleaned up this > SD manually and run everything from scratch with provisioning of machines > and so.. and didn't hit this issue again. The ovirt-hosted-engine-cleanup tool is essential for redeploying the Hosted-engine after a failed deployment. This might be the reason why you got an error on the second attempt in spite of the clean SD.
(In reply to Ido Rosenzwig from comment #7) > (In reply to Nikolai Sednev from comment #6) > > > > Following official documentation, SHE deployments should be made only on > > clean environment. > > True, although Hosted-engine can be redeployed successfully after a failed > deployment using the ovirt-hosted-engine-cleanup tool. > And this is tested flow and worked fine on our latest tests. > > (In reply to Petr Balogh from comment #5) > > Haven't tried if you mean ovirt-hosted-engine-cleanup. But in the first > > attempt hosted engine wasn't deployed cause of unclean SD. I cleaned up this > > SD manually and run everything from scratch with provisioning of machines > > and so.. and didn't hit this issue again. > > The ovirt-hosted-engine-cleanup tool is essential for redeploying the > Hosted-engine after a failed deployment. This might be the reason why you > got an error on the second attempt in spite of the clean SD.
I know that there were introduced a few similar bugs with move to ansible 2.5, so I thought that this one is related too. From some reason vlan_tag is '8000\\\\n1' as I can see from error messages so I guess that someone should check this one in the code.. it can maybe cause another issues in different place later on? Once we will be able to reproduce it, I will try run clan script before.
Please provide your network configuration settings (output of 'ip a' command)
Works for me on these components: ovirt-hosted-engine-ha-2.2.13-1.el7ev.noarch ovirt-hosted-engine-setup-2.2.22-1.el7ev.noarch rhvm-appliance-4.2-20180601.0.el7.noarch Linux 3.10.0-862.3.2.el7.x86_64 #1 SMP Tue May 15 18:22:15 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux Server release 7.5 (Maipo) Moving to verified.
This bugzilla is included in oVirt 4.2.4 release, published on June 26th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.4 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.