CA-88840:User Friendly error message when cross/intrapool migration fails

Signed-off-by: Akshay Ramani <akshay.ramani@citrix.com>
CA-102759: loosen HA restriction on expired hosts

Signed-off-by: Zheng Li <zheng.li@eu.citrix.com>
Adding console examples to git repo

Signed-off-by: Bob Ball <bob.ball@citrix.com>
PR-1455: Update perfmon wrt the new alert priority grade

Signed-off-by: Zheng Li <zheng.li@eu.citrix.com>
PR-1455: Remove VMPP specific mail-alarm code

Signed-off-by: Zheng Li <zheng.li@eu.citrix.com>
PR-1455: Revise default priority threshhold in mail-alarm

  * The previous PR-1455 work changed from mail-min-prioirty to mail-max-priority. I believe this is an unnecessary change that break backward compatability. "mail-min-priority" can literally mean the lowest message priority level to trigger an email alert. Which direction (greater value or smaller value) is lower is up for interpreation.
  * With PR-1455 definition, priority value between 1-3 will require actions, hence change the mail-min-priority threshhold to 3.

We should probably document this mail-min-priority config as part of PR-1455 doc in the release note (for incomptabile changes to the alert system in general).

Signed-off-by: Zheng Li <zheng.li@eu.citrix.com>
PR-1455: rewrite message priorities online during rolling pool upgrade

During rolling upgrade, upgraded master might have an alerts grading system different from the not yet upgraded slaves. During this process, as a special case, we transform the priority of a received message (if the message belongs to the standard messages set).

Signed-off-by: Zheng Li <zheng.li@eu.citrix.com>
PR-1455: Move some code from Xapi_message.create to Xapi_message.write

... so that we can reuse them when calling Xapi_message.write directly.

Signed-off-by: Zheng Li <zheng.li@eu.citrix.com>
PR-1455: rewrite message priority values during upgrade.

A host post-upgrade might have different priority on messages from pre-upgrade. In order to reduce confusions (e.g. messages with the same code before and after upgrade shown together with different priorities),  here we convert the messages pre-upgrade to use the new priority values.

We are using a very straightforward algorithm here: destroying a old message and recreating a new one keeping most of the settings untouched but the priority. A more elegant solution would be creating facilities to upgrade an existing message rather than destroy/recreate one. In fact, I was half way on that solution but decided to take the no so elegent but simpler approach. The straightfoward implementation can avoid many of the complexities because messages are not part of the datebase hence many things have to be updated manually (e.g. event, gen, symlink). It's much reliable to reuse the existing facilities rather than creating the new ones.

Signed-off-by: Zheng Li <zheng.li@eu.citrix.com>
PR-1455: Update pool's other-config:mail-min-priority to the new alerts grading system

Users were allowed to set the mail-min-priority to arbitray value before, so there isn't a definitive algorithm to map the setting to the new alert grades. This is just one reasonble way making the transformation:

Given previous mail-min-priority = n

    n > 10       ->  0
    n = 10       ->  1
    5 < n < 10   ->  2
    n = 5        ->  3
    1 < n < 5    ->  4
    n <= 1       ->  5
    unrecognized ->  remove (reset to default)

Signed-off-by: Zheng Li <zheng.li@eu.citrix.com>
CA-95053: VM.start should check if a host has enough memory

Though it should fall back to just trying anyway in case of
failure as memory checks are notoriously hard to get right.

This patch is based on a similar one by Jerome Maloberti.

Signed-off-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com>
Merge pull request #1216 from jonludlam/CA-95053-v2

CA-95053: VM.start should check if a host has enough memory
Merge pull request #1184 from zli/xenserver/CA-102759

CA-102759: loosen HA restriction on expired hosts
CA-105080: just added some comments
Signed-off-by: Thomas Sanders <thomas.sanders@citrix.com>
CA-106034: update device_watches when domain appears/disappears

When a domain appears, we need to initialise the entry in device_watches for
that domid. When a domain disappears, we need to remove the entry in
device_watches for that domid.

This was overlooked in the refactoring of CA-102259 -- the old semantics of
add_domU_watches and remove_domU_watches was not preserved as the watches map
was split into a set of domain watches and a map of device_watches.

Acked-by: Jonathan Davies <Jonathan.Davies@eu.citrix.com>
Signed-off-by: Mike McClurg <mike.mcclurg@citrix.com>
Merge pull request #1220 from mcclurmc/ca106034-xenstore-watches-master

CA-106034: update device_watches when domain appears/disappears
Merge pull request #1219 from thomassa/CA-105080

CA-105080: just added some comments
CA-105002: Robustify against domains that are unkillable

Signed-off-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com>
Merge pull request #1224 from jonludlam/CA-105002

CA-105002: Robustify against domains that are unkillable
Merge pull request #1210 from zli/xenserver/PR-1455

xenserver/PR-1455