core: monitoring - rename VURTI to HostMonitoring

Change-Id: I100d1821428260e9a7e623b06deabf71edcf5cbc
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1099068
Signed-off-by: Roy Golan <rgolan@redhat.com>
core: monitoring - split VDS and VMs monitoring apart

Change-Id: Ic2f4acb9ad6acd07552d4aabe97cd2a63a328b75
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1099068
Signed-off-by: Roy Golan <rgolan@redhat.com>
core: monitoring - adhere to fields naming convention

Change-Id: I18d520d3b7a61c2e02bb43ca73334b8c0ecc1c23
Signed-off-by: Roy Golan <rgolan@redhat.com>
core: monitoring - make host monitoring fetch mem commited from vms
monitoring

Change-Id: I5a9f1aa04f979a1278614f7c96b33458da399997
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1099068
Signed-off-by: Roy Golan <rgolan@redhat.com>
core: monitoring - make Vm a managed resource

- Introduce VmManger state object
- responsible for getting dynamic,statistics and saving to db
- holds the last changed status
- holds a lock to co-ordinate execution of commands or monitoring

Change-Id: Ia711cc2d69082ecc03325362291faa4a38aa6c0a
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1099068
Signed-off-by: Roy Golan <rgolan@redhat.com>
core: monitoring - separate Host Monitoring and Vm Moniting

- introduce another quartz job to fire each 3 seconds
(VDS_REFRESH_RATE)
- try lock each VM before monitoring - if fail don't monitor it
- Create, Destory Hibernate etc, that change VM state (status, dynamic, statistics)
must aquires this lock before executing and release finally
- Vm Monitoring locking is minimized to per-VM scope.

- Count memCommited and vmsCoresCount at VM Monitoring cycle
- Update VdsManager with the new values
- Host monitoring is responsible in getting those metrics and save to db
  if changed

Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1099068
Change-Id: I54c6091a3996c23a4b70c7ef89412d34f1b58e34
Signed-off-by: Roy Golan <rgolan@redhat.com>
core: VM monitoring - no need to handle exception

Execption handling isn't the responsibility of this class rather its
Host Monitoring task.

- fetchVMs is now void method
- VDSProtocolException was never used in the code

next:

separate the VM fetching strategy responsibility

Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1099068
Change-Id: I6f037813b52d63c45c97c44e3e6074c009dd5b9a
Signed-off-by: Roy Golan <rgolan@redhat.com>
core: VM Monitoring abstract fetching/analyzing/monitoring

this patch introduces the core changes the monitoring stack.
the work breaks down responsibilities and changes internal locking
characteristics:

* Data(VM/s) fetching:

  classes: VmListFetcher.java, VmStatisticsFetcher.java

  in-charge of fetching vms list/stats together with the db counter-part
  and store for analysis on VdsManager

* State analysis:

  classes: VmAnalyzer.java

  invoked with 2 view of a VM, a stored on (dbVm) and a running
  one(vdsmVm), analyzing what changed and marking with flags
  for further actions down the line. currently some actions are
  performed in-lined in the class - they should be moved out.

* Actions dispatching:

  classes: VmsMonitoring.java

  invoke all Vm analyzers in hand and iterate over their report
  and take actions - fire VDSM commands (destroy,run/rerun,migrate), report complete actions,
  hand-over migration and save-to-db

* New Locking characteristics:

  classes: VmManager.java

  responsible to lock a Vm entity (relation by Vm Guid) for exclusive
  dispatching a VDSM call OR a analysis && dispatching (i.e monitoring
  cycle)

  i.e. CreateVmVdsCommand will hold the lock, thus preventing only this
  single VM from being monitored.

Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1099068
Change-Id: I1adf0a95007140e89b080b5160ba93e340ee3ba6
Signed-off-by: Roy Golan <rgolan@redhat.com>
core: Monitoring - refactor Host newtork error handling

Host VDS network error should trigger a state change
and a treatment for auto-fencing as outlined in [1]

[1] http://www.ovirt.org/Automatic_Fencing

This handling is done at a single place [2] and is only called
from a single place, the VdsEventListener [3].

[2] VdsManager.handleNetworkException

[3] void onError(@Observes VdsNetworkException networkException)

*All* vds broker commands in action that throw VDS network exception is also
firing and event with the Exception as payload.

The event it caught by VdsEventListener and it invokes the handling on
using the assigned VdsManager in a separate thread.

Mo more VDSNetwork Exception throwing and re-throwing for flow control.

Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1099068
Change-Id: I59d26baa4d372905c8249edb0aabe28ea4c4a74a
Signed-off-by: Roy Golan <rgolan@redhat.com>
core: HostMonitoring - update cache when updating dynamic data

not updating the cache causes races in storing stale data to db such as
old status, vm count (in case doing Manual fence and so on...

Change-Id: Id007638586733b7263ae574e97a98c78faa5e666
https://bugzilla.redhat.com/show_bug.cgi?id=1099068
Signed-off-by: Roy Golan <rgolan@redhat.com>