[libvirt] [PATCH 19/27] conf: Add XML for individual vCPU hotplug
Daniel P. Berrange
berrange at redhat.com
Wed Aug 17 12:45:18 UTC 2016
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 :|
More information about the libvir-list
mailing list