[libvirt] [PATCHv2 4/6] API: Introduce VIR_DOMAIN_VCPU_AGENT, for agent based CPU hot(un)plug

[Daniel P. Berrange]

On Thu, Apr 18, 2013 at 12:00:09PM +0200, Peter Krempa wrote:
> Hmm, okay that seems fair enough. The virDomainSetvcpus api has the
> ideal name for this but mixing the semantics of disabling CPUs with
> the angent and ripping them out from the hypervisor might lead to
> user confusion.
> 
> In this case we need to design a new API. Here are a few suggestions:
> 
> 1) virDomainSetGuestVCPU(virDomainPtr dom,
> 			 unsigned int cpu_id,
> 			 bool state,
> 			 unsigned int flags);
> 
> This api would be very easy for us as only one cpu could be modified
> at time, thus no painful error reporting on semi-failed
> transactions. Harder to use in mgmt apps as they would need to call
> it multiple times.

Yep, the simplicity is nice. I don't think it is much of a burden
to apps.

> 2) virDomainSetGuestVCPUs(virDomainPtr dom,
> 			  virBitmapPtr to_online,
> 			  virBitmapPtr to_offline,
> 			  unsigned int flags);
> 
> Doesn't look very nice. Two bitmaps are needed as CPU indexes are
> not guaranteed to be contiguous inside of a guest. Is easier to use
> for mgmt apps as only a single call is needed. Libvirt will have to
> solve failures and maybe even attempt rollback.

More importantly I don't want us to expose virBitmapPtr in the public
API ! We'd want to use  raw bitmask as we do for other CPU related
APIs

> 3) virDomainSetGuestVCPUs(virDomainPtr dom,
> 			  virBitmapPtr cpumap,
> 			  bool state,
> 			  unsigned int flags);
> 
> Variation of 2), one cpu map and a state flag that will determine
> what action to take with the cpus provided in the map instead of two
> separate maps.
> 
> Other possibility would be to expose the cpu state in a kind of
> array as the agent monitor functions do it right now, but this
> wouldn't be expandable and would require users to use that new data
> structure.
> 
> Again, the getter functions will need to do the same, so that the
> user will be able to obtain a map of the system to do decisions
> about offlining and onlining processors.
> 
> 
> In the future we will also need similar APIs for classic cpu hotplug
> as qemu is probably going to support it in that way. With the
> classic hotplug we probably won't need to take care of sparse cpu
> ID's.
>
> Any other design or naming suggestions are welcome.

Since 'cpu_id' in this refers to the guest OS' notion of CPUs,
do we need some way to expose what the guest OS considers the
CPU IDs to be.

Personally I like the simpler first API, since it has easy to
understand error behaviour.

What is the data format QEMU agent requires for toggling CPUs ?
Does it allow multiple CPUs to be changed at once ?


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 :|