Bug 1434276
Summary: | virsh vcpupin shows the wrong cpu affinity details | ||
---|---|---|---|
Product: | [Community] Virtualization Tools | Reporter: | Satheesh Rajendran <sathnaga> |
Component: | libvirt | Assignee: | Daniel Henrique Barboza (IBM) <dbarboza> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | unspecified | CC: | bugproxy, dan, dbarboza, hannsj_uhl, laine, libvirt-maint, mprivozn, niteshkonkar.libvirt, pkrempa, srwx4096 |
Target Milestone: | --- | Keywords: | Reopened, Upstream |
Target Release: | --- | ||
Hardware: | ppc64le | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-08-07 13:41:45 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: | |||
Bug Blocks: | 1071880, 1480062 |
Description
Satheesh Rajendran
2017-03-21 07:10:46 UTC
Since you did not configure any specific vcpu pinning, the vcpu threads are allowed to run on all the host vcpus from libvirt's point of view. Returning the value expected by you would indicate that there's a pinning configured which is not true. (In reply to Peter Krempa from comment #1) > Since you did not configure any specific vcpu pinning, the vcpu threads are > allowed to run on all the host vcpus from libvirt's point of view. > > Returning the value expected by you would indicate that there's a pinning > configured which is not true. I agree partially but it can not be run on a offlined cpu which is in this case needs a proper initial value, it shows the invalid initial range for the user which is wrong whereas vcpuinfo API output is as expected. #virsh vcpupin vm1 0 1 error: Invalid value '1' for 'cpuset.cpus': Invalid argument --------------OK but the initial output range of affinity "0-159" contradicts that. This seems to me yet another design decision issue, of course it can be 'fixed', but do we want it fixed? Again, I am just trying to contribute some code. Dan (In reply to srwx4096 from comment #3) > This seems to me yet another design decision issue, of course it can be > 'fixed', but do we want it fixed? > > Again, I am just trying to contribute some code. > > Dan Hi Dan, I think this should be fixed because as pointed out by Viktor, CPU hotplug is very common on Linux running on z Systems and also widely used by customers. Reference: https://www.spinics.net/linux/fedora/libvir/msg140443.html Hence if a host CPU is offline and virsh cpupin/emulatorpin shows them as available for pinning, this would mislead user/other layers which shall end up in trying wrong pinning and fail. -Nitesh Any update on this? ------- Comment From scheloh.com 2019-07-30 15:08 EDT------- https://www.redhat.com/archives/libvir-list/2019-July/msg00747.html ------- Comment From lagarcia.com 2020-04-22 10:42 EDT------- It seems this one never got upstream. Getting it back to the team backlog. The best way to get a forgotten patch noticed is to rebase it to current upstream, then repost it to the mailing list with --subject-prefix="libvirt PATCH v2" Beyond that, libvirt is deprecating the use of bugzilla for upstream bugs. In the future all upstream bug tracking will be done using gitlab's issue tracker: https://www.redhat.com/archives/libvir-list/2020-April/msg00782.html Dan has been slowly going through the existing bugs in bugzilla and closing them or creating new records in the gitlab tracker as appropriate. I've just merged patches upstream: 2020c6af8a conf, qemu: consider available CPUs in vcpupin/emulatorpin output 42036650c6 virhostcpu.c: introduce virHostCPUGetAvailableCPUsBitmap() bc07020511 virhostcpu.c: refactor virHostCPUParseCountLinux() 9d31433483 virsh-domain.c: modernize cmdVcpuinfo() a3a628f54c virsh-domain.c: modernize virshVcpuinfoInactive() de6a40f01f virhostcpu.c: use g_autoptr in virHostCPUGetMap() 42bf2a7573 qemu_driver.c: use g_autoptr in qemuDomainGetEmulatorPinInfo() v6.5.0-69-g2020c6af8a ------- Comment From lagarcia.com 2020-08-05 07:08 EDT------- Fedora Rawhide has now libvirt 6.6, which includes these patches. Could you please verify and close this bug if everything is OK, Satheesh? ------- Comment From satheera.com 2020-08-05 08:05 EDT------- (In reply to comment #15) > Fedora Rawhide has now libvirt 6.6, which includes these patches. Could you > please verify and close this bug if everything is OK, Satheesh? Sure, will have it tested. Regards, -Satheesh ------- Comment From satheera.com 2020-08-07 08:11 EDT------- Tested with fedora rawhide libvirt version and found the issue is fixed, this bug can be closed. # lscpu Architecture: ppc64le Byte Order: Little Endian CPU(s): 32 On-line CPU(s) list: 0,8,16,24 Off-line CPU(s) list: 1-7,9-15,17-23,25-31 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Model: 2.3 (pvr 004e 1203) Model name: POWER9 (architected), altivec supported ... # virsh start f31 Domain f31 started # virsh vcpupin f31 VCPU CPU Affinity ---------------------- 0 0,8,16,24 1 0,8,16,24 2 0,8,16,24 3 0,8,16,24 4 0,8,16,24 5 0,8,16,24 6 0,8,16,24 7 0,8,16,24 # lscpu Architecture: ppc64le Byte Order: Little Endian CPU(s): 32 On-line CPU(s) list: 0-31 Thread(s) per core: 8 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Model: 2.3 (pvr 004e 1203) Model name: POWER9 (architected), altivec supported ... # virsh vcpupin f31 VCPU CPU Affinity ---------------------- 0 0-31 1 0-31 2 0-31 3 0-31 4 0-31 5 0-31 6 0-31 7 0-31 # rpm -qa|grep libvirt libvirt-bash-completion-6.6.0-1.fc33.ppc64le libvirt-libs-6.6.0-1.fc33.ppc64le libvirt-daemon-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-storage-core-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-network-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-nwfilter-6.6.0-1.fc33.ppc64le libvirt-daemon-config-nwfilter-6.6.0-1.fc33.ppc64le libvirt-daemon-config-network-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-lxc-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-storage-disk-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-storage-gluster-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-storage-iscsi-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-storage-iscsi-direct-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-storage-mpath-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-storage-scsi-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-storage-sheepdog-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-storage-zfs-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-nodedev-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-qemu-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-secret-6.6.0-1.fc33.ppc64le python3-libvirt-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-storage-logical-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-interface-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-storage-rbd-6.6.0-1.fc33.ppc64le libvirt-daemon-driver-storage-6.6.0-1.fc33.ppc64le libvirt-client-6.6.0-1.fc33.ppc64le libvirt-6.6.0-1.fc33.ppc64le libvirt-daemon-kvm-6.6.0-1.fc33.ppc64le libvirt-admin-6.6.0-1.fc33.ppc64le libvirt-daemon-qemu-6.6.0-1.fc33.ppc64le Regards, -Satheesh |