| Summary: | Cockpit reports vdsmd service is in failed state at initial install (as it was not yet configured) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Roger Heslop <rheslop> | ||||
| Component: | vdsm | Assignee: | Yaniv Bronhaim <ybronhei> | ||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Pavol Brilla <pbrilla> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 4.0.0 | CC: | bazulay, cshao, dfediuck, dguo, edwardh, fdeutsch, huzhao, jiawu, lsurette, mgoldboi, mperina, pstehlik, rbarry, rheslop, srevivo, weiwang, yaniwang, ybronhei, ycui, ykaul, yzhao | ||||
| Target Milestone: | ovirt-4.2.0 | Flags: | rbarry:
needinfo-
|
||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2017-11-21 15:50:00 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
Roger Heslop
2016-09-14 16:25:22 UTC
Created attachment 1200962 [details]
Screen shot of health status as seen through cockpit
It does appear as though vdsmd gets configured and subsequently started during hosted-engine setup. (I've moved on to troubleshooting another unrelated problem). The status of the vdsmd service came to light when opening cockpit to run through the HE setup process; the health status of the node within cockpit reads 'bad'. (See attachment) This apparently will be the default state of a node prior to HE setup, and I imagine will cause confusion for those using RHV-H hypervisor and cockpit for HE installation. The problem is really that vdsmd is enabled by default on RHVH - and because vdsm is unconfigured by default, it fails to come up. vdsm itself is enabling itself by default. And because these are vdsm's defaults, I wonder if it should be solved there. Edward, what do you think? Should vdsm not be enabled by default? Or could we add a conditional to the unit file, to only start vdsmd if i.e. the client certs are installed? This problem should actually be reproducable on RHEL: 1. install vdsmd 2. reboot 3. check vdsmd status vdsmd status should be failed Yaniv, do you recall why do we enable vdsm on installation (via presets) and not wait for vdsm-tool configure? https://gerrit.ovirt.org/43032 I don't see any problem with that.. after reboot vdsmd won't be up even if its enabled without the configure call. When installing the package I do want that as part of the rpm installation it will enable vdsmd in systemd automatically host-deploy, rhv-h setup or administrator that install vdsm rpms directly should take care for the configure call after the installation Fabian, I don't see how it is an infra bug. Please explain .. the bug is about requesting us to remove the "enable by default"? Node should manage this kind of installation flow properly .. it runs vdsm-tool configure during boot, doesn't it? Moving to Node for further investigation. (In reply to Yaniv Bronhaim from comment #6) > Fabian, I don't see how it is an infra bug. Please explain .. the bug is > about requesting us to remove the "enable by default"? > Node should manage this kind of installation flow properly .. it runs > vdsm-tool configure during boot, doesn't it? Node does manage this -- we do run "vdsm-tool configure --force" as part of rebooting. We also filter vdsm status in 'nodectl check' by checking to see if it ever actually started (rather than Starting ...), and fake the status being ok if it's never come up. So comment#2 is not valid -- we report a 'good' status Obviously this is just for basic sanity, and wouldn't do anything to resolve this bug (an administrator looking at journalctl). Roger, can you reach to the journal log from the same time vdsm failed to start? in the ticket you have logs when vdsm is already running and I can't see if the configure was indeed called Closing as insufficient data, feel free to reopen if reproduces again and add requested information |