Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: message received from 54.76.25.247 which
 is an MX secondary for dev@cloudstack.apache.org)
MIME-Version: 1.0
From: Remi Bergsma <remi@remi.nl>
Date: Mon, 04 May 2015 10:04:21 +0000
Message-ID: 
 <CAHR8DBTSizY6Pcxg7ZPZUZyygo7c5zqxmvgdfz3QxLJy=11uiQ@mail.gmail.com>
Subject: [DISCUSS] XenServer and HA: the way forward
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Content-Type: multipart/alternative; boundary=f46d04428ef69b183a05153eafe0

--f46d04428ef69b183a05153eafe0
Content-Type: text/plain; charset=UTF-8

Hi all,

Since CloudStack 4.4 the implementation of HA in CloudStack was changed to
use the XenHA feature of XenServer. As of 4.4, it is expected to have XenHA
enabled for the pool (not for the VMs!) and so XenServer will be the one to
elect a new pool master, whereas CloudStack did it before. Also, XenHA
takes care of fencing the box instead of CloudStack should storage be
unavailable. To be exact, they both try to fence but XenHA is usually
faster.

To be 100% clear: HA on VMs is in all cases done by CloudStack. It's just
that without a pool master, no VMs will be recovered anyway. This brought
some headaches to me, as first of all I didn't know. We probably need to
document this somewhere. This is important, because without XenHA turned on
you'll not get a new pool master (a behaviour change).

Personally, I don't like the fact that we have "two captains" in case
something goes wrong. But, some say they like this behaviour. I'm OK with
both, as long as one can choose whatever suits their needs best.

In Austin I talked to several people about this. We came up with the idea
to have CloudStack check whether XenHA is on or not. If it is, it does the
current 4.4+ behaviour (XenHA selects new pool master). When it is not, we
do the CloudStack 4.3 behaviour where CloudStack is fully in control.

I also talked to Tim Mackey and he wants to help implement this, but he
doesn't have much time. The idea is to have someone else join in to code
the change and then Tim will be able to help out on a regularly basis
should we need in depth knowledge of XenServer or its implementation in
CloudStack.

Before we kick this off, I'd like to discuss and agree that this is the way
forward. Also, if you're interested in joining this effort let me know and
I'll kick it off.

Regards,
Remi

--f46d04428ef69b183a05153eafe0--