Bug 851964 - [RFE] Add optional --placement and --cpuset parameter to setvcpus command
Summary: [RFE] Add optional --placement and --cpuset parameter to setvcpus command
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Martin Kletzander
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-27 07:11 UTC by hongming
Modified: 2016-04-27 00:40 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-09-03 07:23:22 UTC
Embargoed:


Attachments (Terms of Use)

Description hongming 2012-08-27 07:11:52 UTC
Description of problem:
The setvcpus command is unable to set the optional "placement" and "cpuset" parameters. The customers may have the request for virsh to tune the placement and host cpuset for virtual machines.



Quote as follows from libvirt.org http://libvirt.org/formatdomain.html#elementsCPUAllocation
vcpu

    The content of this element defines the maximum number of virtual CPUs allocated for the guest OS, which must be between 1 and the maximum supported by the hypervisor. Since 0.4.4, this element can contain an optional cpuset attribute, which is a comma-separated list of physical CPU numbers that virtual CPUs can be pinned to. Each element in that list is either a single CPU number, a range of CPU numbers, or a caret followed by a CPU number to be excluded from a previous range. Since 0.8.5, the optional attribute current can be used to specify whether fewer than the maximum number of virtual CPUs should be enabled. Since 0.9.11 (QEMU and KVM only), the optional attribute placement can be used to indicate the CPU placement mode for domain process, its value can be either "static" or "auto", defaults to placement of numatune, or "static" if cpuset is specified. "auto" indicates the domain process will be pinned to the advisory nodeset from querying numad, and the value of attribute cpuset will be ignored if it's specified. If both cpuset and placement are not specified, or if placement is "static", but no cpuset is specified, the domain process will be pinned to all the available physical CPUs. 



Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1.# virsh dumpxml rhel6q 

<domain>
  ...
  <vcpu placement='static' cpuset="1-4,^3,6" current="1">2</vcpu>
  ...
</domain>


2.# virsh help setvcpus
  NAME
    setvcpus - change number of virtual CPUs

  SYNOPSIS
    setvcpus <domain> <count> [--maximum] [--config] [--live] [--current]

  DESCRIPTION
    Change the number of virtual CPUs in the guest domain.

  OPTIONS
    [--domain] <string>  domain name, id or uuid
    [--count] <number>  number of virtual CPUs
    --maximum        set maximum limit on next boot
    --config         affect next boot
    --live           affect running domain
    --current        affect current domain

  
Actual results:
The setvcpus command is unable to set the optional "placement" and "cpuset" parameters.


Expected results:


Additional info:

Comment 2 hongming 2012-08-27 07:30:11 UTC
It maybe doesn't need to add the "cpuset" to  setvcpus command. The  vcpupin [cpulist] have the same function.

Comment 3 Martin Kletzander 2012-08-27 14:08:41 UTC
(In reply to comment #2)
The virsh command 'setvcpus' is intended only for setting the number of VCPUs.
As you said, there is vcpupin for setting the particular vcpu pinning. Even though I don't see any special advantage in configuring cpuset and particulary placement with virsh, I'll have a look how cumbersome this would be.

Is there any special reason for having this virsh-configurable?

Comment 4 hongming 2012-08-28 01:26:54 UTC
In my opinion , users maybe need to change the cpu "placement" and "cpuset" for running domain in NUMA environment. For example , change the "placement" of a running domain from "auto" to "static" , in order to pin the domain process from the advisory nodeset by querying numad to the specified cpus.

Comment 5 Martin Kletzander 2014-09-03 07:23:22 UTC
Live placement change is not something user should want to do.  Not that numad can't work properly in that case (static->auto) and changing it to static doesn't make sense (auto->static), but also in case of NUMA memory nodes, the memory might need to be moved, there can be insufficient space, etc.  Many things could cause performance degradation if such things are changed live.  If anyone needs to do this, he/she should thought this through and then we can discuss whether we need to add this functionality.  Adding it when there is no real need for it would just clutter up the code.

Reopen if necessary.


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