Description of problem: After re-installing to rhevh 20140930.1.el6ev , the host is pingable . After setting IP for the ovirt-engine in Ovirt Engine menu , After accepting the SSH the vdsm looks to restart and then it changes the network settings details in the console . Note: The host is pingable but in Network menu , the NIC no longer shows that it is configured . In Ovirt Engine menu it says "Networking is not configured, please configure it before registering". This has blocked upgrade plan to latest hypervisor . Version-Release number of selected component (if applicable): rhevh 20140930.1.el6ev 4 NIC , rhevm bridge on 4th nic . How reproducible: Always on customer end . Not on new env . Steps to Reproduce: 1. 2. 3. Actual results: After setting the ovirt engine IP , the vdsm restarts & the NICs shows "networking not configured" , although network works. Expected results: After setting the ovirt engine IP , the vdsm restarts & the NICs should still show 'managed' . Additional info: This is very similar to https://bugzilla.redhat.com/show_bug.cgi?id=1058257
Jaison, could you please check if this also appears to you as duplicate of bug 1102632 ? If so, then this is the "intended" behavior, when RHEV-H was registered, but was not yet approved.
Also, please try to log out of the TUI and login again.
(In reply to Fabian Deutsch from comment #1) > Jaison, could you please check if this also appears to you as duplicate of > bug 1102632 ? > > If so, then this is the "intended" behavior, when RHEV-H was registered, but > was not yet approved. Hi Fabian, I think so . Once customer upgrades the host : "When I use the ovirt-engine menu item it lets me put in the IP for the ovirt-engine, then it sets the SSH key. After accepting the SSH the vdsm looks to restart and then it wipes out the network settings." After this point , the host does not show up on rhev manager & host UI shows "Networking is not configured, please configure it before registering" . But the issue seems like the host does not come up in the engine portal . I will request customer for fresh logs with engine logs too . Regards, Jaison R
Jaison, one thing the customer can try: On RHEV-H: 1. Enter oVirt Engine / RHEV-M menu 2. Set a password 3. <Save> On RHEV-M: 1. Select the Hosts tab 2. Add a new host 2.a Enter a name, and ip address of the RHEV-H host 2.b Enter the password (the same as on the rhevh side) 2.b Show the advanced options and fetch the ssh-key 3. Add the host Does this work for the customer?
I'll see if I can reproduce this. In the meantime, can you get the customer to post the contents of /etc/default/ovirt ? We determine whether or not the network is configured in the UI by looking for interfaces which are configured but not bridged, or by looking at a key in /etc/default/ovirt. It seems like this key may not be getting set. Also, in both sosreports, it looks like something is wrong with vdsm-reg, which is likely the root problem. Douglas, any ideas? SSLError: [Errno 1] _ssl.c:492: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed MainThread::ERROR::2014-11-20 20:31:35,421::deployUtil::1598::root::Failed to fetch /engine.ssh.key.txt status 400 MainThread::DEBUG::2014-11-20 20:31:35,421::deployUtil::1610::root::getRemoteFile end. MainThread::DEBUG::2014-11-20 20:31:35,422::deployUtil::1552::root::getRemoteFile start. IP = 192.169.0.3 port = 443 fileName = "/rhevm.ssh.key.txt" MainThread::DEBUG::2014-11-20 20:31:35,430::deployUtil::1572::root::/rhevm.ssh.key.txt failed in HTTPS. Retrying using HTTP. Traceback (most recent call last): File "/usr/share/vdsm-reg/deployUtil.py", line 1567, in getRemoteFile File "/usr/share/vdsm-reg/deployUtil.py", line 1387, in getSSLSocket File "/usr/lib64/python2.6/ssl.py", line 342, in wrap_socket File "/usr/lib64/python2.6/ssl.py", line 120, in __init__ File "/usr/lib64/python2.6/ssl.py", line 279, in do_handshake
Douglas - Any ideas?
(In reply to Ryan Barry from comment #5) > I'll see if I can reproduce this. > > In the meantime, can you get the customer to post the contents of > /etc/default/ovirt ? We determine whether or not the network is configured > in the UI by looking for interfaces which are configured but not bridged, or > by looking at a key in /etc/default/ovirt. It seems like this key may not be > getting set. > > Also, in both sosreports, it looks like something is wrong with vdsm-reg, > which is likely the root problem. Douglas, any ideas? > > SSLError: [Errno 1] _ssl.c:492: error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > MainThread::ERROR::2014-11-20 20:31:35,421::deployUtil::1598::root::Failed > to fetch /engine.ssh.key.txt status 400 > MainThread::DEBUG::2014-11-20 > 20:31:35,421::deployUtil::1610::root::getRemoteFile end. > MainThread::DEBUG::2014-11-20 > 20:31:35,422::deployUtil::1552::root::getRemoteFile start. IP = 192.169.0.3 > port = 443 fileName = "/rhevm.ssh.key.txt" > MainThread::DEBUG::2014-11-20 > 20:31:35,430::deployUtil::1572::root::/rhevm.ssh.key.txt failed in HTTPS. > Retrying using HTTP. > Traceback (most recent call last): > File "/usr/share/vdsm-reg/deployUtil.py", line 1567, in getRemoteFile > File "/usr/share/vdsm-reg/deployUtil.py", line 1387, in getSSLSocket > File "/usr/lib64/python2.6/ssl.py", line 342, in wrap_socket > File "/usr/lib64/python2.6/ssl.py", line 120, in __init__ > File "/usr/lib64/python2.6/ssl.py", line 279, in do_handshake Hi Ryan, This trace shows that we couldn't make a registration via https and will fall into http mode. Would be nice to see the logs from sosreport and /etc/default/ovirt to have a precise point where's failing.
After talking to Douglas, this looks like it may be a duplicate of bz#1088875 This is slated to be fixed in 3.5, but the current workaround is to navigate to the "oVirt Engine/RHEV-M" page in the RHEV-H TUI again, which will set the appropriate key (if I'm reading bz#1088875 correctly).
(In reply to Ryan Barry from comment #8) > After talking to Douglas, this looks like it may be a duplicate of bz#1088875 > > This is slated to be fixed in 3.5, but the current workaround is to navigate > to the "oVirt Engine/RHEV-M" page in the RHEV-H TUI again, which will set > the appropriate key (if I'm reading bz#1088875 correctly). (In reply to Douglas Schilling Landgraf from comment #7) > (In reply to Ryan Barry from comment #5) > > I'll see if I can reproduce this. > > > > In the meantime, can you get the customer to post the contents of > > /etc/default/ovirt ? We determine whether or not the network is configured > > in the UI by looking for interfaces which are configured but not bridged, or > > by looking at a key in /etc/default/ovirt. It seems like this key may not be > > getting set. > > > > Also, in both sosreports, it looks like something is wrong with vdsm-reg, > > which is likely the root problem. Douglas, any ideas? > > > > SSLError: [Errno 1] _ssl.c:492: error:14090086:SSL > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > > MainThread::ERROR::2014-11-20 20:31:35,421::deployUtil::1598::root::Failed > > to fetch /engine.ssh.key.txt status 400 > > MainThread::DEBUG::2014-11-20 > > 20:31:35,421::deployUtil::1610::root::getRemoteFile end. > > MainThread::DEBUG::2014-11-20 > > 20:31:35,422::deployUtil::1552::root::getRemoteFile start. IP = 192.169.0.3 > > port = 443 fileName = "/rhevm.ssh.key.txt" > > MainThread::DEBUG::2014-11-20 > > 20:31:35,430::deployUtil::1572::root::/rhevm.ssh.key.txt failed in HTTPS. > > Retrying using HTTP. > > Traceback (most recent call last): > > File "/usr/share/vdsm-reg/deployUtil.py", line 1567, in getRemoteFile > > File "/usr/share/vdsm-reg/deployUtil.py", line 1387, in getSSLSocket > > File "/usr/lib64/python2.6/ssl.py", line 342, in wrap_socket > > File "/usr/lib64/python2.6/ssl.py", line 120, in __init__ > > File "/usr/lib64/python2.6/ssl.py", line 279, in do_handshake > > Hi Ryan, > > This trace shows that we couldn't make a registration via https and will > fall into http mode. Would be nice to see the logs from sosreport and > /etc/default/ovirt to have a precise point where's failing. I have attached the same . Do let us know if there seem anything thing suspicious causing this issue. I have requested customer to confirm #8 workaround works . Regards, Jaison R
Hello Team , Customer's issue is resolved . Usually when adding host to rhevm messes up network when : We put the password & the IP address of the ovirt-engine in Hypervisor UI & exit . This would bring hypervisor to the state described in the BZ . But as per customer : After we put the password & the IP address of the ovirt-engine, before exiting, add the new host from webadmin portal . After this customer sets up network on the host added in portal . Again from Hypervisor TUI , sets the ovirt-engine IP & this time the network does not change like earlier (but the NICs were configured ) . We had requested customer to add host from webadmin portal too earlier. Not sure how it is much different from above steps . Regards, Jaison R
Jaison - It's likely that this works because setting the engine IP again requires navigating to the engine page, which sets the right key. Since the customer's issue is resolved, do you have a problem with me closing this as a duplicate?
*** This bug has been marked as a duplicate of bug 1088875 ***