[libvirt] [PATCH 19/27] conf: Add XML for individual vCPU hotplug
phrdina at redhat.com
Wed Aug 17 12:53:47 UTC 2016
On Wed, Aug 17, 2016 at 01:45:18PM +0100, Daniel P. Berrange wrote:
> On Wed, Aug 17, 2016 at 02:42:21PM +0200, Peter Krempa wrote:
> > On Fri, Aug 12, 2016 at 10:29:53 +0200, Pavel Hrdina wrote:
> > > On Fri, Aug 05, 2016 at 03:56:15PM +0200, Peter Krempa wrote:
> > > > Individual vCPU hotplug requires us to track the state of any vCPU. To
> > > > allow this add the following XML:
> > > >
> > > > <domain>
> > > > ...
> > > > <vcpu current='1'>2</vcpu>
> > > > <vcpus>
> > > > <vcpu id='0' enabled='no' hotpluggable='yes'/>
> > > > <vcpu id='1' enabled='yes' hotpluggable='no' order='1'/>
> > > > </vcpus>
> > > > ...
> > > >
> > > > The 'enabled' attribute allows to control the state of the vcpu.
> > > > 'hotpluggable' controls whether given vcpu can be hotplugged and 'order'
> > > > allows to specify the order to add the vcpus.
> > >
> > > Based on CPU arch there are some restriction how many vcpus must be plugged in
> > > together, currently only for Power arch. Based on configured topology we can
> > Yep. I admit though that the documentation is pretty weak since I wanted
> > to get review started. I plan to add more of it though.
> > > plug only whole cores, which means group of vcpus. Because of this I would
> > > suggest that we group those vcpus in the XML like this:
> > >
> > > <vcpus>
> > > <group id='1' enabled='yes' hotpluggable='no' order='1'>
> > > <vcpu id='0'/>
> > > <vcpu id='1'/>
> > > </group>
> > I don't think this is a good idea:
> > 1) This XML part is not input-only thus users will need to provide this
> > (also see below)
> > 2) it's extremely verbose for non-weird architectures
> > granted, for ppc64 it allows to display the wiredness of the
> > core-level hotplug, but for x86 it's 3 times more verbose
> > on the off-hand it requires the user to provide this in advance an
> > 3) this does not hide the weirdness of the "hotpluggable entities" as
> > reported by qemu.
> > With this we basically could add the vcpus to <devices>. At the
> > 'group' granularity which would be basically a dumb wrapper on top of
> > the qemu design.
> > 4) It can't be properly verified at define time.
> > (okay, my approach can't be validated either, but it's vastly
> > simpler and more tolerant to config changes)
> Agree to all those points.
> IMHO the domain capabilities is the place where we should expose
> any information about the ppc-specific pre-requisite rules for
> vcpus and hotplug. Apps should consume the capabilities and then
> format domain XML in a "normal" syntax, honouring the constraints
> expressed in the capabilities.
Yes those points are valid and it makes sense. My main motivation was to
discuss the XML design before I'll continue with review.
More information about the libvir-list