Re: [ClusterLabs] Antw: [EXT] Re: cluster-recheck-interval and failure-timeout

2021-04-06 Thread Ken Gaillot
On Tue, 2021-04-06 at 09:15 +0200, Ulrich Windl wrote: > > > > Ken Gaillot schrieb am 31.03.2021 um > > > > 15:48 in > > Nachricht > <7dfc7c46442db17d9645854081f1269261518f84.ca...@redhat.com>: > > On Wed, 2021‑03‑31 at 14:32 +0200, Antony Stone wrote: > > > Hi. > > > > > > I'm trying to

[ClusterLabs] Antw: Re: Antw: [EXT] staggered resource start/stop

2021-04-06 Thread Ulrich Windl
>>> Klaus Wenninger schrieb am 06.04.2021 um 14:38 in Nachricht <8dc001d0-c3ed-d9d1-ea91-3a7ebd83b...@redhat.com>: > On 3/29/21 12:47 PM, Reid Wahl wrote: >> >> >> On Mon, Mar 29, 2021 at 3:35 AM Ulrich Windl >> > > wrote: >> >> >>> d tbsky

Re: [ClusterLabs] Antw: [EXT] staggered resource start/stop

2021-04-06 Thread Klaus Wenninger
On 3/29/21 12:47 PM, Reid Wahl wrote: On Mon, Mar 29, 2021 at 3:35 AM Ulrich Windl > wrote: >>> d tbsky mailto:tbs...@gmail.com>> schrieb am 29.03.2021 um 04:01 in Nachricht mailto:t_moml5ecx8ay3gtcfgmofkd...@mail.gmail.com>>: > Hi:

Re: [ClusterLabs] Antw: [EXT] Corosync 3.1.1 is available at corosync.org!

2021-04-06 Thread Jan Friesse
Ulrich, Jan Friesse schrieb am 31.03.2021 um 15:16 in Nachricht <8f611847-e341-b51b-49c9-fd9ef29fb...@redhat.com>: I am pleased to announce the latest maintenance release of Corosync 3.1.1 available immediately from GitHub release section at https://github.com/corosync/corosync/releases or

[ClusterLabs] Corosync 3.1.2 is available at corosync.org!

2021-04-06 Thread Jan Friesse
I am pleased to announce the latest maintenance release of Corosync 3.1.2 available immediately from GitHub release section at https://github.com/corosync/corosync/releases or our website at http://build.clusterlabs.org/corosync/releases/. This release contains only one (but very important)

[ClusterLabs] Antw: [EXT] Re: Live migration possible with KSM ?

2021-04-06 Thread Ulrich Windl
>>> Klaus Wenninger schrieb am 06.04.2021 um 09:28 in Nachricht <59526b01-e3cb-737d-9357-26e4ff46d...@redhat.com>: > On 3/30/21 7:54 PM, Strahil Nikolov wrote: >> Keep in mind that KSM is highly cpu intensive and is most suitable for >> same type of VMs,so similar memory pages will be merged

Re: [ClusterLabs] "iscsi.service: Unit cannot be reloaded because it is inactive."

2021-04-06 Thread Strahil Nikolov
Unless you clusterize your iSCSI.You can see  https://forums.centos.org/viewtopic.php?t=65539 Keep in mind that you will need to setup another resource to block the iscsi port before and after the iscsi resources or your clients will get a I/O error. Sadly I didn't have the time to refine it

[ClusterLabs] Antw: [EXT] "iscsi.service: Unit cannot be reloaded because it is inactive."

2021-04-06 Thread Ulrich Windl
Hi! This is not a cluster question as your iSCSI node has no cluster running. Maybe try "systemctl cat iscsi" to find out details of your unit. Regards, Ulrich >>> Jason Long schrieb am 03.04.2021 um 16:35 in Nachricht <1820840624.1977394.1617460554...@mail.yahoo.com>: > Hello, > I configure

Re: [ClusterLabs] Antw: [EXT] Re: Live migration possible with KSM ?

2021-04-06 Thread Klaus Wenninger
On 4/6/21 9:34 AM, Ulrich Windl wrote: "Lentes, Bernd" schrieb am 31.03.2021 um 15:58 in Nachricht <537587707.120787942.1617199127012.javamail.zim...@helmholtz-muenchen.de>: - On Mar 30, 2021, at 7:54 PM, hunter86 bg hunter86...@yahoo.com wrote: Keep in mind that KSM is highly cpu

Re: [ClusterLabs] staggered resource start/stop

2021-04-06 Thread Klaus Wenninger
On 4/6/21 10:23 AM, d tbsky wrote: Klaus Wenninger Guess that heavily depends on what you are running inside your VMs. If the services inside don't need each other or anything provided by the other cluster-resources (or other way round) or everything is synchronizing independently from the

Re: [ClusterLabs] staggered resource start/stop

2021-04-06 Thread d tbsky
Klaus Wenninger > Guess that heavily depends on what you are running inside your VMs. > If the services inside don't need each other or anything provided by > the other cluster-resources (or other way round) or everything is > synchronizing independently from the cluster ... > What you could

[ClusterLabs] Antw: [EXT] Re: Live migration possible with KSM ?

2021-04-06 Thread Ulrich Windl
>>> "Lentes, Bernd" schrieb am 31.03.2021 >>> um 15:58 in Nachricht <537587707.120787942.1617199127012.javamail.zim...@helmholtz-muenchen.de>: > > - On Mar 30, 2021, at 7:54 PM, hunter86 bg hunter86...@yahoo.com wrote: > >> Keep in mind that KSM is highly cpu intensive and is most

[ClusterLabs] Antw: [EXT] Corosync 3.1.1 is available at corosync.org!

2021-04-06 Thread Ulrich Windl
>>> Jan Friesse schrieb am 31.03.2021 um 15:16 in Nachricht <8f611847-e341-b51b-49c9-fd9ef29fb...@redhat.com>: > I am pleased to announce the latest maintenance release of Corosync > 3.1.1 available immediately from GitHub release section at > https://github.com/corosync/corosync/releases or our

Re: [ClusterLabs] Live migration possible with KSM ?

2021-04-06 Thread Klaus Wenninger
On 3/30/21 7:54 PM, Strahil Nikolov wrote: Keep in mind that KSM is highly cpu intensive and is most suitable for same type of VMs,so similar memory pages will be merged until a change happen (and that change is allocated elsewhere). In oVirt migration is possible with KSM actively working,

[ClusterLabs] Antw: [EXT] Re: cluster-recheck-interval and failure-timeout

2021-04-06 Thread Ulrich Windl
Hi Anthony, are you sure you are not mixing the two: fail-counts sticky resource failures I mean once the fail-count did exceed, you get a sticky resource constraint (a candidate for "cleanup"). Even if the fail-count is reset after that, the constraints will still be there. Regards, Ulrich

[ClusterLabs] Antw: [EXT] Re: cluster-recheck-interval and failure-timeout

2021-04-06 Thread Ulrich Windl
>>> Ken Gaillot schrieb am 31.03.2021 um 15:48 in Nachricht <7dfc7c46442db17d9645854081f1269261518f84.ca...@redhat.com>: > On Wed, 2021‑03‑31 at 14:32 +0200, Antony Stone wrote: >> Hi. >> >> I'm trying to understand what looks to me like incorrect behaviour >> between >>