RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 994139 - $dom->get_vcpu_info() have some issues.
Summary: $dom->get_vcpu_info() have some issues.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: perl-Sys-Virt
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Daniel Berrangé
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-06 14:53 UTC by Daniel Berrangé
Modified: 2015-05-14 17:32 UTC (History)
8 users (show)

Fixed In Version: perl-Sys-Virt-1.1.1-2.el7
Doc Type: Bug Fix
Doc Text:
Previously, using the libvirt-tck utility to display virtual CPU (VCPU) information only printed a part of the expected diagnostics. With this update, the get_vcpu_info() function handles VCPU flags properly, and libvirt-tck displays the full extent of the expected information.
Clone Of: 905836
Environment:
Last Closed: 2014-06-13 10:39:58 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Daniel Berrangé 2013-08-06 14:53:55 UTC 
+++ This bug was initially created as a clone of Bug #905836 +++

Description of problem:
When try to get vcpus info using libvirt-tck,hash can't have keys mentioned in man page(cpu,cpuTime,state)


Version-Release number of selected component (if applicable):
libvirt-0.10.2-17.el6.x86_64
perl-Sys-Virt-0.10.2-5.el6.x86_64
kernel-2.6.32-348.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.348.el6.x86_64


How reproducible:
100%

Steps to Reproduce:
1.in libvirt-tck script,added
.....
my @vcpuinfo = $dom->get_vcpu_info();
foreach my $info(@vcpuinfo){
      while ((my $key, my $value) = each %$info){    
     diag "$key => $value\n";
         }
     }
.....
Actual results:
only list below two keys and values for each vcpu, i set vcpus to 3
# number => 0
# affinity =>
# number => 1
# affinity =>
# number => 2
# affinity =>


Expected results:
per /usr/share/man/man3/Sys::Virt:domain.3pm.gz,
get_vcpu_info should have 'number,cpu,cpuTime,state,affinity'

Additional info:
using virsh cmd line,result as below:
# virsh vcpuinfo win2012
VCPU:           0
CPU:            2
State:          running
CPU time:       22780.5s
CPU Affinity:   yyyy

VCPU:           1
CPU:            0
State:          running
CPU Affinity:   yyyy

VCPU:           2
CPU:            0
State:          running
CPU Affinity:   yyyy

--- Additional comment from Daniel Berrange on 2013-08-06 15:52:10 BST ---

commit f8514d9440ccc6827d6cb7d71e891fae10a26ad1
Author: Daniel P. Berrange <berrange>
Date:   Tue Aug 6 15:46:02 2013 +0100

    Fix handling of flags in get_vcpu_info()
    
    We must always use virDomainGetVcpus if flags is zero and
    fall back to virDomainGetVcpuPinInfo if we get an error
    indicating the guest was shutoff.
Comment 2 zhe peng 2013-08-26 05:58:28 UTC 
test with perl-Sys-Virt-1.1.1-2.el7.x86_64:

step same with bug description:
my @vcpuinfo = $dom->get_vcpu_info();

    foreach my $info(@vcpuinfo){
    while ((my $key, my $value) = each %$info){
    diag "$key => $value\n";
            }
   }

output:
# cpuTime => 0
# cpu => 3
# number => 0
# affinity => 

# state => 1
# cpuTime => 30000000
# cpu => 0
# number => 1
# affinity => 

# state => 1
# cpuTime => 30000000
# cpu => 0
# number => 2
# affinity => 

# state => 1

the output msg seem have some problem, the first cpu info 'state' in wrong order, hi, daniel , is it worked as expect?
Comment 3 Daniel Berrangé 2013-12-13 12:09:12 UTC 
(In reply to zhe peng from comment #2)
> test with perl-Sys-Virt-1.1.1-2.el7.x86_64:
> 
> step same with bug description:
> my @vcpuinfo = $dom->get_vcpu_info();
> 
>     foreach my $info(@vcpuinfo){
>     while ((my $key, my $value) = each %$info){
>     diag "$key => $value\n";
>             }
>    }
> 
> output:
> # cpuTime => 0
> # cpu => 3
> # number => 0
> # affinity => 
> 
> # state => 1
> # cpuTime => 30000000
> # cpu => 0
> # number => 1
> # affinity => 
> 
> # state => 1
> # cpuTime => 30000000
> # cpu => 0
> # number => 2
> # affinity => 
> 
> # state => 1
> 
> the output msg seem have some problem, the first cpu info 'state' in wrong
> order, hi, daniel , is it worked as expect?

The ordering of fields will not match the C struct ordering. This is because the data is stored in a hash table and Perl has random ordering of hash keys. So the results are fine here IMHO
Comment 4 zhe peng 2013-12-17 05:30:29 UTC 
per comment 3, move to verified.
Comment 5 Ludek Smid 2014-06-13 10:39:58 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.
Note You need to log in before you can comment on or make changes to this bug.