[ovirt-devel] "Host.queryVms": A proposal for new a VDSM API verb

[Saggi Mizrahi]

In 3.6 we are intending to have events in the json-rpc interface.

That means that a lot of the problems this is trying to fix will
no longer be an issue.

Changes about VM status will be sent as soon as they are available
instead of when the engine is polling.

This means that the messages will be smaller. We will also be
introducing compression which would make things even faster.

I also expressed my problems with VDSM keeping state.
When we move to an event driven system there would be no reason
to cache data anymore as internal polling would generate messages
and external polling would be used *only* to get up to date
information.

With call overhead being minimal getAllVmStats would just become
a list of getVmStats() for every VM of interest making the
filtering redundant.

Also, without internal caching it would also make the interface
of specifying the fields to include or exclude a bit problematic.
Having a bitflag (or a list of flags) to specify what type of
information is needed as it is easier to figure out what actual
calls need to be made. It is also easier for the user to know
that they are adding overhead to the response this way.

----- Original Message -----
> From: "Vinzenz Feenstra" <vfeenstr at redhat.com>
> To: devel at ovirt.org
> Sent: Monday, July 14, 2014 5:05:17 PM
> Subject: [ovirt-devel] "Host.queryVms": A proposal for new a VDSM API verb
> 
> Hi,
> 
> This proposal is a follow up on a previous discussion about
> optimizing the communication between VDSM and the ovirt-engine.
> 
> 
> Currently the engine polls VDSM every 3 seconds with the `list`
> verb to retrieve the status of all VMs. Every 5th time (every 15
> seconds) it alternates to 'getAllVmStats' which gives more
> information about the VMs.
> 
> 
> Quite a big portion of the data, mainly the reply of getAllVmStats,
> is only of interest if it actually changes so that the engine/back-end
> can act on changes and update rows accordingly.
> 
> Now the problem is that there is quite a lot of data transferred
> which is not really necessary and there is a 15 seconds delay on
> communicating changes to certain VMs before the engine actually
> can react on them and before these changes can be communicated
> to the user.
> 
> As part of an improvement on this matter I'd like to propose a new API
> verb for VDSM:
> 
> Host.queryVms(vmIds=[], fields=[], exclude=[], changedSince='')
> 
> This new verb is intended to eventually replace 2 currently
> used verbs `list` and `getAllVmStats`. `queryVms` is supposed to
> allow to request any data fields of a VM which can be requested through
> the public API:
> 
> - Statistics
> - Configuration
> - Status information
> - Guest OS Information
> 
> I have executed some tests and in those tested scenarios the new Verb
> can result in an improvement of 75%-90% of data transferred and average
> response body size depending on the scenario and usage.
> 
> The test results can be found here:
> http://www.ovirt.org/Feature/VDSM_VM_Query_API/Measurements#Results
> (An explanation of the tested methods is on the top of the page and a
> description of the scenario in each section)
> 
> The benefit of introducing this verb would be a lowered volume of data
> transferred over the management network which avoids congestion
> on huge setups and can introduce an increased responsiveness for
> communicating changes in state to the user. For example live migration
> status. However even SLA related changes could be communicated faster
> for things like QoS.
> 
> 
> Preliminary Feature Proposal Wiki:
> http://www.ovirt.org/Feature/VDSM_VM_Query_API
> 
> --
> Regards,
> 
> Vinzenz Feenstra | Senior Software Engineer
> RedHat Engineering Virtualization R & D
> Phone: +420 532 294 625
> IRC: vfeenstr or evilissimo
> 
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>