On Mon, Oct 27, 2014 at 07:49:45AM +0100, Jiri Moskovcak wrote:
On 10/26/2014 11:13 PM, Dan Kenigsberg wrote:
On Sat, Oct 25, 2014 at 09:18:18PM -0400, Robert Story wrote:
On Sat, 25 Oct 2014 23:30:41 +0100 Dan wrote: DK> On Sat, Oct 25, 2014 at 03:18:32PM -0400, Robert Story wrote: DK> > line 225, in _setupNetworks 'message: "%s"' % (networks, code, DK> > message)) RuntimeError: Failed to setup networks {'ovirtmgmt': DK> > {'nic': 'eth0', 'netmask': '255.255.255.0', 'bootproto': 'none', DK> > 'ipaddr': '10.69.79.31'}}. Error code: "16" message: "Unexpected DK> > exception" DK> DK> This means that something nasty happened inside Vdsm while attempting to DK> create the bridge. DK> DK> Can you attach vdsm.log and supervdsmd.log?
Sure...
http://futz.org/users/tmp/ovirt5/supervdsm.log http://futz.org/users/tmp/ovirt5/vdsm.log
supervdsm.log has
MainProcess|Thread-16::DEBUG::2014-10-25 12:37:25,045::supervdsmServer::101::SuperVdsm.ServerCallback::(wrapper) call setupNetworks with ({'ovirtmgmt': {'nic': 'eth0', 'netmask': '255.255.255.0', 'bootproto': 'none', 'ipaddr': '10.69.79.31'}}, {}, {'connectivityCheck': False}) {} MainProcess|Thread-16::WARNING::2014-10-25 12:37:25,046::libvirtconnection::135::root::(wrapper) connection to libvirt broken. ecode: 1 edom: 7 MainProcess|Thread-16::CRITICAL::2014-10-25 12:37:25,046::libvirtconnection::137::root::(wrapper) taking calling process down. MainThread::DEBUG::2014-10-25 12:37:25,046::supervdsmServer::451::SuperVdsm.Server::(main) Terminated normally MainProcess|Thread-16::DEBUG::2014-10-25 12:37:25,046::libvirtconnection::143::root::(wrapper) Unknown libvirterror: ecode: 1 edom: 7 level: 2 message: internal error client socket is closed
which means that libvirtd has died (or was restarted).
Jiri, can you tell why this has happened?
Hi Dan, I'm not libvirt expert, so I don't have any idea why it died and I don't think the setup restarts it during the installation.
When `vdsm-tool configure` change libvirt's condifuration, the installation should restart libvirtd. Vdsm (and supervdsm) must be restarted after the new libvirtd process is up. I remember that we had some problems in developement time, and wonder if we see here another case. Can you or Sandro compare timeings and check this out?