Bug 1405797
| Summary: | vdsm-tool configure: comment-out offending values in libvirtd.conf and qemu.conf | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [oVirt] vdsm | Reporter: | Michael Burman <mburman> | ||||||
| Component: | General | Assignee: | Yaniv Bronhaim <ybronhei> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Pavel Stehlik <pstehlik> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 4.18.30 | CC: | bugs, danken, lsvaty, mburman, mgoldboi, oourfali, ybronhei | ||||||
| Target Milestone: | --- | Keywords: | FutureFeature, Reopened | ||||||
| Target Release: | --- | Flags: | sbonazzo:
ovirt-4.2-
lsvaty: testing_plan_complete- |
||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2017-06-26 10:01:43 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: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Michael Burman
2016-12-18 14:14:21 UTC
This bug is easily reproduced if doing it manually on a host and editing the /etc/libvirt/libvirtd.conf with auth_tcp = "none" Unit vdsmd.service has begun starting up. Dec 18 16:21:35 orchid-vds1.qa.lab.tlv.redhat.com vdsmd_init_common.sh[16232]: vdsm: Running mkdirs Dec 18 16:21:35 orchid-vds1.qa.lab.tlv.redhat.com vdsmd_init_common.sh[16232]: vdsm: Running configure_coredump Dec 18 16:21:35 orchid-vds1.qa.lab.tlv.redhat.com vdsmd_init_common.sh[16232]: vdsm: Running configure_vdsm_logs Dec 18 16:21:35 orchid-vds1.qa.lab.tlv.redhat.com vdsmd_init_common.sh[16232]: vdsm: Running wait_for_network Dec 18 16:21:36 orchid-vds1.qa.lab.tlv.redhat.com vdsmd_init_common.sh[16232]: vdsm: Running run_init_hooks Dec 18 16:21:36 orchid-vds1.qa.lab.tlv.redhat.com vdsmd_init_common.sh[16232]: vdsm: Running upgraded_version_check Dec 18 16:21:36 orchid-vds1.qa.lab.tlv.redhat.com vdsmd_init_common.sh[16232]: vdsm: Running check_is_configured Dec 18 16:21:36 orchid-vds1.qa.lab.tlv.redhat.com sasldblistusers2[16264]: DIGEST-MD5 common mech free Dec 18 16:21:36 orchid-vds1.qa.lab.tlv.redhat.com vdsmd_init_common.sh[16232]: Current revision of multipath.conf detected, preserving Dec 18 16:21:36 orchid-vds1.qa.lab.tlv.redhat.com vdsmd_init_common.sh[16232]: libvirt is already configured for vdsm Dec 18 16:21:36 orchid-vds1.qa.lab.tlv.redhat.com vdsmd_init_common.sh[16232]: vdsm: Running validate_configuration Dec 18 16:21:37 orchid-vds1.qa.lab.tlv.redhat.com vdsmd_init_common.sh[16232]: Error: Config is not valid. Check conf files Dec 18 16:21:37 orchid-vds1.qa.lab.tlv.redhat.com vdsmd_init_common.sh[16232]: FAILED: conflicting vdsm and libvirt-qemu tls configuration. Dec 18 16:21:37 orchid-vds1.qa.lab.tlv.redhat.com vdsmd_init_common.sh[16232]: vdsm.conf with ssl=True requires the following changes: Dec 18 16:21:37 orchid-vds1.qa.lab.tlv.redhat.com vdsmd_init_common.sh[16232]: libvirtd.conf: listen_tcp=0, auth_tcp="sasl", listen_tls=1 Dec 18 16:21:37 orchid-vds1.qa.lab.tlv.redhat.com vdsmd_init_common.sh[16232]: qemu.conf: spice_tls=1. Dec 18 16:21:37 orchid-vds1.qa.lab.tlv.redhat.com vdsmd_init_common.sh[16232]: Modules libvirt contains invalid configuration Dec 18 16:21:37 orchid-vds1.qa.lab.tlv.redhat.com vdsmd_init_common.sh[16232]: vdsm: stopped during execute validate_configuration task (task returned with error code 1). Dec 18 16:21:37 orchid-vds1.qa.lab.tlv.redhat.com systemd[1]: vdsmd.service: control process exited, code=exited status=1 Dec 18 16:21:37 orchid-vds1.qa.lab.tlv.redhat.com systemd[1]: Failed to start Virtual Desktop Server Manager. [root@orchid-vds1 ~]# vdsm-tool configure --force Checking configuration status... Current revision of multipath.conf detected, preserving libvirt is already configured for vdsm FAILED: conflicting vdsm and libvirt-qemu tls configuration. vdsm.conf with ssl=True requires the following changes: libvirtd.conf: listen_tcp=0, auth_tcp="sasl", listen_tls=1 qemu.conf: spice_tls=1. Running configure... Reconfiguration of libvirt is done. Error: ServiceOperationError: _systemctlStart failed Job for vdsmd.service failed because the control process exited with error code. See "systemctl status vdsmd.service" and "journalctl -xe" for details. This is known behavior. If libvirtd.conf includes values that vdsm also configures with vdsm-tool it collides. We don't take care of removing old configurations before adding vdsm section to the conf. If this indeed an rfe that needs to be solved we need to declare the reason for that. Until now we consider vdsm as the only configurator on the system, but ofcourse it might be not the case.. so please share a scenario where such behavior is required to be handled currently and we'll consider to add this logic. Closing as bug, please reopen as RFE if there is such need Michael, can you tell what created that odd libvirtd.conf? The host was configured using ospd10, so we believe that ospd10 created this odd libvirtd.conf. I'm not sure at the moment, i will have to check such host right after ospd10 installation is done. With your permission, I'll keep the needinfo set until you attach an osp10-generated libvirtd.conf and qemu.conf (so that I don't forget this bug) Attaching clean ospd10-generated libvirtd.conf and qemu.conf Created attachment 1234711 [details]
libvirtd and qemu confs
Do we have a valid workaround for OSP10 integration? Currently, the workaround is to manually comment-out the listen_tcp listen_tls and auth_tcp lines in libvirtd.conf, and spice_tls in qemu.conf (before adding the host). But we are only beginning to test integration, so this might be partial. From my understanding this can effect hosts which ere previously installed with OSP. since it's a corner case, I'm setting low priority. please let me know if there are additional use cases where it can be relevant. I'm quite sure it doesn't effect OSP hosts in general. do we modify directly the libvirtd.conf file on hypervisors as part of the OSP provisioning? the issue is related only to cases where the admin user (root user) modified manually or by other process libvirtd.conf file with values conflict with those that vdsm set. in this case - vdsm will set the values, but the value that appears first in the conf file will be the one that the program will use. the parser ignore later values in the conf file. to fix it, we need to process the conf file before adding our lines. as Dan said in comment #9, the workaround is to remove those configuration lines if exists before running "vdsm-tool configure". I don't see us getting to that, and there is a workaround. Closing this as wontfix. |