ui: fix NPE when trying to create a pool with limited permissions

Bug-Url: https://bugzilla.redhat.com/1105622
Change-Id: I676d5d9bf0a51e2f570f3b45d930122e58b24fcf
Signed-off-by: Shahar Havivi <shaharh@redhat.com>
engine: Persist empty QoS for VM

This has been fixed previously for host QoS but not for VMs; in case
no QoS is assigned to a profile, an empty entry is sent (rather than
no entry).

Change-Id: Iffe16ac863d338aa82cab1248b8fb1769ac7fcd3
Bug-Url: https://bugzilla.redhat.com/1105080
Signed-off-by: Lior Vernia <lvernia@redhat.com>
core: move the logic in VmPoolHandler to separate command

The logic of how to handle VM that went down is extracted to separate
command, so the invocation of this logic is be in a more standard way.
The DownVmsHandler remains, it will later on be used as a listener for
notifications from VURTI.

Change-Id: Ic8840b8cba0fcec68936f0f24abc9948568cca0d
Bug-Url: https://bugzilla.redhat.com/1108675
Signed-off-by: Arik Hadas <ahadas@redhat.com>
core: do not handle crashed VM twice

We used to save the VMs which moves to Down in a List which means that
theoretically we can have duplicated VMs in the List. Because of bz
1099846, we might get into a situation where VM will be in the List
twice.

Before extracting the handling of the VMs that went down to separate
thread, it is important to make sure we have each VM stored in this
collection only one, so we won't invoke redundant threads. So the
solution is to change the List to be Set, so it will not store
duplicated values.

Change-Id: I913cf18ad341090f3ed1df5acda93b372af7ab4d
Bug-Url: https://bugzilla.redhat.com/1108675
Signed-off-by: Arik Hadas <ahadas@redhat.com>
core: process VMs that went down on separate thread

In order to prevent the processing of VMs that went down from blocking
the VURTI thread, we'll do the processing in a separate thread.

Change-Id: I903992087c7d5975548746f45451fccbfd38b299
Bug-Url: https://bugzilla.redhat.com/1108675
Signed-off-by: Arik Hadas <ahadas@redhat.com>
core: fix reattempt to go to maintenance mechanism

We used to calculate the time from which we should retry to switch the
host to maintenance in case of failure while changing the status of the
host from preparing to maintenance to other status. This is wrong. We
should calculate it when we set the host's status to preparing to
maintenance.

Change-Id: I39835028d5696b9e7a3473852ccf5bf70d3d74d4
Bug-Url: https://bugzilla.redhat.com/1110126
Signed-off-by: Arik Hadas <ahadas@redhat.com>