Bug 1760233
| Summary: | Unable to complete install: 'Unable to read from '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or directory' | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | Chris Marusich <cmmarusich> | ||||||||
| Component: | libvirt | Assignee: | Pavel Hrdina <phrdina> | ||||||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | |||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | unspecified | CC: | crobinso, libvirt-maint, mprivozn, phrdina, rosen644835, tburke | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | libvirt-5.10.0 | Doc Type: | If docs needed, set a value | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2019-11-15 14:48:06 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
Chris Marusich
2019-10-10 08:51:05 UTC
CCing phrdina. this looks like a different root issue than the one we fixed in Fedora As you can read here[1] the core issue seems to be that the generic layout without systemd is exactly the same as with systemd without the .slice part (nor the delegation on the slice creation as far as I understand from the code), but nowhere on In virCgroupV2MakeGroup(src/util/vircgroupv2.c:429[2]) an mkdir is performed on the new sub-group, but I cannot find any check for the partition itself on virCgroupV2Available, that's the error reproducible with the guix image provided. The function virCgroupSetPartitionSuffix (src/util/vircgroupv2.c:789[3]) contains a reference of these directories as fixed, even though only systemd creates them. As far as I understand the manual should remove all references to user and system cgroups on non-systemd systems, which clearly is a bug. I'm attaching a patch for that. On the other hand, a clarification must be made by libvirt maintainers: either libvirt creates of /machine group when not running on systemd or the manual should specify that it is a configuration step that must be performed by system administrators and/or distributions before starting libvirtd, as it is specified with the custom partitions. [1] https://libvirt.org/cgroups.html#currentLayoutGeneric [2] https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/util/vircgroupv2.c;h=e0362990ab3ff669a38df0988f509359bb0cbbe6;hb=HEAD#l429 [3] https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/util/vircgroup.c;h=b46f20abfda626956b8a8c96d99c4c8c45800ddc;hb=HEAD#l789 Created attachment 1629745 [details]
Systemd references in non-systemd configurations
Hi Miguel, Thank you for the analysis! I just now walked through the code, myself, using the debug output I attached earlier as a guide. I examined the following version of the source (commit bafb3d1fbef9eac49230015b2fdbe60ceb1673b8, which was tagged with v5.6.0): https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/util/vircgroup.c;h=825f62a97b9cf637cf3664fcbce0522ddf15ef31;hb=bafb3d1fbef9eac49230015b2fdbe60ceb1673b8#l827 https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/util/vircgroupv2.c;h=e36c36685b6d0332d6310fe633fcfb4fbfd2f1de;hb=bafb3d1fbef9eac49230015b2fdbe60ceb1673b8 It looks to me like your assessment is correct: even though the directory /sys/fs/cgroup/unified/machine does not exist, libvirt does not create it. The debug output I attached earlier clearly shows the following functions being executed: 2019-10-10 06:45:05.116+0000: 335: debug : virCgroupNewMachineManual:1201 : Fallback to non-systemd setup 2019-10-10 06:45:05.116+0000: 335: debug : virCgroupNewPartition:849 : path=/machine create=1 controllers=ffffffff 2019-10-10 06:45:05.116+0000: 335: debug : virCgroupNew:678 : pid=-1 path=/machine parent=(nil) controllers=-1 group=0x7f28680c77e0 [... some lines omitted ...] 2019-10-10 06:45:05.118+0000: 335: error : virFileReadAll:1431 : Failed to open file '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or directory 2019-10-10 06:45:05.118+0000: 335: error : virCgroupV2ParseControllersFile:260 : Unable to read from '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or directory In fact, there IS a potential call path from virCgroupNewPartition to virCgroupMakeGroup to virCgroupV2MakeGroup, where mkdir is actually called. It looks like that mkdir invocation is intended to create the /sys/fs/cgroup/unified/machine directory, but I'm not 100% sure. In any case, libvirt never reaches that mkdir call when this problem occurs, since (in the virCgroupNewPartition function) the first call to virCgroupNew results in the error above. The fact that virCgroupMakeGroup has code to call virCgroupMakeGroup (and thus mkdir) makes me think that maybe libvirt intends to create the missing /sys/fs/cgroup/unified/machine directory but fails to do so. In any case, I agree that it would be helpful if the libvirt maintainers would clarify the intended behavior. If libvirt can be fixed to create the expected cgroups automatically, that would be great; however, if GNU/Linux distributions like Guix are expected to create the necessary cgroups before running libvirt, then we need clear guidance as to what needs to be created in this situation. -- Chris Created attachment 1631560 [details]
vircgroup: Ensure /machine group is associated with its parent.
This patch fixes the problem by providing the parent to the group creation. I've tested on the master branch. What do you think?
(In reply to Chris Marusich from comment #4) > (...) > The fact that virCgroupMakeGroup has code to call virCgroupMakeGroup (and > thus mkdir) makes me think that maybe libvirt intends to create the missing > /sys/fs/cgroup/unified/machine directory but fails to do so. In any case, I > agree that it would be helpful if the libvirt maintainers would clarify the > intended behavior. If libvirt can be fixed to create the expected cgroups > automatically, that would be great; however, if GNU/Linux distributions like > Guix are expected to create the necessary cgroups before running libvirt, > then we need clear guidance as to what needs to be created in this situation. Thank you very much for your analysis too. The intent is clear, as the create parameter is provided by the expression STREQ(partition, "/machine") in virCgroupNewMachineManual. The simplest way to solve it I've found was the one in the patch. Best regards, Miguel (In reply to Miguel Arruga Vivas from comment #5) > Created attachment 1631560 [details] > vircgroup: Ensure /machine group is associated with its parent. > > This patch fixes the problem by providing the parent to the group creation. > I've tested on the master branch. What do you think? Thanks for the patch, I'll look into it if that patch fixes this issue. However, libvirt project accepts patches that are send to libvir-list and we have some guidelines on how to submit a patch [1]. Can you please post the patch to mailing list. Few notes, we require Developer Certificate of Origin [2], so please add Signed-of-by with your real name into the commit message and subject of commit message should not end with a dot. Thanks, Pavel [1] <https://libvirt.org/hacking.html> [2] <https://developercertificate.org/> Pushed to master as: a74df786a2 vircgroup: Ensure /machine group is associated with its parent ddcb33bdc0 doc: cgroups: Remove unwanted references to systemd v5.9.0-251-ga74df786a2 |