Hide Forgot
Created attachment 796344 [details] Scrrenshots and engine log Description of problem: Upgrade rhevh from rhev-hypervisor6-6.4-20130815.0.el6_4 to rhev-hypervisor6-6.5-20130910.2.el6ev was success but modify network and as result, host in non-responsive state after restart and without ssh. Also when enter to TUI(pc physical available) under Network tab under 'Available System Nics' you can see 4 bonds with macs 00:00:00:00:00:00(see screenshot for more details) Version-Release number of selected component (if applicable): host - from rhev-hypervisor6-6.4-20130815.0.el6_4 to rhev-hypervisor6-6.5-20130910.2.el6ev rhevm - is13 How reproducible: Always Steps to Reproduce: 1. Have host with rhev-hypervisor6-6.4-20130815.0.el6_4 2. Install on rhevm rhev-hypervisor6-6.5-20130910.2.el6ev 3. Put host to maintenance and upgrade Actual results: Host to installation of new iso and after this reboot, after reboot host in non responsive state Expected results: Host state UP Additional info: Same thing happening, after that network repaired(change mode of one nic to dhcp) and adding host I see again 4 bonds with macs 00:00:00:00:00:00, but network continue work
Has any NIC/bond got a valid IP configuration?
All NIC's and bonds have unconfigured status via TUI, but ssh work fine, also under root, ifconfig show that I have rhevm nic with correct IP.
I'd suggest that we disable the network page when RHEV-H is managed. We'll still need to fix the status screen to display assigned IPs. Mike, does this align with the expected and previous behavior?
Yes, we lock networking when we're registered in previous versions and we should continue that going forward. Sounds like we have a bug with upgrade...
(In reply to Artyom from comment #0) > Created attachment 796344 [details] > Scrrenshots and engine log > > Description of problem: > Upgrade rhevh from rhev-hypervisor6-6.4-20130815.0.el6_4 to > rhev-hypervisor6-6.5-20130910.2.el6ev was success Just to confirm: The update went well and the host was responsive after the update? > but modify network and as > result, host in non-responsive state after restart and without ssh. What exactely did you configure? > Also > when enter to TUI(pc physical available) under Network tab under 'Available > System Nics' you can see 4 bonds with macs 00:00:00:00:00:00(see screenshot > for more details) That's a different issue tracked in bug 989419. > Steps to Reproduce: > 1. Have host with rhev-hypervisor6-6.4-20130815.0.el6_4 > 2. Install on rhevm rhev-hypervisor6-6.5-20130910.2.el6ev > 3. Put host to maintenance and upgrade Don't you also need the next step you described above: 4. Reconfigure networking ?
I upgraded rhevh and upgrade process was success, but upgrade process, not I, dropped network setting and it put host to non responsive state(no ip), so after upgrade I was need physical access to host(via power management also option) to reconfigure network via TUI. After reconfiguration host in up state with new version of rhevh(because this I said that upgrade was success)
(In reply to Artyom from comment #7) > I upgraded rhevh and upgrade process was success, but upgrade process, not > I, dropped network setting and it put host to non responsive state(no ip), > so after upgrade I was need physical access to host(via power management > also option) to reconfigure network via TUI. After reconfiguration host in > up state with new version of rhevh(because this I said that upgrade was > success) Right. Can you provide all vdsm, rhevh and rhevm related log files? For node they are /var/log/ovirt.log and /var/log/ovirt-node.log.
ok, I did again upgrade from rhev-hypervisor6-6.4-20130815.0.el6_4 to rhev-hypervisor6-6.5-20131011.0.el6 and upgrade was success, after restart host respond and in up state, ssh on host also worked fine, so I think problem was with build rhev-hypervisor6-6.5-20130910.2.el6ev. So I think it possible to close bug If I will receive the same problem in future will reopen bug or open new.
Will close the bug given the reasons in comment 9.