Bug 1331577
| Summary: | hypervvssd, hypervfcopyd, hypervkvpd cause a timeout and notice when started on non-microsoft systems | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Zbigniew Jędrzejewski-Szmek <zbyszek> | ||||||||
| Component: | hyperv-daemons | Assignee: | Vitaly Kuznetsov <vkuznets> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | rawhide | CC: | antoine, bughunt, cristian.ciupitu, eliteknipser, icarohoff, jeremy9856, johannbg, kevin, lnykryn, mmuzila, msekleta, muadda, samuel-rhbugs, s, systemd-maint, thozza, vkuznets, zbyszek | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | hyperv-daemons-0-0.15.20160728git.fc26 hyperv-daemons-0-0.15.20160728git.fc24 hyperv-daemons-0-0.15.20160728git.fc25 | Doc Type: | Bug Fix | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2016-08-25 13:53:59 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Zbigniew Jędrzejewski-Szmek
2016-04-28 20:49:06 UTC
Well, this appears to be a misunderstanding what systemd unit conditions are and are supposed to be. The idea is that they do not affect the dependency tree. i.e. if a unit "foo" pulls in another unit "bar", and "foo" fails a condition this has no effect on whether "bar" is pulled in, it will still be pulled in. So, this is really a misuse of the condition stuff. I can see multiple ways out: a) drop the whole ConditionVirtulization= stuff. Instead pull in microsoft-virtualization.target or so via a udev rule that sets SYSTEMD_WANTS on the hv_vss device. Then change your services to plug into that target instead of multi-user.target, via WantedBy=. See systemd.device(5) for details about SYSTEMD_WANTS in udev rules. or: b) the same as above, but don't bother with definining the "microsoft-virtualization" target stuff, but pull in the services directly from the udev rule. This is fine if there's really no reason why one would ever want to turn off these services. or: c) drop the ConditionVirtualization= stuff, instead write a small generator that pulls in the microsoft services if systemd-detect-virt returns "microsoft". The generator can be a shell script if you like. See systemd.generator(7) for details on how to write generators. Created attachment 1155125 [details] patch to implement option b) from comment #1 Option b) seems best. It is simplest and was already implemented, so it is enough to remove the preset stuff to fix this bug. (I think those three services should be started "unconditionally", when the right hardware is present, and the packages are installed. This is recommended by the packaging guidelines https://fedoraproject.org/wiki/Packaging:Systemd#Hardware_activation and I don't see any advantage to making them condtional. If necessary, it is always possible to uninstall the package or mask the service.) https://pagure.io/fedora-release/pull-request/45 (master) https://pagure.io/fedora-release/pull-request/46 (f24) Created attachment 1155129 [details] patch to implement option b) from comment #1 v2 of patch, that also disables those daemons on existing installations, to also fix the bug for people who installed previously Created attachment 1184454 [details] patch to implement option b) from comment #1 v3: fix typo reported by Juha Leppänen <juha_efku> Oops, this wasn't assigned properly. While I see no point in having these daemons installed on non-Hyper-V guests I agree it makes sense to drop ConditionVirtualization= stuff and remove them from dependencies switching to udev-only activation. I'll try to experiment starting with your patch, thanks! I see no obvious flaws in the suggested solution, I tested it on both Hyper-V and non-Hyper-V installs and tested the upgrade, it works as expected. Here is a koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=15049187 I'll test it a bit more and if no one is against the idea push it to rawhide. As of today, my system being up-to-date with f24 upstream, I've still encountered the same problem. It makes my computer hang on for 1m28s-1m34s usually when the service is enabled. Even when disabling through systemd: sudo systemctl disable hypervvssd.service \ hypervfcopyd.service \ enable hypervkvpd.service The status returns: vendor preset: enable The preset still forcing it to enable... cat /usr/lib/systemd/system-preset/90-default.preset | grep yper # Hyper-V guest support daemons enable hypervvssd.service enable hypervfcopyd.service enable hypervkvpd.service I'm running the latest systemd from f24 branch: systemd-229-9.fc24.x86_64 Having a udev capable kernel makes this implementation of Hyper-V deprecated and pointless as it targets all devices globally instead of Hyper-V only. No changes were made to F24 so far. Did you test packages from http://koji.fedoraproject.org/koji/taskinfo?taskID=15049187 ? It should be possible to install them on F24. We'll ask to remove hyperv services from the default preset for future but with the packages from the scratch build (above) it shouldn't matter. My PR to disable the presets for F24 seems to have been lost. I opened https://pagure.io/fedora-release/issue/55 to have it reinstated. I think I have this problem on a fully up to date F24 août 18 03:03:41 Desktop systemd[1]: sys-devices-virtual-misc-vmbus\x21hv_vss.device: Job sys-devices-virtual-misc-vmbus\x21hv_vss.device/start failed with result 'timeout'. août 18 03:03:41 Desktop systemd[1]: hypervvssd.service: Job hypervvssd.service/start failed with result 'dependency'. août 18 03:03:41 Desktop systemd[1]: Dependency failed for Hyper-V VSS daemon. août 18 03:03:41 Desktop systemd[1]: Timed out waiting for device sys-devices-virtual-misc-vmbus\x21hv_vss.device. août 18 03:03:41 Desktop systemd[1]: sys-devices-virtual-misc-vmbus\x21hv_vss.device: Job sys-devices-virtual-misc-vmbus\x21hv_vss.device/start timed out. août 18 03:03:41 Desktop systemd[1]: sys-devices-virtual-misc-vmbus\x21hv_fcopy.device: Job sys-devices-virtual-misc-vmbus\x21hv_fcopy.device/start failed with result 'timeout'. août 18 03:03:41 Desktop systemd[1]: hypervfcopyd.service: Job hypervfcopyd.service/start failed with result 'dependency'. août 18 03:03:41 Desktop systemd[1]: Dependency failed for Hyper-V FCOPY daemon. août 18 03:03:41 Desktop systemd[1]: Timed out waiting for device sys-devices-virtual-misc-vmbus\x21hv_fcopy.device. août 18 03:03:41 Desktop systemd[1]: sys-devices-virtual-misc-vmbus\x21hv_fcopy.device: Job sys-devices-virtual-misc-vmbus\x21hv_fcopy.device/start timed out. août 18 03:03:41 Desktop systemd[1]: sys-devices-virtual-misc-vmbus\x21hv_kvp.device: Job sys-devices-virtual-misc-vmbus\x21hv_kvp.device/start failed with result 'timeout'. août 18 03:03:41 Desktop systemd[1]: hypervkvpd.service: Job hypervkvpd.service/start failed with result 'dependency'. août 18 03:03:41 Desktop systemd[1]: Dependency failed for Hyper-V KVP daemon. août 18 03:03:41 Desktop systemd[1]: Timed out waiting for device sys-devices-virtual-misc-vmbus\x21hv_kvp.device. août 18 03:03:41 Desktop systemd[1]: sys-devices-virtual-misc-vmbus\x21hv_kvp.device: Job sys-devices-virtual-misc-vmbus\x21hv_kvp.device/start timed out. Can it be fixed in F24 please ? It seem to make the boot way longer according to systemd-analyze Startup finished in 2.724s (kernel) + 784ms (initrd) + 1min 30.192s (userspace) = 1min 33.702s Thanks ! (In reply to jeremy9856 from comment #12) > I think I have this problem on a fully up to date F24 > ... > > Can it be fixed in F24 please ? It seem to make the boot way longer > according to systemd-analyze > > Startup finished in 2.724s (kernel) + 784ms (initrd) + 1min 30.192s > (userspace) = 1min 33.702s The fix is currently in rawhide, I'll prepare updates for F24 and already branched F25. Great ! Thank you. hyperv-daemons-0-0.15.20160728git.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-191d231dca hyperv-daemons-0-0.15.20160728git.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-90c7f9018e hyperv-daemons-0-0.15.20160728git.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-191d231dca hyperv-daemons-0-0.15.20160728git.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-90c7f9018e hyperv-daemons-0-0.15.20160728git.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report. Thanks for the update ! It's much better now. Startup finished in 2.719s (kernel) + 826ms (initrd) + 8.565s (userspace) = 12.111s hyperv-daemons-0-0.15.20160728git.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report. Hello. This still happens on my CentOS 7. Version 0.29.20160216git.el7 uname -r 3.10.0-514.2.2.el7.x86_64 only epel is "installed" KVP runs, vssd and daemon do not. I will try with udev now. Sorry, I don't think it is the same bug. My CentOS runs indeed as VM on HyperV. I'm so sorry (In reply to Michael Beck from comment #22) > Hello. This still happens on my CentOS 7. > Version 0.29.20160216git.el7 > uname -r > 3.10.0-514.2.2.el7.x86_64 > only epel is "installed" > > > KVP runs, vssd and daemon do not. > > I will try with udev now. (In reply to Michael Beck from comment #23) > Sorry, I don't think it is the same bug. My CentOS runs indeed as VM on > HyperV. > If vssd and fcopy don't run please check that you have these services enabled for your guest in Hyper-V. Please also check that it's not SELinux which prevents deaemons from starting. But, anyway, this sound like a different issue, feel free to open a BZ. |