Bug 713376 - [virt-manager]Modifiation of vcpus for guest rh4.9 could not take effect when the guest was installed with one cpu.
Summary: [virt-manager]Modifiation of vcpus for guest rh4.9 could not take effect when...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-manager
Version: 6.1
Hardware: x86_64
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Cole Robinson
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-15 08:16 UTC by Huming Jiang
Modified: 2011-07-22 02:47 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-07-21 13:51:57 UTC
Target Upstream Version:


Attachments (Terms of Use)
virt-manager.log (14.90 KB, text/plain)
2011-06-15 09:36 UTC, Huming Jiang
no flags Details

Description Huming Jiang 2011-06-15 08:16:51 UTC
Description of problem:
Install a guest rh4.9 with one cpu. After the installation is finished, change the vcpus to other values, such as, 2,3 or 9, apply. Then start the guest, log in, check the /proc/cpuinfo, the value of processor is always 0.

Version-Release number of selected component (if applicable):
kernel-2.6.32-131.0.13.el6
virt-manager-0.8.6-4.el6

How reproducible:
always

Steps to Reproduce:
1.Install a guest rh4.9 through network install, with "cpus=1",leave other param default. My os tree is http://download.englab.nay.redhat.com/pub/rhel/released/RHEL-4/U9/WS/x86_64/tree/
2.Log in the guest, check the processor in the /proc/cpuinfo.
2.After installation is finished. Change current allocation of "cpus" from "1" to "2","3","9","16"
3.Log in the guest, check the processor in the /proc/cpuinfo.

  
Actual results:
The value of processor is always 0.


Expected results:
The value of processor should changed with the current allocation of "cpus".

Additional info:
If set the vcpus value bigger than 1 in the installation process of guest rh4.9, there will be no this problem.

Comment 2 Huming Jiang 2011-06-15 09:36:43 UTC
Created attachment 504833 [details]
virt-manager.log

Comment 3 Cole Robinson 2011-07-21 00:08:07 UTC
I think rhel4 has a separate SMP kernel. Can you try installing that, rebooting into it, and see if it makes a difference? If so, please close this bug.

Comment 4 Huming Jiang 2011-07-21 04:39:56 UTC
(In reply to comment #3)
> I think rhel4 has a separate SMP kernel. Can you try installing that, rebooting
> into it, and see if it makes a difference? If so, please close this bug.

Reproduce it with the following components:
libvirt-0.9.3-7.el6.x86_64
qemu-kvm-0.12.1.2-2.165.el6.x86_64
kernel-2.6.32-170.el6.x86_64
virt-manager-0.8.6-4.el6.noarch

Steps is same with bug description.

Comment 5 Huming Jiang 2011-07-21 06:18:21 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > I think rhel4 has a separate SMP kernel. Can you try installing that, rebooting
> > into it, and see if it makes a difference? If so, please close this bug.
> 
> Reproduce it with the following components:
> libvirt-0.9.3-7.el6.x86_64
> qemu-kvm-0.12.1.2-2.165.el6.x86_64
> kernel-2.6.32-170.el6.x86_64
> virt-manager-0.8.6-4.el6.noarch
> 
> Steps is same with bug description.

My guest os tree is: http://download.englab.nay.redhat.com/pub/rhel/released/RHEL-4/U9/WS/x86_64/tree/

Install the guest with one vcpu, has the problem same with the bug description.
log in the guest:
#rpm -qa | grep kernel
kernel-utils-2.4-23.el4
kernel-2.6.9-100.EL
#uname -a 
Linux localhost.localdomain 2.6.9-100.EL #1 Tue Feb 1 11:59:36 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

Install the guest with two vcpu or more, no that problem.
log in the guest:
#rpm -qa | grep kernel
kernel-smp-2.6.9-100.EL
kernel-2.6.9-100.EL
kernel-utils-2.4-23.el4
#uname -a
Linux localhost.localdomain 2.6.9-100.ELsmp #1 SMP Tue Feb 1 12:04:42 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

So the guest kernel has been determined by the vcpus' value when the guest is created.

Comment 6 Cole Robinson 2011-07-21 13:51:57 UTC
> My guest os tree is:
> http://download.englab.nay.redhat.com/pub/rhel/released/RHEL-4/U9/WS/x86_64/tree/
> 
> Install the guest with one vcpu, has the problem same with the bug description.
> log in the guest:
> #rpm -qa | grep kernel
> kernel-utils-2.4-23.el4
> kernel-2.6.9-100.EL
> #uname -a 
> Linux localhost.localdomain 2.6.9-100.EL #1 Tue Feb 1 11:59:36 EST 2011 x86_64
> x86_64 x86_64 GNU/Linux
> 
> Install the guest with two vcpu or more, no that problem.
> log in the guest:
> #rpm -qa | grep kernel
> kernel-smp-2.6.9-100.EL
> kernel-2.6.9-100.EL
> kernel-utils-2.4-23.el4
> #uname -a
> Linux localhost.localdomain 2.6.9-100.ELsmp #1 SMP Tue Feb 1 12:04:42 EST 2011
> x86_64 x86_64 x86_64 GNU/Linux
> 
> So the guest kernel has been determined by the vcpus' value when the guest is
> created.

Right, I think that's how RHEL4 is expected to work. If the installer detects multiple CPUs it installs the SMP kernel, otherwise installs the UP kernel. If you add CPUs to the machine after install time and it is only using the UP kernel, it ignores the new CPUs.

Inside the guest, after adding more CPUs, you will need to do the RHEL4 equivalent of 'yum install kernel-smp' and reboot the guest, making sure it runs the SMP kernel. It should then see the new CPUs.

Closing NOTABUG. Please reopen if those steps don't work

Comment 7 Huming Jiang 2011-07-22 02:47:09 UTC
According to comment 6, do the following test:

Steps:
1. Install a rh4.9 guest with os tree http://download.englab.nay.redhat.com/pub/rhel/released/RHEL-4/U9/WS/x86_64/tree/, and set vcpu=1.
2. Log in the guest. download the following packages and install.
 kernel-largesmp-2.6.9-100.EL.x86_64.rpm
 kernel-largesmp-devel-2.6.9-100.EL.x86_64.rpm  
 kernel-smp-2.6.9-100.EL.x86_64.rpm                                   
 kernel-smp-devel-2.6.9-100.EL.x86_64.rpm 
3. Delete the original kernel
 #rpm -e kernel
 #rpm -e kernel-utils
4. Shutdown the guest, and set vcpu=2
5. Start the guest, and log in.
 #cat /proc/cpuinfo
 ...
 processor : 1

So this problem is not a bug.


Note You need to log in before you can comment on or make changes to this bug.