Re: [Engine-devel] Async Task Manager improvements
- Original Message - > From: "Sahina Bose" > To: engine-devel@ovirt.org > Sent: Thursday, March 14, 2013 7:53:15 AM > Subject: Re: [Engine-devel] Async Task Manager improvements > > Hi Yair, > > Thanks for the detailed design. Hi Sahina, we're going to change the detailed design, to be more flexible and loose coupled. > Had some questions > > 1. Can we think about introducing some DI framework in the Task > Management package. This could be used to inject the DAL, VDS Broker, > Commons etc dependencies. Even the list of providers and > TaskStatusEvent > handlers could be registered using this framework. I think that at this point it's too early to talk about DI at the new task mgmt framework, but that's a possibility. We're aiming to a more general framework for scheduling operations + providing a mechanism to signal objects when the operations are ended. > > 2. You mention "Several providers that refer to instances of the same > external system type have the same ProviderLogic object. " I'm not > sure > I understand this. Could you clarify? This is still a draft and may change. I wanted to distinguish for example between an instance of SPM or gluster host and the logic to handle their task-related issues - so, you may have several instances of "task provider", but you have one logic per task provider type. > > 3. Will TaskManager also talk to Job entity and update/end Job if > necessary? Yes, this was not addressed at this point. > > 4. Are we planning to support custom actions on tasks? That is, > depending on status of task, task can be paused/ resumed/ aborted > /custom action performed etc Yes, the next phase of the design we're working on will be more flexible, and you will be able to have more flexibility. > > thanks > sahina > > > > On 03/11/2013 03:38 PM, Yair Zaslavsky wrote: > > Hi all, > > > > I would like to present you a document I'm working on (still in > > draft/working-in-progress mode) of changes to be done at the > > engine async task manager. > > > > Regarding the detailed design - > > > > The suggested design breaks the task management into two modules - > > task management/polling part + command management (in context of > > completion of tasks/commands). > > The current status of the design is that the design of task > > management is provided (needs some polishing) - the command > > management design will be provided soon. > > > > In addition, we already have some ideas for an alternative design > > for the task management part (as suggested by Saggi Mizrahi). > > After converging , we will present the complete design. > > The reason we're sending the Wiki now is that community members > > will be aware mainly to the motivations behind the changes > > > > (Perhaps we should create separate documents for the design and for > > the motivation/requirements) > > > > http://www.ovirt.org/Wiki/AsyncTaskManagerChanges > > > > > > Yair > > > > > > ___ > > Engine-devel mailing list > > Engine-devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Async Task Manager improvements
Hi Yair, Thanks for the detailed design. Had some questions 1. Can we think about introducing some DI framework in the Task Management package. This could be used to inject the DAL, VDS Broker, Commons etc dependencies. Even the list of providers and TaskStatusEvent handlers could be registered using this framework. 2. You mention "Several providers that refer to instances of the same external system type have the same ProviderLogic object. " I'm not sure I understand this. Could you clarify? 3. Will TaskManager also talk to Job entity and update/end Job if necessary? 4. Are we planning to support custom actions on tasks? That is, depending on status of task, task can be paused/ resumed/ aborted /custom action performed etc thanks sahina On 03/11/2013 03:38 PM, Yair Zaslavsky wrote: Hi all, I would like to present you a document I'm working on (still in draft/working-in-progress mode) of changes to be done at the engine async task manager. Regarding the detailed design - The suggested design breaks the task management into two modules - task management/polling part + command management (in context of completion of tasks/commands). The current status of the design is that the design of task management is provided (needs some polishing) - the command management design will be provided soon. In addition, we already have some ideas for an alternative design for the task management part (as suggested by Saggi Mizrahi). After converging , we will present the complete design. The reason we're sending the Wiki now is that community members will be aware mainly to the motivations behind the changes (Perhaps we should create separate documents for the design and for the motivation/requirements) http://www.ovirt.org/Wiki/AsyncTaskManagerChanges Yair ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization
- Original Message -
>
>
> - Original Message -
> > From: "Ayal Baron"
> > To: "Saggi Mizrahi"
> > Cc: engine-devel@ovirt.org, vdsm-de...@lists.fedorahosted.org,
> > "Vinzenz Feenstra"
> > Sent: Wednesday, March 13, 2013 5:39:24 PM
> > Subject: Re: [vdsm] [Engine-devel] Proposal VDSM <=> Engine Data
> > Statistics RetrievalOptimization
> >
> >
> >
> > - Original Message -
> > > 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.
> > >
> > > 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.
> >
> > +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).
> +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.
Of course vdsm does the hash, otherwise you'd need to pass all the data to
engine which would beat the purpose.
>
> But, we might want to consider that when we add events polling
> becomes (much) less frequent so maybe it'll be an overkill.
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.
>
> >
> > >
> > > - Original Message -
> > > > From: "Vinzenz Feenstra"
> > > > To: vdsm-de...@lists.fedorahosted.org, engine-devel@ovirt.org
> > > > 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:
> > > > http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval
> > > >
> > > > 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 se
Re: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization
- Original Message -
> From: "Ayal Baron"
> To: "Saggi Mizrahi"
> Cc: engine-devel@ovirt.org, vdsm-de...@lists.fedorahosted.org, "Vinzenz
> Feenstra"
> Sent: Wednesday, March 13, 2013 5:39:24 PM
> Subject: Re: [vdsm] [Engine-devel] Proposal VDSM <=> Engine Data Statistics
> Retrieval Optimization
>
>
>
> - Original Message -
> > 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.
> >
> > 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.
>
> +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).
+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.
But, we might want to consider that when we add events polling
becomes (much) less frequent so maybe it'll be an overkill.
>
> >
> > - Original Message -
> > > From: "Vinzenz Feenstra"
> > > To: vdsm-de...@lists.fedorahosted.org, engine-devel@ovirt.org
> > > 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:
> > > http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval
> > >
> > > 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 t
Re: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization
- Original Message -
> 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.
>
> 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.
+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).
>
> - Original Message -
> > From: "Vinzenz Feenstra"
> > To: vdsm-de...@lists.fedorahosted.org, engine-devel@ovirt.org
> > 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:
> > http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval
> >
> > 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
> >
Re: [Engine-devel] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization
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.
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.
- Original Message -
> From: "Vinzenz Feenstra"
> To: vdsm-de...@lists.fedorahosted.org, engine-devel@ovirt.org
> 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:
> http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval
>
> 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 = (getVmStats, getAllVmStats only)
> Allowed values:
>
> * full (default to keep backwards compatibility)
> * app-list (Just send
Re: [Engine-devel] VmDynamic kvm_enable
On Wed, Mar 13, 2013 at 12:58:44AM +0200, Itamar Heim wrote: > On 03/12/2013 05:07 PM, Dan Kenigsberg wrote: > >On Tue, Mar 12, 2013 at 10:37:41AM -0400, Laszlo Hornyak wrote: > >>Hi, > >> > >>I came across a VmDynamic property 'kvm_enable'. It sounds strange for me, > >>because ovirt is very colsely integrated with kvm. So a short dig into this > >>flag... > >>There is a similar thing for the VDS, it is set to true by vdsm is the host > >>CPU has a VT flag. It is actually used to check if the host is OK to run > >>VMS. > >> > >>But the one for Vm it looks like a distributed logical loop in vdsm: it is > >>set when constructing a VM object (vdsm/vm.py:~343) from the data sent by > >>the client (engine) and then reported back in vm stats, so it is just a > >>roundtrip between vdsm and it's client. > >>In the engine side, it is just keeps sending it between the frontend DB and > >>vdsm, never part of a decision. > >> > >>Is this still needed here? Can I remove? > >>VDSM guys? > > > >I have a vague memeory that once upon at time, qemu occasionally failed > >to enable kvm support - even though it was asked to. I then silently > >switched to emulated mode, which was grindingly slow. Engine wanted to > >know about such occasions. > > > >I believe that a better technical approach would have been to kill the > >violating process, and not let it run at all (unless qemu emulation was > >strictly requested by management). > > > >Anyway, as you have noted, this has rotten away throuh the years, and > >unless older Engine versions are expecting this value in any way, I am > >all for dropping it. > > I think this was about something else - the kvmEnable flag was used > to launch installations of guests not correctly supported by kvm > that required real mode or something like that. You are now speaking about kvmEnable sent by Engine to Vdsm. Laszlo was speaking about a supposedly-dynamically-changing kvmEnable that is reported back, in getVmStats. > hopefully not relevant any more, but need to validate won't break > older engines indeed. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] engine watchdog support - new version in gerrit
hi, A new version of the engine watchdog support is available in gerrit. This version finished the rest-api support by adding the capabilities resources. The features listed in the feature page are ready, so if you have enough time and courage, please give it a try! I have left the patch with [wip] because I am waiting for the end of some discussions about the technical background. http://gerrit.ovirt.org/#/c/12419/ Thx, Laszlo ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
