Mailing List Archive: Linux-HA: Users

Xen cluster, no migration when standby mode requested

Index | Next | Previous | View Threaded

jean.baptiste.favre at gmail

Sep 23, 2009, 2:07 PM

Post #1 of 8 (1520 views)
Permalink

Xen cluster, no migration when standby mode requested

Hello,
I'm still building a xen cluster managed by pacemaker/openais.
Things are quite close to be OK I think, execpt when I want to put a
node in standby mode:
When it happens, all XEN VM are shut down and restarted on the other node.
When I ask for ressource migration, XEN Live Migration does the job so
that no downtime occurs.

Is there any way to "slow down" standby mode so that XEN VM can migrate
gracefully ?

Bellow you can find my cluster configuration, if it can help.

Thanks,
JB

=======================================
node remus attributes standby="false"
node romulus attributes standby="false"
primitive Cluster-ocfs-DRBD ocf:linbit:drbd \
params drbd_resource="cluster-ocfs" \
operations $id="Cluster-ocfs-DRBD-operations" \
op monitor interval="20" role="Master" timeout="20" \
op monitor interval="30" role="Slave" timeout="20"
primitive Cluster-ocfs-FS ocf:heartbeat:Filesystem \
params device="/dev/drbd/by-res/cluster-ocfs" \
directory="/cluster" fstype="ocfs2"
primitive xps-101-DRBD ocf:linbit:drbd \
params drbd_resource="xps-101" \
operations $id="xps-101-DRBD-operations" \
op monitor interval="20" role="Master" timeout="20" \
op monitor interval="30" role="Slave" timeout="20"
primitive xps-101 ocf:heartbeat:Xen \
params xmfile="/cluster/xen/xps-101.cfg" allow_migrate="true" \
op monitor interval="10s" \
meta allow-migrate="true"
ms Cluster-ocfs-MS Cluster-ocfs-DRBD \
meta resource-stickines="100" master-max="2" notify="true" \
interleave="true"
ms xps-101-MS xps-101-DRBD \
meta resource-stickines="100" master-max="2" notify="true" \
interleave="true"
clone Cluster-ocfs-FSCL Cluster-ocfs-FS \
meta interleave="true" ordered="true"
colocation xps-101-Xen-DRBD inf: xps-101 xps-101-MS:Master
order Cluster-ocfs-AfterDRBD inf: Cluster-ocfs-MS:promote \
Cluster-ocfs-FSCL:start
order xps-101-AfterDRBD inf: xps-101-MS:promote xps-101:start
property $id="cib-bootstrap-options" \
dc-version="1.0.4-2ec1d189f9c23093bf9239a980534b661baf782d" \
cluster-infrastructure="openais" \
expected-quorum-votes="2" \
last-lrm-refresh="1253739607" \
node-health-red="0" \
stonith-enabled="false" \
no-quorum-policy="ignore"
_______________________________________________
Linux-HA mailing list
Linux-HA [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

tinzauro at ha-solutions

Sep 23, 2009, 3:55 PM

Post #2 of 8 (1477 views)
Permalink

Re: Xen cluster, no migration when standby mode requested [In reply to]

Jean Baptiste Favre wrote:
> Hello,
> I'm still building a xen cluster managed by pacemaker/openais.
> Things are quite close to be OK I think, execpt when I want to put a
> node in standby mode:
> When it happens, all XEN VM are shut down and restarted on the other node.
> When I ask for ressource migration, XEN Live Migration does the job so
> that no downtime occurs.
>
> Is there any way to "slow down" standby mode so that XEN VM can migrate
> gracefully ?
>
> Bellow you can find my cluster configuration, if it can help.
>
> Thanks,
> JB
>
> =======================================
> node remus attributes standby="false"
> node romulus attributes standby="false"
> primitive Cluster-ocfs-DRBD ocf:linbit:drbd \
> params drbd_resource="cluster-ocfs" \
> operations $id="Cluster-ocfs-DRBD-operations" \
> op monitor interval="20" role="Master" timeout="20" \
> op monitor interval="30" role="Slave" timeout="20"
> primitive Cluster-ocfs-FS ocf:heartbeat:Filesystem \
> params device="/dev/drbd/by-res/cluster-ocfs" \
> directory="/cluster" fstype="ocfs2"
> primitive xps-101-DRBD ocf:linbit:drbd \
> params drbd_resource="xps-101" \
> operations $id="xps-101-DRBD-operations" \
> op monitor interval="20" role="Master" timeout="20" \
> op monitor interval="30" role="Slave" timeout="20"
> primitive xps-101 ocf:heartbeat:Xen \
> params xmfile="/cluster/xen/xps-101.cfg" allow_migrate="true" \
> op monitor interval="10s" \
> meta allow-migrate="true"
> ms Cluster-ocfs-MS Cluster-ocfs-DRBD \
> meta resource-stickines="100" master-max="2" notify="true" \
> interleave="true"
> ms xps-101-MS xps-101-DRBD \
> meta resource-stickines="100" master-max="2" notify="true" \
> interleave="true"
> clone Cluster-ocfs-FSCL Cluster-ocfs-FS \
> meta interleave="true" ordered="true"
> colocation xps-101-Xen-DRBD inf: xps-101 xps-101-MS:Master
> order Cluster-ocfs-AfterDRBD inf: Cluster-ocfs-MS:promote \
> Cluster-ocfs-FSCL:start
> order xps-101-AfterDRBD inf: xps-101-MS:promote xps-101:start
> property $id="cib-bootstrap-options" \
> dc-version="1.0.4-2ec1d189f9c23093bf9239a980534b661baf782d" \
> cluster-infrastructure="openais" \
> expected-quorum-votes="2" \
> last-lrm-refresh="1253739607" \
> node-health-red="0" \
> stonith-enabled="false" \
> no-quorum-policy="ignore"

I'm not attempting to solve your issue, but I may be able to help simplify things a little (depending on which version of Xen
you are using).

