Bug 1678085
| Summary: | use "-numa cpu" instead of "-numa node,cpus=" in libvirt | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Dan Zheng <dzheng> | |
| Component: | libvirt | Assignee: | Michal Privoznik <mprivozn> | |
| libvirt sub component: | General | QA Contact: | Luyao Huang <lhuang> | |
| Status: | CLOSED MIGRATED | Docs Contact: | ||
| Severity: | high | |||
| Priority: | medium | CC: | abologna, chhu, dyuan, dzheng, haizhao, hhuang, imammedo, jinqi, jsuchane, ldoktor, lvivier, mdeng, ngu, qzhang, rbalakri, smitterl, virt-maint, xuma, xuzhang, yalzhang, yihyu, yuhuang | |
| Version: | unspecified | Keywords: | MigratedToJIRA, Reopened, Triaged | |
| Target Milestone: | rc | |||
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | 1669434 | |||
| : | 2021932 (view as bug list) | Environment: | ||
| Last Closed: | 2023-09-22 17:32:24 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: | ||||
| Bug Depends On: | 2021932 | |||
| Bug Blocks: | 1382434 | |||
|
Description
Dan Zheng
2019-02-18 03:47:36 UTC
This looks very similar to bug 1783355 (In reply to Ján Tomko from comment #2) > This looks very similar to bug 1783355 Actually, it is not similar. There are two problems tracked in this bug. The first one is that libvirt doesn't put all vCPUs onto the command line (unless the domain XML contains the full specification too). The second one is that libvirt generates obsolete cmd line. For instance, instead of using: -smp 4,maxcpus=8,cores=2,threads=2,sockets=2 -numa node,cpus=0,cpus=1 -numa node,cpus=2,cpus=3 -numa node,cpus=4,cpus=5 -numa node,cpus=6,cpus=7 Libvirt should generate: -smp 4,maxcpus=8,cores=2,threads=2,sockets=2 -numa node,nodeid=0 -numa node,nodeid=1 -numa node,nodeid=2 -numa node,nodeid=3 -numa cpu,node-id=0,socket-id=0,core-id=0 -numa cpu,node-id=1,socket-id=0,core-id=1 -numa cpu,node-id=2,socket-id=1,core-id=0 -numa cpu,node-id=3,socket-id=1,core-id=1 Question is whether mixing these two approaches breaks migration. Igor, do you know if say the source used the old cmd line whether it is possible to migrate to a destination where new cmd line would be generated? (In reply to Michal Privoznik from comment #3) > (In reply to Ján Tomko from comment #2) ... > > Question is whether mixing these two approaches breaks migration. Igor, do > you know if say the source used the old cmd line whether it is possible to > migrate to a destination where new cmd line would be generated? one can map old schema to new by using query-cpus[-fast] command "CPU" [cpu-index] <-> props {topo properties}, that works for present CPUs only. With CPU hotplug, index could be inferred from the order of entries in query-hotpluggable-cpus response. But with cpu-add deprecated, we probably do not care about that case (libvirt should be using device_add for plugging cpus (available since qemu-2.7 (2016))) Problem with '-numa node,cpus=', is that one can't correctly assign CPUs to nodes since index doesn't reflect topology. In order to make it work libvirt user has to reimplement index to topology mapping(s) to make valid node assignment. So once libvirt moves away from '-numa node,cpus=' to "-numa cpu", I plan to remove the former. "-numa cpu" was introduced in qemu-2.10 (2017 commit 419fcdec3c1ff545) which allows us to avoid issues described in this bug, since it operates in topology terms that machine advertises. Patches proposed upstream: https://www.redhat.com/archives/libvir-list/2020-May/msg01035.html Bulk update: Move RHEL-AV bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release. Patches proposed upstream: https://listman.redhat.com/archives/libvir-list/2021-September/msg00635.html *** Bug 1382434 has been marked as a duplicate of this bug. *** After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. reopen it since patch is ready. Alright, so after re-reading the transcript again, I need to refresh my memory. As stated in comment 3 (and comment 0), libvirt needs to generate a different cmd line, so that QEMU can deprecate the current one. Let's go for it! Except, I must be missing something, because I don't see any benefit. What we currently have (assuming -smp 4,maxcpus=8,cores=2,threads=2,sockets=2): -numa node,cpus=0-1 -numa node,cpus=2-3 ... what is suggested here is: -numa cpu,node-id=0,socket-id=0,core-id=0 -numa cpu,node-id=0,socket-id=0,core-id=1 ... While this is more explicit on the cmd line, libvirt still needs to query QEMU to translate cpus=0-1, cpus=2-3 into socket/core/thread topology (as it is different for each platform), and thus QEMU can't drop that code ever and Libvirt needs to add new code only for the things to remain the same. Surely, I must be missing something. But what it is? (In reply to Michal Privoznik from comment #19) > Alright, so after re-reading the transcript again, I need to refresh my > memory. As stated in comment 3 (and comment 0), libvirt needs to generate a > different cmd line, so that QEMU can deprecate the current one. Let's go for > it! Except, I must be missing something, because I don't see any benefit. > What we currently have (assuming -smp > 4,maxcpus=8,cores=2,threads=2,sockets=2): > > -numa node,cpus=0-1 > -numa node,cpus=2-3 > ... > > what is suggested here is: > > -numa cpu,node-id=0,socket-id=0,core-id=0 > -numa cpu,node-id=0,socket-id=0,core-id=1 > ... > > While this is more explicit on the cmd line, libvirt still needs to query > QEMU to translate cpus=0-1, cpus=2-3 into socket/core/thread topology (as it > is different for each platform), and thus QEMU can't drop that code ever and > Libvirt needs to add new code only for the things to remain the same. > Surely, I must be missing something. But what it is? Well, reasoning why it needs to be done is explained in comment 4. (cpu-add was removed in 5.2, the only remaining configuration option that uses cpu-index is '-numa node,cpus') As for keeping '-numa node,cpus' forever, once libvirt implements '-numa cpu', QEMU side can deprecate and then drop legacy '-numa node,cpus='. (QEMU can keep unofficial support for cpu-index in query-cpus to facilitate conversion for old configs that used 'cpus=' to 'cpu', but otherwise cpu-index will not be longer used by CLI). Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug. This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there. Due to differences in account names between systems, some fields were not replicated. Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information. To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like: "Bugzilla Bug" = 1234567 In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information. |