[libvirt] [PATCH 19/27] conf: Add XML for individual vCPU hotplug

[Daniel P. Berrange]

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.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|