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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/17/13 11:16, Daniel P. Berrange wrote:
On Wed, Apr 17, 2013 at 08:47:01AM +0200, Peter Krempa wrote:
On 04/16/13 19:41, Daniel P. Berrange wrote:
On Tue, Apr 16, 2013 at 04:00:10PM +0200, Peter Krempa wrote:
This flag will allow to use qemu guest agent commands to disable
(offline) and enable (online) processors in a live guest that has the
guest agent running.

How do guest CPU offline/online state changes relate
to the offline/online state changes we have traditionally
done via the monitor.

ie if we offline a CPU with the guest agent, will then
now be visible in the state via the monitor ? And the
reverse ?

If you modify the guest state via agent it is not visible to the
host (except for the VCPU not consuming cpu time).

So this isn't really VCPU hotplug then. It is just toggling
whether the guest OS is scheduling things on that VCPU or
not. As such IMHO, we should not be overloading the existing
API with this functionality - we should have strictly separate
APIs for controlling guest OS vCPU usage.

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.

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.


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.

Peter

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]