[ovirt-users] info about ovirtmgmt bridge config in master

[Piotr Kliczewski]

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Gianluca Cecchi" <gianluca.cecchi at gmail.com>, pkliczew at redhat.com, asegurap at redhat.com
> Cc: "users" <users at ovirt.org>
> Sent: Wednesday, August 27, 2014 1:28:41 PM
> Subject: Re: [ovirt-users] info about ovirtmgmt bridge config in master
> 
> On Fri, Aug 15, 2014 at 01:01:50PM +0200, Gianluca Cecchi wrote:
> > On Fri, Aug 15, 2014 at 12:30 PM, Dan Kenigsberg <danken at redhat.com> wrote:
> > 
> > >
> > >
> > > ifcfg-ovirtmgmt network should be found on disk after a successful
> > > installation of a host. However, if network configuration phase fails,
> > > ifcfg files should be reverted to their original values.
> > >
> > 
> > ok.
> > 
> > 
> > >
> > > Could you see your super/vdsm.log if that is the case?
> > > Could you explain when did "hypervisor part goes in timeout". Can you
> > > correlate this to something in vdsm.log?
> > >
> > > Dan.
> > >
> > 
> > So, initial config was no dns and I forgot the /etc/hosts part too.
> > So engine-setup complained about hostname input and asked again.
> > At this point I filled up /etc/hosts and confirmed hostname in engine-setup
> > prompt.
> > It complained about dns part but continued.
> > As this is an all-in-one setup it arrived at the hypervisor config part.
> > It gave in engine-setup output the message about time out in having
> > hypervisor host up a few times and at the end
> > 
> > [ INFO  ] Still waiting for VDSM host to become operational...
> > [ ERROR ] Timed out while waiting for host to start. Please check the logs.
> > 
> > During these recurring time-out warnings I see in vdsm.log
> > Detector thread::ERROR::2014-08-13
> > 17:48:59,482::protocoldetector::104::vds.MultiProtocolAcceptor::(serve_forever)
> > Unhandled exception
> > Traceback (most recent call last):
> >   File "/usr/share/vdsm/protocoldetector.py", line 100, in serve_forever
> >     self._process_events()
> >   File "/usr/share/vdsm/protocoldetector.py", line 117, in _process_events
> >     self._accept_connection()
> >   File "/usr/share/vdsm/protocoldetector.py", line 180, in
> > _accept_connection
> >     client_socket, _ = self._socket.accept()
> >   File "/usr/lib64/python2.6/site-packages/vdsm/sslutils.py", line 121, in
> > accept
> >     raise SSL.SSLError("%s, client %s" % (e, address[0]))
> > SSLError: unexpected eof, client 192.168.122.51
> 
> Gianluca, does this show repeatedly when `vdsClient -s 0 getVdsCaps` is
> called manually?
> 
> Piotr, can you guess what may cause this?
> 

Having information above it looks like ssl handshake failed or disconnect happened
during handshake. How easy it is to reproduce it?

>
> > 
> > engine-setup went ahead with these messages:
> > 
> > [WARNING] Local storage domain not added because the VDSM host was not up.
> > Please add it manually.
> > [ INFO  ] Stage: Clean up
> >           Log file is located at
> > /var/log/ovirt-engine/setup/ovirt-engine-setup-20140813173448-i47i1l.log
> > [ INFO  ] Generating answer file
> > '/var/lib/ovirt-engine/setup/answers/20140813174959-setup.conf'
> > [ INFO  ] Stage: Pre-termination
> > [ INFO  ] Stage: Termination
> > [ INFO  ] Execution of setup completed successfully
> > 
> > inside supervdsm.log no error message. See it here:
> > https://drive.google.com/file/d/0BwoPbcrMv8mvRVpxR3UzYU9hUmM/edit?usp=sharing
> 
> 
> I don't think it's anyway related to your problem, but it does require
> Toni comment - supervdsm.log has traces of needless calls
> 
> MainThread::DEBUG::2014-08-15
> 10:38:02,570::vdsm-restore-net-config::56::root::(unified_restoration)
> Removing all networks ({}) and bonds ({}) in running config.
> 
>   and
> 
> MainThread::DEBUG::2014-08-15
> 10:38:02,642::api::640::setupNetworks::(setupNetworks) Setting up network
> according to configuration: networks:{}, bondings:{},
> options:{'_inRollback': True, 'connectivityCheck': False}
> MainThread::DEBUG::2014-08-15 10:38:02,642::api::644::root::(setupNetworks)
> Validating configuration
> 
>