Bug 991087 - network is lost after installing all in one on fedora 19
network is lost after installing all in one on fedora 19
Status: CLOSED DUPLICATE of bug 1001186
Product: oVirt
Classification: Community
Component: ovirt-engine-installer (Show other bugs)
3.3
Unspecified Unspecified
urgent Severity unspecified
: ---
: ---
Assigned To: Yedidyah Bar David
network
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-01 11:02 EDT by Ohad Basan
Modified: 2013-08-28 09:19 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-27 11:27:32 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ohad Basan 2013-08-01 11:02:50 EDT
Description of problem:
when the bridge is created the ifcfg file is created with BOOTPROTO=dhcp entry
so after the setup restarts the network, connection is lost
and there is no ip
Comment 1 Dan Kenigsberg 2013-08-04 16:36:56 EDT
I really hope the Ofer understands what this bug is all about, since I do not. To track this properly, please report the versions of the relevant packages (including vdsm), the content of the relevant ifcfg files before and after installation, and relevant logs.
Comment 2 Ohad Basan 2013-08-14 04:09:57 EDT
I tried reproducing that on a clean machine 
using ovirt-engine-3.3.0-0.2.master.20130813190148.git4d3992c.fc19.noarch
and now the bridge is not being created at all and the all in one plugin does not seem to be running

2013-08-14 11:05:42 DEBUG otopi.context context._executeMethod:132 method exception
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/otopi/context.py", line 122, in _executeMethod
    method['method']()
  File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/all-in-one/vdsm.py", line 236, in _closeup
    self.environment[osetupcons.AIOEnv.LOCAL_CLUSTER]
  File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py", line 1331, in get
    headers={}
  File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line 52, in get
    return self.request(method='GET', url=url, headers=headers)
  File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line 112, in request
    persistent_auth=self._persistent_auth)
  File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line 134, in __doRequest
    persistent_auth=persistent_auth
  File "/usr/lib/python2.7/site-packages/ovirtsdk/web/connection.py", line 133, in doRequest
    raise RequestError, response
RequestError: 
status: 503
reason: Service Unavailable


it's a clean f19 machine
Comment 4 Yedidyah Bar David 2013-08-27 10:01:47 EDT
Did not manage to reproduce.

Started from a clean f19 VM.
Before setup, I had:
[root@ovirte1 network-scripts]# cat ifcfg-eth0 
HWADDR=52:54:00:1C:7B:48
TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=eth0
UUID=d41795c2-637e-4f48-b348-122317a98883
ONBOOT=yes

After setup with allinone, I had:
[root@ovirte1 network-scripts]# cat ifcfg-eth0
# Generated by VDSM version 4.12.0-78.git8f7eebf.fc19
DEVICE=eth0
ONBOOT=yes
HWADDR=52:54:00:1c:7b:48
BRIDGE=ovirtmgmt
MTU=1500
NM_CONTROLLED=no
STP=no
[root@ovirte1 network-scripts]# cat ifcfg-ovirtmgmt
# Generated by VDSM version 4.12.0-78.git8f7eebf.fc19
DEVICE=ovirtmgmt
ONBOOT=yes
TYPE=Bridge
DELAY=0
BOOTPROTO=dhcp
DEFROUTE=yes
NM_CONTROLLED=no
STP=no

Naturally, network configuration changes might temporarily disconnect the network, but this didn't happen for me this time.
We still might want to add a recommendation to run under 'screen' just in case, as we do in hosted-engine: http://gerrit.ovirt.org/17258

Versions:
ovirt-engine-3.4.0-0.2.master.20130822162248.gite4782ef.fc19.noarch
vdsm-4.12.0-78.git8f7eebf.fc19.x86_64
Comment 5 Ohad Basan 2013-08-27 10:15:01 EDT
Did the all in one installation finished for you succeessfully with host in "up" state?
this is odd.
Comment 6 Yedidyah Bar David 2013-08-27 10:26:45 EDT
=======================================================================
[ INFO  ] Stage: Closing up

          --== SUMMARY ==--

[WARNING] Warning: Not enough memory is available on the host. Minimum requirement is 4096MB, and 16384MB is recommended.
          SSH fingerprint: 68:55:f3:1b:d8:77:27:7a:48:9e:b0:25:00:88:81:4d
          Internal CA SHA1 Fingerprint=80:D5:19:2E:DB:F7:4F:51:B2:0B:98:E7:96:75:C6:D2:53:1B:0A:90
          Web access is enabled at:
              http://ovirte1.home.local:80/ovirt-engine
              https://ovirte1.home.local:443/ovirt-engine
          Please use the user "admin" and password specified in order to login into oVirt Engine

          --== END OF SUMMARY ==--

