Question: Virtual IP for HA (patroni postgres for example)

jochumdev · June 24, 2026, 9:24am

I’m looking for a way to move IP’s between containers and/or VM’s.

OVN commands are untested

The easy way I found is OVN:

incus network load-balancer backend remove ovn0 10.0.0.100 postgres-primary
incus network load-balancer backend add ovn0 10.0.0.100 postgres-secondary

The hard way I found that doesn’t require: OVN:

I think OVN is hard to setup - please tell me I’m wrong, so I think about another way for new users to have a VIP.

Create a bridge for that VIP and move the interface around:

incus network create incusbr-vip ipv4.address=10.0.0.1/24 ipv6.address=none
incus config device add postgres-primary eth1 nic \
        network=incusbr-vip \
        hwaddr=aa:bb:cc:dd:ee:ff \
        ipv4.address=10.0.0.100

To move it around

incus config device remove postgres-primary vip-nic
incus config device add postgres-secondary eth1 nic \
        network=incusbr-vip \
        hwaddr=aa:bb:cc:dd:ee:ff \
        ipv4.address=10.0.0.100

DOESNT WORK: The new hot plugged interface doesn’t get an IP.

This will be NATed source will be the IP incusbr-vip see: How best to disable NAT between incus managed networks

The question

Do you think the bridge part is possible and has no quirks? Would you prefer OVN only for that?

The possible patroni part

1.) We need a way to contact incus - my ic-healthd from incus-compose could do that.

github.com/lxc/incus-compose

docs/healthd.md

main

# Health Checking (ic-healthd)

incus-compose implements health checks via a sidecar container called `ic-healthd`.
Incus has no native healthcheck support, so ic-healthd fills that role.

> **ic-healthd is a core component.** Every `healthcheck`, every restart policy
> (`restart: always | on-failure | unless-stopped`), and every
> `depends_on: { condition: service_healthy }` is enforced by this sidecar, not by
> Incus. If healthd is misconfigured, stopped, or crashing:
>
> - instances are not restarted, and
> - **the project may fail to come up at all**: `incus-compose up` waits for
>   `service_healthy` dependencies to be reported healthy by healthd. If that
>   status never arrives, `up` blocks until `--dependency-timeout` (default 5m;
>   `0` waits forever) and then fails.
>
> Opt out of healthd entirely with `incus-compose up --no-healthd` (this also
> drops the dependency wait); `--no-deps` skips the wait too. When health,
> restart, or startup-ordering behavior looks wrong, debug healthd first (see
> [Debugging ic-healthd](#debugging-ic-healthd)).

This file has been truncated. show original

It already has everything needed to talk to incus, adding an token authenticated API for a VIP switch (and other stuff) is easy.

2.) In patroni you can define a script.

postgresql:
  callbacks:
    on_role_change: /scripts/switch-vip.sh

3.) That script would take a token and Healthd address from ENV and then ask healthd to switch the VIP.

jochumdev · June 24, 2026, 10:01am

I’ve tried the bridge based switching - it isn’t working as the container doesn’t get the IP (but the interface).

candlerb · June 24, 2026, 12:37pm

On a bridge network, you don’t need incus to take part in this; the container can add an additional IP alias by itself. For example, I run keepalived to manage a virtual IP address (VRRP) which moves between two front-end containers.

jochumdev · June 24, 2026, 12:42pm

Ye but not when you run docker-like containers, question is if people need that functionality on incus.

candlerb · June 24, 2026, 12:56pm

OK (although there was no mention of docker or OCI).

The Kubernetes Way would be to have a “service” on an IP, which proxies through to one or more backend IPs. Something like haproxy in its own container could do that.