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, so it should work
with pacemaker.
I doubt
On 30.03.2021 18:16, Lentes, Bernd wrote:
> Hi,
>
> currently i'm reading "Mastering KVM Virtualization", published by Packt
> Publishing, a book i can really recommend.
> There are some proposals for tuning guests. One is KSM (kernel samepage
> merging), which sounds quite interesting.
>
On 30.03.2021 17:42, Ken Gaillot wrote:
>>
>> Colocation does not work, this will force everything on the same node
>> where master is active and that is not what we want.
>
> Nope, you can colocate by node attribute instead of node.
>
> Colocating by node attribute says "put this resource on a
Hi Reid,
in order the colocation to work , it should (logically) look like
pcs constraint colocation add BKP_IP1 with Master
rsc_SAPHana__HDB-clone INFINITY node-attribute=$(attribute
SITE on Master rsc_SAPHana__HDB-clone)
So far , I have created a bash script to:- detect global maintenance and
Hi,
currently i'm reading "Mastering KVM Virtualization", published by Packt
Publishing, a book i can really recommend.
There are some proposals for tuning guests. One is KSM (kernel samepage
merging), which sounds quite interesting.
Especially in a system with lots of virtual machines with the
On Tue, 2021-03-30 at 08:01 +0300, Andrei Borzenkov wrote:
> On 29.03.2021 20:12, Ken Gaillot wrote:
> > On Sun, 2021-03-28 at 09:20 +0300, Andrei Borzenkov wrote:
> > > On 28.03.2021 07:16, Strahil Nikolov wrote:
> > > > I didn't mean DC as a designated coordinator, but as a physical
> > > >
On Tue, 2021-03-30 at 08:26 +0200, Ulrich Windl wrote:
> > > > Ken Gaillot schrieb am 29.03.2021 um
> > > > 19:23 in
>
> Nachricht
> :
> > Scores are in the range ‑1,000,000 to +1,000,000 (also known as
> > "infinity").
> >
> > Numerically higher scores are preferred in whatever the context is
On Tue, 2021-03-30 at 12:05 +, Strahil Nikolov wrote:
> Hi Reid,
>
> in order the colocation to work , it should (logically) look like
>
> pcs constraint colocation add BKP_IP1 with Master
> rsc_SAPHana__HDB-clone INFINITY node-
> attribute=$(attribute SITE on
> Master
>>> Klaus Wenninger schrieb am 30.03.2021 um 07:32 in
Nachricht <9541d96d-be98-15e4-a8eb-966d2ee0f...@redhat.com>:
> On 3/29/21 8:44 AM, d tbsky wrote:
>> Reid Wahl
>>> An order constraint set with kind=Serialize (which is mentioned in the
first
> reply to the thread you linked) seems like the
Hi Ken, can you provide a prototype code example.
Currently,I'm making a script that will be used in a systemd service managed by
the cluster.Yet, I would like to avoid non-pacemaker solutions.
Best Regards,Strahil Nikolov
On Mon, Mar 29, 2021 at 20:12, Ken Gaillot wrote: On
Sun,
You can try the following and see if it works, replacing the items in angle
brackets (<>).
# pcs constraint colocation add with Master
INFINITY node-attribute=hana__site
However, `pcs constraint colocation add --help` gives no information about
what options it accepts. It just says
On Mon, Mar 29, 2021 at 10:32 PM Klaus Wenninger
wrote:
> On 3/29/21 8:44 AM, d tbsky wrote:
> > Reid Wahl
> >> An order constraint set with kind=Serialize (which is mentioned in the
> first reply to the thread you linked) seems like the most logical option to
> me. You could serialize a set of
>>> Ken Gaillot schrieb am 29.03.2021 um 19:23 in
Nachricht
:
> Scores are in the range ‑1,000,000 to +1,000,000 (also known as
> "infinity").
>
> Numerically higher scores are preferred in whatever the context is
> (e.g. higher stickiness means more sticky, higher colocation score
> means more
>>> Ken Gaillot schrieb am 29.03.2021 um 19:08 in
>>> Nachricht
<02771561b0dc2980b87191ad72306bfd9fa27cd3.ca...@redhat.com>:
...
>> What about listing allowable exit codes with each action?
>
> I think for the purposes of the standard, any action can return any of
> the specified error codes
>>> Andrei Borzenkov schrieb am 29.03.2021 um 18:02 in
Nachricht <4e638e03-936e-40c9-3f4e-8e641a5ed...@gmail.com>:
> On 29.03.2021 11:11, Ulrich Windl wrote:
> Andrei Borzenkov schrieb am 27.03.2021 um 06:37
in
>> Nachricht <7c294034-56c3-baab-73c6-7909ab554...@gmail.com>:
>>> On 26.03.2021
15 matches
Mail list logo
