+++ This bug was initially created as a clone of Bug #545118 +++ +++ This bug was initially created as a clone of Bug #453042 +++ BZ #545118 introduces request for adding default-vcpus and max-vcpus options in libvirt API to allow number of initial and maximum vcpus set up and not to allocate all the vcpus to the guest at the boot time. Since it is going to be added to be libvirt (see RFE at BZ #545118) we need an interface to add it to virt-manager as well since now virt-manager is showing just maximum allocation set according to the HV it uses but the maximum allocation should be set to one from the HV configuration for this particular guest.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
This request was erroneously denied for the current release of Red Hat Enterprise Linux. The error has been fixed and this request has been re-proposed for the current release.
This is upstream now: http://hg.fedorahosted.org/hg/virt-manager/rev/5bdc66e596cc Though not sure what the dev effort will look like for a backport, the codebases are pretty different now.
Since we are pretty late in the RHEL5 cycle, I'm hesitant about adding this to virt-manager, since it would basically require a reimplementation since the relevant 5.6 code is 2 years old. How exactly does the customer want to use this functionality? Is it more important to set this value at install time or for existing guests? Is virt-manager support really necessary or is editing the XML by hand with 'virsh edit' sufficient? Is the customer using xen or kvm?
Okay, since a private comment indicated that the virsh functionality is sufficient for RHEL5, closing this as WONTFIX.