You 'may' not have to manage the DRBD resource(s) yourself. Xen will take care of promotion/demotion of the DRBD resource.
To see if yours supports it, look for /etc/xen/scripts/block-drbd. Once you do so, you will not have a need to use
colocation and ordering ;) This was added to make what you are doing ALOT easier and more pragmatic.

DRBD note:
I believe you will have to "allow-two-primaries" for your resources in /etc/drbd.conf in order for live migration to work.

the relevant line in your xen_domu.cfg will look something like this(depending on your setup):

disk = ['drbd:xen_domU-disk,sda2,w','drbd:xen_domU-swap,sda1,w']

See the following for reference:
http://fghaas.wordpress.com/2007/09/03/drbd-806-brings-full-live-migration-for-xen-on-drbd/
http://www.drbd.org/users-guide/s-xen-configure-domu.html

best reagards,

_Terry

_______________________________________________
Linux-HA mailing list
Linux-HA [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

jean.baptiste.favre at gmail

Sep 23, 2009, 10:50 PM

Post #3 of 8 (1469 views)
Permalink

Re: Xen cluster, no migration when standby mode requested [In reply to]

Hello Terry,

Terry L. Inzauro a �crit :
> Jean Baptiste Favre wrote:
>> Hello,
>> I'm still building a xen cluster managed by pacemaker/openais.
>> Things are quite close to be OK I think, execpt when I want to put a
>> node in standby mode:
>> When it happens, all XEN VM are shut down and restarted on the other node.
>> When I ask for ressource migration, XEN Live Migration does the job so
>> that no downtime occurs.
>>
>> Is there any way to "slow down" standby mode so that XEN VM can migrate
>> gracefully ?
>>
>> Bellow you can find my cluster configuration, if it can help.
>>
>> Thanks,
>> JB
>>
>> =======================================
>> node remus attributes standby="false"
>> node romulus attributes standby="false"
>> primitive Cluster-ocfs-DRBD ocf:linbit:drbd \
>> params drbd_resource="cluster-ocfs" \
>> operations $id="Cluster-ocfs-DRBD-operations" \
>> op monitor interval="20" role="Master" timeout="20" \
>> op monitor interval="30" role="Slave" timeout="20"
>> primitive Cluster-ocfs-FS ocf:heartbeat:Filesystem \
>> params device="/dev/drbd/by-res/cluster-ocfs" \
>> directory="/cluster" fstype="ocfs2"
>> primitive xps-101-DRBD ocf:linbit:drbd \
>> params drbd_resource="xps-101" \
>> operations $id="xps-101-DRBD-operations" \
>> op monitor interval="20" role="Master" timeout="20" \
>> op monitor interval="30" role="Slave" timeout="20"
>> primitive xps-101 ocf:heartbeat:Xen \
>> params xmfile="/cluster/xen/xps-101.cfg" allow_migrate="true" \
>> op monitor interval="10s" \
>> meta allow-migrate="true"
>> ms Cluster-ocfs-MS Cluster-ocfs-DRBD \
>> meta resource-stickines="100" master-max="2" notify="true" \
>> interleave="true"
>> ms xps-101-MS xps-101-DRBD \
>> meta resource-stickines="100" master-max="2" notify="true" \
>> interleave="true"
>> clone Cluster-ocfs-FSCL Cluster-ocfs-FS \
>> meta interleave="true" ordered="true"
>> colocation xps-101-Xen-DRBD inf: xps-101 xps-101-MS:Master
>> order Cluster-ocfs-AfterDRBD inf: Cluster-ocfs-MS:promote \
>> Cluster-ocfs-FSCL:start
>> order xps-101-AfterDRBD inf: xps-101-MS:promote xps-101:start
>> property $id="cib-bootstrap-options" \
>> dc-version="1.0.4-2ec1d189f9c23093bf9239a980534b661baf782d" \
>> cluster-infrastructure="openais" \
>> expected-quorum-votes="2" \
>> last-lrm-refresh="1253739607" \
>> node-health-red="0" \
>> stonith-enabled="false" \
>> no-quorum-policy="ignore"
>
>
> I'm not attempting to solve your issue, but I may be able to help simplify things a little (depending on which version of Xen
> you are using).
> You 'may' not have to manage the DRBD resource(s) yourself. Xen will take care of promotion/demotion of the DRBD resource.
> To see if yours supports it, look for /etc/xen/scripts/block-drbd. Once you do so, you will not have a need to use
> colocation and ordering ;) This was added to make what you are doing ALOT easier and more pragmatic.
Yes I saw that, but DRBD documentation you mentionned notes:
"There are three sets of circumstances under which you cannot use this
"approach:
" * You are configuring a fully virtualized (HVM) domU.

