Bug 1004630 - vdsmd doesn't start after registration on oVirt Node (Fedora 19)
vdsmd doesn't start after registration on oVirt Node (Fedora 19)
Status: CLOSED DUPLICATE of bug 999664
Product: oVirt
Classification: Community
Component: vdsm (Show other bugs)
3.3
Unspecified Unspecified
urgent Severity urgent
: ---
: ---
Assigned To: Douglas Schilling Landgraf
Haim
:
Depends On:
Blocks: 918494
  Show dependency treegraph
 
Reported: 2013-09-05 01:58 EDT by Fabian Deutsch
Modified: 2013-09-05 09:49 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-05 09:49:58 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)
supervdsm.log (42.26 KB, text/x-log)
2013-09-05 05:42 EDT, Fabian Deutsch
no flags Details
vdsm.log (45.45 KB, text/x-log)
2013-09-05 05:42 EDT, Fabian Deutsch
no flags Details
/var/log/messages (178.39 KB, text/plain)
2013-09-05 05:43 EDT, Fabian Deutsch
no flags Details

  None (edit)
Description Fabian Deutsch 2013-09-05 01:58:20 EDT
Description of problem:
vdsmd doesn't come up cleanly after registering Node with Engine and rebooting the Node.

Version-Release number of selected component (if applicable):
vdsm-4.12.1-1

How reproducible:
Always

Steps to Reproduce:
1. Install Node with vdsm: http://fedorapeople.org/~fabiand/node/ovirt-node-iso-3.0.1-1.0.20130903draft.vdsm.fc19.iso
2. Configure network and register with Engine
3. Set host into maintenance mode 
4. Reboot the Node

Actual results:
vdsmd is in a failed state

Expected results:
vdsmd starts successfully

Additional info:
This issue is only present on F19 and not on EL6.

Restarting the service manually after rebooting works (so vdsmd will come up normally).

Also running
<alonbl> vdsm-tool libvirt-configure
<alonbl> vdsm-tool sanlock-check-service
brings up the service fine, alon's notes:
<alonbl> so I guess this is a race between services at startup.

ybronhei's notes:
<ybronhei> check if ksmtuned is there and run
<ybronhei> check if another instance of vdsm runs
<ybronhei> check also that sanlock is installe
Comment 1 Fabian Deutsch 2013-09-05 05:42:01 EDT
Created attachment 794142 [details]
supervdsm.log
Comment 2 Fabian Deutsch 2013-09-05 05:42:26 EDT
Created attachment 794143 [details]
vdsm.log
Comment 3 Fabian Deutsch 2013-09-05 05:43:06 EDT
Created attachment 794144 [details]
/var/log/messages
Comment 4 Fabian Deutsch 2013-09-05 06:46:38 EDT
Let me point out that this bug prevents Engine from using Node.

A workaround is to manually restart vdsmd.

This should be fixed before the release, otherwise we've got an non-working Engine-Node combination.
Comment 5 Mike Burns 2013-09-05 07:17:01 EDT
While there is a workaround available, it's an ugly workaround (login to ovirt-node, drop to a shell, run service vdsmd restart or systemctl restart vdsmd.service).  

If we can get this fixed in short order, then I'd rather hold the release a couple days.  

Thanks,

Mike
Comment 6 Mike Burns 2013-09-05 09:49:58 EDT
After additional testing, applying a manual workaround for bug 999664 results in vdsmd coming up correctly after reboot.

Manual workaround on node:

mount -o remount,rw /
edit /usr/lib/systemd/systemd-vdsmd to remove ksmtuned from CONFLICTING_SERVICES
persist /usr/lib/systemd/systemd-vdsmd

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

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