[ INFO  ] Starting engine service
[ INFO  ] Restarting httpd
[ INFO  ] Waiting for VDSM host to become operational. This may take several minutes...
[ INFO  ] Still waiting for VDSM host to become operational...
[ INFO  ] The VDSM Host is now operational
[ INFO  ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20130827165149-setup.conf'
[ INFO  ] Stage: Clean up
          Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20130827163658.log
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
=======================================================================
You had in your log:
=======================================================================
2013-08-14 11:05:40 DEBUG otopi.plugins.ovirt_engine_setup.all-in-one.vdsm vdsm._closeup:184 Connecting to the Engine
2013-08-14 11:05:41 DEBUG otopi.plugins.ovirt_engine_setup.all-in-one.vdsm vdsm._closeup:202 Creating the local data center
2013-08-14 11:05:41 DEBUG otopi.plugins.ovirt_engine_setup.all-in-one.vdsm vdsm._closeup:212 Creating the local cluster into the local data center
2013-08-14 11:05:42 DEBUG otopi.plugins.ovirt_engine_setup.all-in-one.vdsm vdsm._closeup:227 Adding the local host to the local cluster
2013-08-14 11:05:42 DEBUG otopi.context context._executeMethod:132 method exception
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/otopi/context.py", line 122, in _executeMethod
    method['method']()
  File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/all-in-one/vdsm.py", line 236, in _closeup
    self.environment[osetupcons.AIOEnv.LOCAL_CLUSTER]
  File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py", line 1331, in get
    headers={}
  File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line 52, in get
    return self.request(method='GET', url=url, headers=headers)
  File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line 112, in request
    persistent_auth=self._persistent_auth)
  File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line 134, in __doRequest
    persistent_auth=persistent_auth
  File "/usr/lib/python2.7/site-packages/ovirtsdk/web/connection.py", line 133, in doRequest
    raise RequestError, response
RequestError: 
status: 503
reason: Service Unavailable
=======================================================================
meaning it did manage to connect to the engine and do some stuff, but failed
during 'Adding the local host to the local cluster'. This can be a failure of the engine, host-deploy or vdsm. If you still have this machine, please attach all of the relevant logs including host-deploy/vdsm/engine.log. If you don't, please try to reproduce using current versions.

Also, perhaps it was fixed by: http://gerrit.ovirt.org/18262
Comment 7 Yedidyah Bar David 2013-08-27 10:31:26 EDT
No, it's not related to http://gerrit.ovirt.org/18262 .

Your log shows that you first had:

2013-08-14 11:05:37 INFO otopi.plugins.ovirt_engine_setup.core.misc misc._closeup:85 Starting engine service

and then:

2013-08-14 11:05:37 INFO otopi.plugins.ovirt_engine_common.system.apache apache._closeup:76 Restarting httpd

and only later 503.
Comment 8 Yedidyah Bar David 2013-08-27 10:59:55 EDT
Verified again, just to make sure.

ran cleanup, removed some packages, restored ifcfg-* from backup, rebooted.
Had:
========================================================================
[root@ovirte1 ~]# nm-tool 

NetworkManager Tool

State: connected (global)

- Device: eth0  [eth0] ---------------------------------------------------------
  Type:              Wired
  Driver:            virtio_net
  State:             connected
  Default:           yes
  HW Address:        52:54:00:1C:7B:48

  Capabilities:
    Carrier Detect:  yes

  Wired Properties
    Carrier:         on

  IPv4 Settings:
    Address:         192.168.122.12
    Prefix:          24 (255.255.255.0)
    Gateway:         192.168.122.1

    DNS:             192.168.122.1
========================================================================
Then installed again packages, ran engine-setup which finished successfully, then had:
========================================================================
[root@ovirte1 ~]# nm-tool

NetworkManager Tool

State: disconnected

- Device: bond0 ----------------------------------------------------------------
  Driver:            bonding
  State:             disconnected
  Default:           no

  Capabilities:
    Carrier Detect:  yes


- Device: eth0 -----------------------------------------------------------------
  Type:              Wired
  Driver:            virtio_net
  State:             unmanaged
  Default:           no
  HW Address:        52:54:00:1C:7B:48

  Capabilities:
    Carrier Detect:  yes

  Wired Properties
    Carrier:         on

========================================================================
So eth0 did change from "connected" to "unmanaged" by NM.
Comment 9 Ofer Schreiber 2013-08-27 11:27:32 EDT
Ohad, seems like this issue has been resolved already.
Please re-open if it happens again.
Comment 10 Yedidyah Bar David 2013-08-28 09:19:14 EDT

*** This bug has been marked as a duplicate of bug 1001186 ***

Note You need to log in before you can comment on or make changes to this bug.