And I use HVM domU :-(

> DRBD note:
> I believe you will have to "allow-two-primaries" for your resources in /etc/drbd.conf in order for live migration to work.
Dual primary is enabled. When I manually migrate a DomU ressource, it
gets live migrated. It's only when requesting a node to be put in
standby mode that they got shut down.
It seems that when a node switch to standby mode, all ressources on the
remaining node are restarted. Therefore, when DRBD resource is stopped,
domU is stopped as well because of colocation constraint.

Maybe a start_delay property could do the trick. I will try it today.

Regards,
JB

===============================
DRBD conf exerpt
===============================
global {
usage-count yes;
}

common {
syncer {
rate 33M;
}
protocol C;
}
resource cluster-ocfs {
meta-disk internal;
device /dev/drbd0;
disk {
fencing resource-only;
}
handlers {
fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
after-resync-target "/usr/lib/drbd/crm-unfence-peer.sh";
}
on remus {
disk /dev/XenHosting/cluster-ocfs;
address 192.168.0.1:7800;
}
on romulus {
disk /dev/XenHosting/cluster-ocfs;
address 192.168.0.0:7800;
}
net {
allow-two-primaries;
}
startup {
become-primary-on both;
}
}

resource xps-101 {
meta-disk internal;
device /dev/drbd1;
disk {
fencing resource-only;
}
handlers {
fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
after-resync-target "/usr/lib/drbd/crm-unfence-peer.sh";
}
on remus {
disk /dev/XenHosting/xps-101.sda.disk;
address 192.168.0.1:7801;
}
net {
allow-two-primaries;
}
startup {
become-primary-on both;
}
}
_______________________________________________
Linux-HA mailing list
Linux-HA [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

dejanmm at fastmail

Sep 24, 2009, 1:32 AM

Post #4 of 8 (1463 views)
Permalink

Re: Xen cluster, no migration when standby mode requested [In reply to]

Hi,

On Wed, Sep 23, 2009 at 11:07:27PM +0200, Jean Baptiste Favre wrote:
> Hello,
> I'm still building a xen cluster managed by pacemaker/openais.
> Things are quite close to be OK I think, execpt when I want to put a
> node in standby mode:
> When it happens, all XEN VM are shut down and restarted on the other node.
> When I ask for ressource migration, XEN Live Migration does the job so
> that no downtime occurs.
>
> Is there any way to "slow down" standby mode so that XEN VM can migrate
> gracefully ?

There are no special options for standby, but I think that it
should do migrate instead of stop/start if migrate is allowed.
Did you see anything suspicious in the logs? If not, then you
should open a bugzilla.

Thanks,

Dejan

> Bellow you can find my cluster configuration, if it can help.
>
> Thanks,
> JB
>
> =======================================
> node remus attributes standby="false"
> node romulus attributes standby="false"
> primitive Cluster-ocfs-DRBD ocf:linbit:drbd \
> params drbd_resource="cluster-ocfs" \
> operations $id="Cluster-ocfs-DRBD-operations" \
> op monitor interval="20" role="Master" timeout="20" \
> op monitor interval="30" role="Slave" timeout="20"
> primitive Cluster-ocfs-FS ocf:heartbeat:Filesystem \
> params device="/dev/drbd/by-res/cluster-ocfs" \
> directory="/cluster" fstype="ocfs2"
> primitive xps-101-DRBD ocf:linbit:drbd \
> params drbd_resource="xps-101" \
> operations $id="xps-101-DRBD-operations" \
> op monitor interval="20" role="Master" timeout="20" \
> op monitor interval="30" role="Slave" timeout="20"
> primitive xps-101 ocf:heartbeat:Xen \
> params xmfile="/cluster/xen/xps-101.cfg" allow_migrate="true" \
> op monitor interval="10s" \
> meta allow-migrate="true"
> ms Cluster-ocfs-MS Cluster-ocfs-DRBD \
> meta resource-stickines="100" master-max="2" notify="true" \
> interleave="true"
> ms xps-101-MS xps-101-DRBD \
> meta resource-stickines="100" master-max="2" notify="true" \
> interleave="true"
> clone Cluster-ocfs-FSCL Cluster-ocfs-FS \
> meta interleave="true" ordered="true"
> colocation xps-101-Xen-DRBD inf: xps-101 xps-101-MS:Master
> order Cluster-ocfs-AfterDRBD inf: Cluster-ocfs-MS:promote \
> Cluster-ocfs-FSCL:start
> order xps-101-AfterDRBD inf: xps-101-MS:promote xps-101:start
> property $id="cib-bootstrap-options" \
> dc-version="1.0.4-2ec1d189f9c23093bf9239a980534b661baf782d" \
> cluster-infrastructure="openais" \
> expected-quorum-votes="2" \
> last-lrm-refresh="1253739607" \
> node-health-red="0" \
> stonith-enabled="false" \
> no-quorum-policy="ignore"
> _______________________________________________
> Linux-HA mailing list
> Linux-HA [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
_______________________________________________
Linux-HA mailing list
Linux-HA [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

jean.baptiste.favre at gmail

Sep 24, 2009, 5:04 AM

Post #5 of 8 (1464 views)
Permalink

Re: Xen cluster, no migration when standby mode requested [In reply to]

Hello,
Absolutely no logs from openais found even in debug mode which looks
strange (my configuration bellow).

Some interesting logs from Xend:

[2009-09-24 13:49:47 3710] DEBUG (XendDomainInfo:467)
XendDomainInfo.shutdown(poweroff)
[2009-09-24 13:49:47 3710] DEBUG (XendDomainInfo:1092)
XendDomainInfo.handleShutdownWatch
[2009-09-24 13:49:47 3710] INFO (XendDomainInfo:485) HVM save:remote
shutdown dom 36!
[2009-09-24 13:49:47 3710] INFO (XendDomainInfo:1283) Domain has
shutdown: name=xps-102 id=36 reason=poweroff.

It seems that Pacemaker request for resource poweroff instead of
migration as allowed in resource configuration.
Saying that, it seems that allow_migrate syntax has changed: in GUI the
only choice I have is allow_migrate as instance attribute.
And after tests, I saw it must be "allow-migrate" as meta attribute for
xen live migration to work.
That may explain what happens.

So, is my configuration suitable to open a bug, or have I made a mistake?

Regards,
JB

===============================================
Openais logging configuration:
logging {
debug: on
timestamp: on
to_file: yes
logfile: /home/openais.log
}

Xen resource config:
primitive xps-102 ocf:heartbeat:Xen \
params xmfile="/cluster/xen/xps-102.cfg" allow_migrate="true" \
op monitor interval="10s" \
meta allow-migrate="true" resource-stickiness="0"

Dejan Muhamedagic a �crit :
> Hi,
>
> On Wed, Sep 23, 2009 at 11:07:27PM +0200, Jean Baptiste Favre wrote:
>> Hello,
>> I'm still building a xen cluster managed by pacemaker/openais.
>> Things are quite close to be OK I think, execpt when I want to put a
>> node in standby mode:
>> When it happens, all XEN VM are shut down and restarted on the other node.
>> When I ask for ressource migration, XEN Live Migration does the job so
>> that no downtime occurs.
>>
>> Is there any way to "slow down" standby mode so that XEN VM can migrate
>> gracefully ?
>
> There are no special options for standby, but I think that it
> should do migrate instead of stop/start if migrate is allowed.
> Did you see anything suspicious in the logs? If not, then you
> should open a bugzilla.
>
> Thanks,
>
> Dejan
>
>> Bellow you can find my cluster configuration, if it can help.
>>
>> Thanks,
>> JB
>>
>> =======================================
>> node remus attributes standby="false"
>> node romulus attributes standby="false"
>> primitive Cluster-ocfs-DRBD ocf:linbit:drbd \
>> params drbd_resource="cluster-ocfs" \
>> operations $id="Cluster-ocfs-DRBD-operations" \
>> op monitor interval="20" role="Master" timeout="20" \
>> op monitor interval="30" role="Slave" timeout="20"
>> primitive Cluster-ocfs-FS ocf:heartbeat:Filesystem \
>> params device="/dev/drbd/by-res/cluster-ocfs" \
>> directory="/cluster" fstype="ocfs2"
>> primitive xps-101-DRBD ocf:linbit:drbd \
>> params drbd_resource="xps-101" \
>> operations $id="xps-101-DRBD-operations" \
>> op monitor interval="20" role="Master" timeout="20" \
>> op monitor interval="30" role="Slave" timeout="20"
>> primitive xps-101 ocf:heartbeat:Xen \
>> params xmfile="/cluster/xen/xps-101.cfg" allow_migrate="true" \
>> op monitor interval="10s" \
>> meta allow-migrate="true"
>> ms Cluster-ocfs-MS Cluster-ocfs-DRBD \
>> meta resource-stickines="100" master-max="2" notify="true" \
>> interleave="true"
>> ms xps-101-MS xps-101-DRBD \
>> meta resource-stickines="100" master-max="2" notify="true" \
>> interleave="true"
>> clone Cluster-ocfs-FSCL Cluster-ocfs-FS \
>> meta interleave="true" ordered="true"
>> colocation xps-101-Xen-DRBD inf: xps-101 xps-101-MS:Master
>> order Cluster-ocfs-AfterDRBD inf: Cluster-ocfs-MS:promote \
>> Cluster-ocfs-FSCL:start
>> order xps-101-AfterDRBD inf: xps-101-MS:promote xps-101:start
>> property $id="cib-bootstrap-options" \
>> dc-version="1.0.4-2ec1d189f9c23093bf9239a980534b661baf782d" \
>> cluster-infrastructure="openais" \
>> expected-quorum-votes="2" \
>> last-lrm-refresh="1253739607" \
>> node-health-red="0" \
>> stonith-enabled="false" \
>> no-quorum-policy="ignore"
>> _______________________________________________
>> Linux-HA mailing list
>> Linux-HA [at] lists
>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>> See also: http://linux-ha.org/ReportingProblems

_______________________________________________
Linux-HA mailing list
Linux-HA [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

dejanmm at fastmail

Sep 24, 2009, 7:00 AM

Post #6 of 8 (1458 views)
Permalink

Re: Xen cluster, no migration when standby mode requested [In reply to]

Hi,

On Thu, Sep 24, 2009 at 02:04:06PM +0200, Jean Baptiste Favre wrote:
> Hello,
> Absolutely no logs from openais found even in debug mode which looks
> strange (my configuration bellow).
>
> Some interesting logs from Xend:
>
> [2009-09-24 13:49:47 3710] DEBUG (XendDomainInfo:467)
> XendDomainInfo.shutdown(poweroff)
> [2009-09-24 13:49:47 3710] DEBUG (XendDomainInfo:1092)
> XendDomainInfo.handleShutdownWatch
> [2009-09-24 13:49:47 3710] INFO (XendDomainInfo:485) HVM save:remote
> shutdown dom 36!
> [2009-09-24 13:49:47 3710] INFO (XendDomainInfo:1283) Domain has
> shutdown: name=xps-102 id=36 reason=poweroff.
>
> It seems that Pacemaker request for resource poweroff instead of
> migration as allowed in resource configuration.
> Saying that, it seems that allow_migrate syntax has changed: in GUI the
> only choice I have is allow_migrate as instance attribute.

Right, but that parameter seems to be noop. No idea why it's
there.

> And after tests, I saw it must be "allow-migrate" as meta attribute for
> xen live migration to work.

Yes. Well, I thought you said that live migration worked on
resource migrate but not on node standby. Wasn't that the case?

Thanks,

Dejan

> That may explain what happens.
>
> So, is my configuration suitable to open a bug, or have I made a mistake?
>
> Regards,
> JB
>
> ===============================================
> Openais logging configuration:
> logging {
> debug: on
> timestamp: on
> to_file: yes
> logfile: /home/openais.log
> }
>
> Xen resource config:
> primitive xps-102 ocf:heartbeat:Xen \
> params xmfile="/cluster/xen/xps-102.cfg" allow_migrate="true" \
> op monitor interval="10s" \
> meta allow-migrate="true" resource-stickiness="0"
>
> Dejan Muhamedagic a �crit :
> > Hi,
> >
> > On Wed, Sep 23, 2009 at 11:07:27PM +0200, Jean Baptiste Favre wrote:
> >> Hello,
> >> I'm still building a xen cluster managed by pacemaker/openais.
> >> Things are quite close to be OK I think, execpt when I want to put a
> >> node in standby mode:
> >> When it happens, all XEN VM are shut down and restarted on the other node.
> >> When I ask for ressource migration, XEN Live Migration does the job so
> >> that no downtime occurs.
> >>
> >> Is there any way to "slow down" standby mode so that XEN VM can migrate
> >> gracefully ?
> >
> > There are no special options for standby, but I think that it
> > should do migrate instead of stop/start if migrate is allowed.
> > Did you see anything suspicious in the logs? If not, then you
> > should open a bugzilla.
> >
> > Thanks,
> >
> > Dejan
> >
> >> Bellow you can find my cluster configuration, if it can help.
> >>
> >> Thanks,
> >> JB
> >>
> >> =======================================
> >> node remus attributes standby="false"
> >> node romulus attributes standby="false"
> >> primitive Cluster-ocfs-DRBD ocf:linbit:drbd \
> >> params drbd_resource="cluster-ocfs" \
> >> operations $id="Cluster-ocfs-DRBD-operations" \
> >> op monitor interval="20" role="Master" timeout="20" \
> >> op monitor interval="30" role="Slave" timeout="20"
> >> primitive Cluster-ocfs-FS ocf:heartbeat:Filesystem \
> >> params device="/dev/drbd/by-res/cluster-ocfs" \
> >> directory="/cluster" fstype="ocfs2"
> >> primitive xps-101-DRBD ocf:linbit:drbd \
> >> params drbd_resource="xps-101" \
> >> operations $id="xps-101-DRBD-operations" \
> >> op monitor interval="20" role="Master" timeout="20" \
> >> op monitor interval="30" role="Slave" timeout="20"
> >> primitive xps-101 ocf:heartbeat:Xen \
> >> params xmfile="/cluster/xen/xps-101.cfg" allow_migrate="true" \
> >> op monitor interval="10s" \
> >> meta allow-migrate="true"
> >> ms Cluster-ocfs-MS Cluster-ocfs-DRBD \
> >> meta resource-stickines="100" master-max="2" notify="true" \
> >> interleave="true"
> >> ms xps-101-MS xps-101-DRBD \
> >> meta resource-stickines="100" master-max="2" notify="true" \
> >> interleave="true"
> >> clone Cluster-ocfs-FSCL Cluster-ocfs-FS \
> >> meta interleave="true" ordered="true"
> >> colocation xps-101-Xen-DRBD inf: xps-101 xps-101-MS:Master
> >> order Cluster-ocfs-AfterDRBD inf: Cluster-ocfs-MS:promote \
> >> Cluster-ocfs-FSCL:start
> >> order xps-101-AfterDRBD inf: xps-101-MS:promote xps-101:start
> >> property $id="cib-bootstrap-options" \
> >> dc-version="1.0.4-2ec1d189f9c23093bf9239a980534b661baf782d" \
> >> cluster-infrastructure="openais" \
> >> expected-quorum-votes="2" \
> >> last-lrm-refresh="1253739607" \
> >> node-health-red="0" \
> >> stonith-enabled="false" \
> >> no-quorum-policy="ignore"
> >> _______________________________________________
> >> Linux-HA mailing list
> >> Linux-HA [at] lists
> >> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> >> See also: http://linux-ha.org/ReportingProblems
>
> _______________________________________________
> Linux-HA mailing list
> Linux-HA [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
_______________________________________________
Linux-HA mailing list
Linux-HA [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

jean.baptiste.favre at gmail

Sep 24, 2009, 7:10 AM

Post #7 of 8 (1463 views)
Permalink

Re: Xen cluster, no migration when standby mode requested [In reply to]

Hi,

Dejan Muhamedagic a �crit :
> Hi,
>
> On Thu, Sep 24, 2009 at 02:04:06PM +0200, Jean Baptiste Favre wrote:
>> Hello,
>> Absolutely no logs from openais found even in debug mode which looks
>> strange (my configuration bellow).
>>
>> Some interesting logs from Xend:
>>
>> [2009-09-24 13:49:47 3710] DEBUG (XendDomainInfo:467)
>> XendDomainInfo.shutdown(poweroff)
>> [2009-09-24 13:49:47 3710] DEBUG (XendDomainInfo:1092)
>> XendDomainInfo.handleShutdownWatch
>> [2009-09-24 13:49:47 3710] INFO (XendDomainInfo:485) HVM save:remote
>> shutdown dom 36!
>> [2009-09-24 13:49:47 3710] INFO (XendDomainInfo:1283) Domain has
>> shutdown: name=xps-102 id=36 reason=poweroff.
>>
>> It seems that Pacemaker request for resource poweroff instead of
>> migration as allowed in resource configuration.
>> Saying that, it seems that allow_migrate syntax has changed: in GUI the
>> only choice I have is allow_migrate as instance attribute.
>
> Right, but that parameter seems to be noop. No idea why it's
> there.
>
>> And after tests, I saw it must be "allow-migrate" as meta attribute for
>> xen live migration to work.
>
> Yes. Well, I thought you said that live migration worked on
> resource migrate but not on node standby. Wasn't that the case?

Yes, it's the case:
Live migration works on resource migrate with "famous" parameter
"allow-migrate" as meta attribute, not without.
On node standby, even with this parameters, DomU ressource is shut down,
not migrated.

Regards,
JB
_______________________________________________
Linux-HA mailing list
Linux-HA [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

andrew at beekhof

Oct 6, 2009, 7:48 AM

Post #8 of 8 (1303 views)
Permalink

Re: Xen cluster, no migration when standby mode requested [In reply to]

On Thu, Sep 24, 2009 at 4:10 PM, Jean Baptiste Favre
<jean.baptiste.favre [at] gmail> wrote:
> Hi,
>
> Dejan Muhamedagic a �crit :

>> Yes. Well, I thought you said that live migration worked on
>> resource migrate but not on node standby. Wasn't that the case?
>
> Yes, it's the case:
> Live migration works on resource migrate with "famous" parameter
> "allow-migrate" as meta attribute, not without.
> On node standby, even with this parameters, DomU ressource is shut down,
> not migrated.

You might want to try 1.0.5, I made some improvements to migration
between 1.0.4 and 1.0.5.
_______________________________________________
Linux-HA mailing list
Linux-HA [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads