Invalid value '-1' for 'cpu.max': Invalid argument - a result of?
Hi guys. In hope that an expert read this - what is, can be, the below a result of? 12284 still running (86040) Invalid value '-1' for 'cpu.max': Invalid argument 12284 still running (86035) 12284 still running (86030) this is a snippet from libvirtd logs which is a consequence of what ovirt's engine setup is doing. To troubleshoot ansible playbooks which is what engine setup does, as I understand it, would be an impossible task for me so I reckoned I should try this end. many thanks, L.
On 5/14/23 07:35, lejeczek wrote:
Hi guys.
In hope that an expert read this - what is, can be, the below a result of?
12284 still running (86040) Invalid value '-1' for 'cpu.max': Invalid argument
This looks like a string coming from libvirt. When setting CGroups, from virCgroupSetValueRaw() which seems to be called (transitively) from virCgroupV2SetCpuCfsPeriod().
12284 still running (86035) 12284 still running (86030)
This string doesn't appear in our code base.
this is a snippet from libvirtd logs which is a consequence of what ovirt's engine setup is doing. To troubleshoot ansible playbooks which is what engine setup does, as I understand it, would be an impossible task for me so I reckoned I should try this end.
If you don't provide more context from the log I don't think we can help you, sorry. If there isn't more context (which I doubt, because at least common log line prefix was stripped) then set up debug logs, paste them somewhere and provide us with the link. Michal
On 15/05/2023 12:06, Michal Prívozník wrote:
On 5/14/23 07:35, lejeczek wrote:
Hi guys.
In hope that an expert read this - what is, can be, the below a result of?
12284 still running (86040) Invalid value '-1' for 'cpu.max': Invalid argument This looks like a string coming from libvirt. When setting CGroups, from virCgroupSetValueRaw() which seems to be called (transitively) from virCgroupV2SetCpuCfsPeriod().
12284 still running (86035) 12284 still running (86030) This string doesn't appear in our code base.
this is a snippet from libvirtd logs which is a consequence of what ovirt's engine setup is doing. To troubleshoot ansible playbooks which is what engine setup does, as I understand it, would be an impossible task for me so I reckoned I should try this end.
If you don't provide more context from the log I don't think we can help you, sorry. If there isn't more context (which I doubt, because at least common log line prefix was stripped) then set up debug logs, paste them somewhere and provide us with the link.
Michal
I think it might be here or related: https://bugzilla.redhat.com/show_bug.cgi?id=2037998 This should be reproducible easily I'd think as comes from widely - as I understand - used VM management platform. This is oVirt self hosted engine setup in a kvm-vm for which VM bare-metal host is Centos 9 Stream with everything up-to-dayte off the distro repos. I'd imagine if you/anybody were to try to deploy current-stable oVirt node and attempted to deploy hosted engine - will hit this very issue/errors. many thanks, L.
On 5/15/23 15:35, lejeczek wrote:
On 15/05/2023 12:06, Michal Prívozník wrote:
On 5/14/23 07:35, lejeczek wrote:
Hi guys.
In hope that an expert read this - what is, can be, the below a result of?
12284 still running (86040) Invalid value '-1' for 'cpu.max': Invalid argument This looks like a string coming from libvirt. When setting CGroups, from virCgroupSetValueRaw() which seems to be called (transitively) from virCgroupV2SetCpuCfsPeriod().
12284 still running (86035) 12284 still running (86030) This string doesn't appear in our code base.
this is a snippet from libvirtd logs which is a consequence of what ovirt's engine setup is doing. To troubleshoot ansible playbooks which is what engine setup does, as I understand it, would be an impossible task for me so I reckoned I should try this end.
If you don't provide more context from the log I don't think we can help you, sorry. If there isn't more context (which I doubt, because at least common log line prefix was stripped) then set up debug logs, paste them somewhere and provide us with the link.
Michal
I think it might be here or related: https://bugzilla.redhat.com/show_bug.cgi?id=2037998
Yep, looks like it's the same bug. It's supposed to be fixed in libvirt-9.0.0-2 rpm OR libvirt-9.1.0 upstream. What's your libvirt version?
This should be reproducible easily I'd think as comes from widely - as I understand - used VM management platform. This is oVirt self hosted engine setup in a kvm-vm for which VM bare-metal host is Centos 9 Stream with everything up-to-dayte off the distro repos. I'd imagine if you/anybody were to try to deploy current-stable oVirt node and attempted to deploy hosted engine - will hit this very issue/errors.
Unfortunately, I don't have a setup for running oVirt, nor I intent to create one, sorry. Michal
On 16/05/2023 14:14, Michal Prívozník wrote:
On 5/15/23 15:35, lejeczek wrote:
On 15/05/2023 12:06, Michal Prívozník wrote:
On 5/14/23 07:35, lejeczek wrote:
Hi guys.
In hope that an expert read this - what is, can be, the below a result of?
12284 still running (86040) Invalid value '-1' for 'cpu.max': Invalid argument This looks like a string coming from libvirt. When setting CGroups, from virCgroupSetValueRaw() which seems to be called (transitively) from virCgroupV2SetCpuCfsPeriod().
12284 still running (86035) 12284 still running (86030) This string doesn't appear in our code base.
this is a snippet from libvirtd logs which is a consequence of what ovirt's engine setup is doing. To troubleshoot ansible playbooks which is what engine setup does, as I understand it, would be an impossible task for me so I reckoned I should try this end.
If you don't provide more context from the log I don't think we can help you, sorry. If there isn't more context (which I doubt, because at least common log line prefix was stripped) then set up debug logs, paste them somewhere and provide us with the link.
Michal
I think it might be here or related: https://bugzilla.redhat.com/show_bug.cgi?id=2037998
Yep, looks like it's the same bug. It's supposed to be fixed in libvirt-9.0.0-2 rpm OR libvirt-9.1.0 upstream. What's your libvirt version?
This should be reproducible easily I'd think as comes from widely - as I understand - used VM management platform. This is oVirt self hosted engine setup in a kvm-vm for which VM bare-metal host is Centos 9 Stream with everything up-to-dayte off the distro repos. I'd imagine if you/anybody were to try to deploy current-stable oVirt node and attempted to deploy hosted engine - will hit this very issue/errors. Unfortunately, I don't have a setup for running oVirt, nor I intent to create one, sorry.
Michal
hmm, I've decommissioned that test-lab, whichever version is there in oVirt stable... I might try again later. ps. it does not take up much off the underlying hardware - as a VM, a few gigs and few cores.
On 5/16/23 14:57, lejeczek wrote:
hmm, I've decommissioned that test-lab, whichever version is there in oVirt stable... I might try again later.
Okay.
ps. it does not take up much off the underlying hardware - as a VM, a few gigs and few cores.
I know. It's not matter of hardware resources, it's matter of my time resources and willingness to reproduce something only to find it's already fixed. Usually, when I'm filing a bug against QEMU, I try to come up with as minimal reproducer as possible. And the very first step is to reproduce the bug without libvirt, i.e. via plain command line. Sure, I start with libvirt generated cmd line but then peel off unnecessary arguments. This preprocessing then makes it way easier for QEMU developers to reproduce and fix the issue. And thus increases my chances of getting the issue fixed. Michal
participants (2)
-
lejeczek -
Michal Prívozník