Bug 1152446
Summary: | "Networking is not configured" warning noticed after upgrade to rhevh 20140930.1.el6ev | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Jaison Raju <jraju> |
Component: | ovirt-node-plugin-vdsm | Assignee: | Ryan Barry <rbarry> |
Status: | CLOSED DUPLICATE | QA Contact: | Pavel Stehlik <pstehlik> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 3.4.0 | CC: | dougsland, ecohen, fdeutsch, iheim, jraju, lsurette, rbarry |
Target Milestone: | --- | ||
Target Release: | 3.6.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | node | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-01-06 14:54:46 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Node | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jaison Raju
2014-10-14 08:09:27 UTC
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 *** |