<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">I have left this for a while without
continuing because I had to focus on other things. However this is
still in progress :-)<br>
On 03/13/2013 10:55 PM, Ayal Baron wrote:<br>
</div>
<blockquote
cite="mid:25893083.7640290.1363211722007.JavaMail.root@redhat.com"
type="cite">
<pre wrap="">
----- Original Message -----
</pre>
<blockquote type="cite">
<pre wrap="">
----- Original Message -----
</pre>
<blockquote type="cite">
<pre wrap="">From: "Ayal Baron" <a class="moz-txt-link-rfc2396E" href="mailto:abaron@redhat.com"><abaron@redhat.com></a>
To: "Saggi Mizrahi" <a class="moz-txt-link-rfc2396E" href="mailto:smizrahi@redhat.com"><smizrahi@redhat.com></a>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:engine-devel@ovirt.org">engine-devel@ovirt.org</a>, <a class="moz-txt-link-abbreviated" href="mailto:vdsm-devel@lists.fedorahosted.org">vdsm-devel@lists.fedorahosted.org</a>,
"Vinzenz Feenstra" <a class="moz-txt-link-rfc2396E" href="mailto:vfeenstr@redhat.com"><vfeenstr@redhat.com></a>
Sent: Wednesday, March 13, 2013 5:39:24 PM
Subject: Re: [vdsm] [Engine-devel] Proposal VDSM <=> Engine Data
Statistics Retrieval Optimization
----- Original Message -----
</pre>
<blockquote type="cite">
<pre wrap="">I am completely against this.
It make the return value differ according to input which
is a big no no when talking about type safe APIs.
The only reason we have this problem is because there is this
thing against making multiple calls.</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
Which is totally contra productive because multiple calls, if
properly split up, will actually lead to less data sent for frequent
needed data calls. And the others shall be triggered when necessary.<br>
<blockquote
cite="mid:25893083.7640290.1363211722007.JavaMail.root@redhat.com"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
Just split it up.
getVmRuntimeStats() - transient things like mem and cpu%
getVmInformation() - (semi)static things like disk\networking
layout
etc.
Each updated at different intervals.
</pre>
</blockquote>
<pre wrap="">
+1 on splitting the data up into 2 separate API calls.
You could potentially add a checksum (md5, or any other way) of the
"static" data to getVmRuntimeStats and not bother even with polling
the VmInformation if this hasn't changed. Then you could poll as
often as you'd like the stats and immediately see if you also need
to retrieve VmInfo or not (you rarely would).
</pre>
</blockquote>
<pre wrap="">+1 To Ayal's suggestion
except that instead of the engine hashing the data VDSM sends the
key which is opaque to the engine.
This can be a local timestap or a generation number.
</pre>
</blockquote>
<pre wrap="">
Of course vdsm does the hash, otherwise you'd need to pass all the data to engine which would beat the purpose.</pre>
</blockquote>
We need the hash if we can't have dynamic content. Generation
numbers aren't really helpful as every call aggregates the
statistics data newly, at the moment at least.
<blockquote
cite="mid:25893083.7640290.1363211722007.JavaMail.root@redhat.com"
type="cite">
<blockquote type="cite">
<pre wrap="">
But, we might want to consider that when we add events polling
becomes (much) less frequent so maybe it'll be an overkill.
</pre>
</blockquote>
<pre wrap="">
You'd still need to compare versions of the data in vdsm and send only if it changed. If you don't persist what was received last then potentially you could have a monday morning effect where upon on system startup you'd be sending everything. So I still think you'd want to have the hash.</pre>
</blockquote>
We do a hash already on the XML and include it in the getStats
response.<br>
Hashes should show enough difference.<br>
<br>
Now to the non-dynamic responses and 'type-safe' API: If we would go
for non dynamic responses we would need for sure 5 new API calls to
achieve some gain on the amount of data sent.<br>
<br>
<b>getAllVmRuntimeStats() "returns a map of vmId/data pairs for all
vms"</b><br>
# All the time changing data which is needed by the oVirt Engine, or
so often changing that it does not make sense<br>
# to place it anywhere else<br>
{<br>
VmId: {<br>
cpuSys --> Could be potentially summarized<br>
cpuUser -/<br>
memUsage<br>
elapsedTime,<br>
status<br>
statsAge<br>
<br>
hashes = {<br>
conf, # Hased information of the XML
(This one is called "hash" in getStats())<br>
info, # Hashed information of semi
static items<br>
statusHash: # Hashed information of items with
are likely to change however not that often<br>
guestDetails: # Hashed value of the guest details
(applicationList, network information)<br>
}<br>
}<br>
<br>
<b><b>getVmStatuses([vmId1, vmId2, ...])</b></b><b><b><b> "Returns a
vmId/data pair for each vm requested"</b></b><br>
</b># This data does not change that often and can be
retrieved on demand once the hash changes<br>
return {<br>
vmId: {<br>
timeOffset,<br>
monitorResponse<br>
clientIp,<br>
lastLogin,<br>
username,<br>
session,<br>
guestIPs,<br>
}<br>
}<br>
<br>
<b>getAllVmDeviceStatistics():</b><b> "Returns a vmId/data pair for
all vms"</b><br>
# This data has to be requested all the time however in lower
intervals (e.g. every 5 minutes)<br>
# And is usually needed for all the VMs anyway<br>
return {<br>
vmId: {<br>
network,<br>
disksUsage, # Might be improved by summarizing?<br>
disks,<br>
balloonInfo,<br>
memoryStats<br>
}<br>
}<br>
<br>
<b>getVmInfo([vmId1, vmId2, ...]) "Returns a vmId/data pair for each
vm requested"<br>
</b> # Basically this should be almost constant, except if there
have been changes like migrations, pausing, errors etc<br>
return {<br>
vmId: {<br>
acpiEnable,<br>
vmType,<br>
guestName,<br>
guestOS,<br>
kvmEnable,<br>
pauseCode,<br>
displayIp,<br>
displayPort,<br>
displaySecurePort,<br>
pid,<br>
}<br>
}<br>
<br>
<b>getVmGuestDetails</b>([vmId1, vmId2, ...])<br>
# Data which changes seldom and these changes can be reflected
in the hash when this needs to be requested<br>
# This data is really only necessary when it really has been
changed or needs to be refreshed for whatever reason. <br>
return {<br>
vmId: {<br>
appsList,<br>
netIfaces,<br>
}<br>
}<br>
<br>
<blockquote
cite="mid:25893083.7640290.1363211722007.JavaMail.root@redhat.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
----- Original Message -----
</pre>
<blockquote type="cite">
<pre wrap="">From: "Vinzenz Feenstra" <a class="moz-txt-link-rfc2396E" href="mailto:vfeenstr@redhat.com"><vfeenstr@redhat.com></a>
To: <a class="moz-txt-link-abbreviated" href="mailto:vdsm-devel@lists.fedorahosted.org">vdsm-devel@lists.fedorahosted.org</a>, <a class="moz-txt-link-abbreviated" href="mailto:engine-devel@ovirt.org">engine-devel@ovirt.org</a>
Sent: Thursday, March 7, 2013 6:25:54 AM
Subject: [Engine-devel] Proposal VDSM <=> Engine Data
Statistics
Retrieval Optimization
Please find the prettier version on the wiki:
<a class="moz-txt-link-freetext" href="http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval">http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval</a>
Proposal VDSM - Engine Data Statistics Retrieval
VDSM <=> Engine data retrieval optimization
Motivation:
Currently the RHEVM engine is polling the a lot of data from
VDSM
every 15 seconds. This should be optimized and the amount of
data
requested should be more specific.
For each VM the data currently contains much more information
than
actually needed which blows up the size of the XML content
quite
big. We could optimize this by splitting the reply on the
getVmStats
based on the request of the engine into sections. For this
reason
Omer Frenkel and me have split up the data into parts based on
their
usage.
This data can and usually does change during the lifetime of
the
VM.
Rarely Changed:
This data is change not very frequent and it should be enough
to
update this only once in a while. Most commonly this data
changes
after changes made in the UI or after a migration of the VM to
another Host. Status = Running acpiEnable = true vmType = kvm
guestName = W864GUESTAGENTT displayType = qxl guestOs = Win 8
kvmEnable = true # this should be constant and never changed
pauseCode = NOERR monitorResponse = 0 session = Locked # unused
netIfaces = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC',
'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet':
['10.34.60.148'],
'hw': '00:1a:4a:22:3c:db'}] appsList = ['RHEV-Tools 3.2.4',
'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', 'RHEV-Network64
3.2.2',
'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64
3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', 'RHEV-USB
3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] pid =
11314
guestIPs = 10.34.60.148 # duplicated info displayIp = 0
displayPort
= 5902 displaySecurePort = 5903 username = user@W864GUESTAGENTT
clientIp = lastLogin = 1361976900.67 Often Changed:
This data is changed quite often however it is not necessary to
update this data every 15 seconds. As this is cumulative data
and
reflects the current status, and it does not need to be
snapshotted
every 15 seconds to retrieve statistics. The data can be
retrieved
in much more generous time slices. (e.g. Every 5 minutes)
network
=
{'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': '0',
'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', 'rxRate':
'0.0',
'txErrors': '0', 'state': 'unknown', 'speed': '100', 'name':
'vnet1'}} disksUsage = [{'path': 'c:\\', 'total':
'64055406592',
'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', 'total':
'3490912256', 'fs': 'UDF', 'used': '3490912256'}] timeOffset =
14422
elapsedTime = 68591 hash = 2335461227228498964 statsAge = 0.09
#
unused Often Changed but unused
This data does not seem to be used in the engine at all. It is
not
even used in the data warehouse. memoryStats = {'swap_out':
'0',
'majflt': '0', 'mem_free': '1466884', 'swap_in': '0',
'pageflt':
'0', 'mem_total': '2096736', 'mem_unused': '1466884'}
balloonInfo
=
{'balloon_max': 2097152, 'balloon_cur': 2097152} disks =
{'vda':
{'readLatency': '0', 'apparentsize': '64424509440',
'writeLatency':
'1754496', 'imageID': '28abb923-7b89-4638-84f8-1700f0b76482',
'flushLatency': '156549', 'readRate': '0.00', 'truesize':
'18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency':
'0',
'apparentsize': '0', 'writeLatency': '0', 'flushLatency': '0',
'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} Very
frequent uppdates needed by webadmin portal:
This data is mostly needed for the webadmin portal and might be
required to be updated quite often. An exception here is the
statsAge field, which seems to be unused by the Engine. This
data
could be requested every 15 seconds to keep things as they are
now.
cpuSys = 2.32 cpuUser = 1.34 memUsage = 30 Proposed Solution
for
VDSM & Engine:
We will introduce new optional parameters to getVmStats,
getAllVmStats and list to allow a finer grained specification
of
data which should be included.
Parameter: statsType = <string> (getVmStats, getAllVmStats
only)
Allowed values:
* full (default to keep backwards compatibility)
* app-list (Just send the application list)
* rare (include everything from rarely changed to very
frequent)
* often (include everything from often changed to very
frequent)
* frequent (only send the very frequently changed items)
Parameter: clientId = <string> The client id is specified by
the
client and should be unique however constantly used.
Parameter: diff = <boolean> In combination with the clientId
VDSM
will send only differences to the previous request from the
named
clientId. (if diff=true)
Additional Change:
Besides the introduction of the new parameters for list,
getVmStats
and getAllVmStats it might make sense to include a hash for the
appList into the rarely changed section of the response which
would
allow to identify changes and avoid having to sent the complete
appList every so often and only if the hash known to the client
is
outdated.
Note: The appList (Application List) reported by the guest
agent
could be fully implemented on request only, as long as the
guest
agent installed supports this. As there seems to be a request
to
have the complete list of installed applications on all guests
this
data could be quite extensive and a huge list. On the other
hand
this data is only rarely visible and therefore it should not be
requested all the time and only on demand. Improvement of the
Guest
Agent:
As part of the proposed solution it is necessary to improve the
guest
agent as well. For the full application list there should be
implemented a caching system which will be fully reactive and
should
not poll the application list for example all the time. The
guest
can create a prepared data file containing all data in the JSON
format (as used for the communication with VDSM via VIO) and
just
have to read that file from disk and directly sends it to VDSM.
However it is quite possible that this list is to big and it
might
have to be chunked into pieces. (Multiple messages, which would
have
to be supported by VDSM then as well) The solution for this is
to
make VDSM request this data and it will retrieve the data
necessary
on request only. --
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
_______________________________________________
Engine-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/engine-devel">http://lists.ovirt.org/mailman/listinfo/engine-devel</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
vdsm-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:vdsm-devel@lists.fedorahosted.org">vdsm-devel@lists.fedorahosted.org</a>
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel">https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
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</pre>
</body>
</html>