Bug 1685656
| Summary: | monitor cpu flag is not being transferred in host-passthrough | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Hetz Ben Hamo <hetz> |
| Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 29 | CC: | agedosier, berrange, clalancette, crobinso, itamar, jforbes, laine, libvirt-maint, veillard, virt-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| 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: | 2019-03-28 21:25:54 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: | |||
By definition "host-passthrough" enables every feature that KVM supports. There's no way to ask for more. Only a handful of QEMU CPU models require the 'monitor' feature - coreduo, core2duo, EPYC, EPYC-IBRS, n270, Opteron_G3 and phenom. So unless you have configured oVirt to use one of those CPU models for guests it launches, you should not need to have the 'monitor' flag. IOW, this feels like a probable oVirt mis-configuration I forgot to mention: I'm using 2 machines, both of them are Ryzen 2700 and in the host I can see this "monitor" flag, so it should transfer it, shouldn't it? I don't think oVirt can do something - if it finds that I'm using Ryzen/Threadripper/EPYC, then it asks for all the flags. Unless I'm missing something? (In reply to Hetz Ben Hamo from comment #2) > I forgot to mention: I'm using 2 machines, both of them are Ryzen 2700 and > in the host I can see this "monitor" flag, so it should transfer it, > shouldn't it? Yes, I would expect it to be passed, especially considering QEMU includes 'monitor' in its EPYC CPU model definition. This suggests KVM might be filtering it out for some reason > I don't think oVirt can do something - if it finds that I'm using > Ryzen/Threadripper/EPYC, then it asks for all the flags. I believe you can force a named CPU model in oVirt, rather than letting it try to expose the max. Picking Opteron_G4 might work if OVirt supports that I can force, but I need the full nested virtualization for oVirt. If KVM filters it, who need I need to contact in order to fix it? the oVirt guys? I think I explained myself incorrectly. oVirt is running under virt-manager. Virt-manager, with host-passthrough, doesn't expose this 'monitor' flag, so I think the bug is either in libvirt or virt-manager. This page has a reference to the 'monitor' flag, saying KVM never supported it and filters it out: https://wiki.qemu.org/Features/CPUModels So it sounds like this is expected behavior The MONITOR flag is now supported by KVM, but will never be enabled by default because it makes the VCPUs use 100% of the host CPU when using MWAIT. It requires the "-cpu ...,cpu-pm=on" option to be used, and I don't know if libvirt already supports it. That said, you really don't want oVirt to enable the MONITOR flag by default. If oVirt is refusing to run a VM because of the MONITOR flag, the solution is to make it stop trying to enable the feature, not to forcibly enable it. |
I'm using Fedora 29, fully updated, after reboot. When I'm creating a guest with virt-manager with CPU "host-passthrough" - it works, but it doesn't pass the "monitor" CPU flag. I can check it easily in the guest. While mostly it doesn't interrupt me, when trying to run oVirt as nested, it doesn't let you create or run any VM and it's complaining that the "monitor" CPU flag is not there ("Host CPU does not provide required features: monitor") and it fails to boot the VM. Is there any way to enable this CPU flag so oVirt will work well? Thanks