Hi Herbert, thanks for clearing things up. It just felt to be the right way to implement the failover inside the guest, so you can fail the guest over to a different host system with out having to take care of things on the host system. Yes, kernel and tools are indeed a bit outdated, but that's how it sometimes goes on a production host, with only a few downtimes possible. All the best, Michael Am 23.11.2010 14:44, schrieb Herbert Poetzl: > On Tue, Nov 23, 2010 at 11:38:55AM +0100, Michael Rennt wrote: >> Hello everyone, > >> I'm trying to implement IP failover from inside a vServer >> with keepalived. > > just don't do it, unless you are using network namespaces > >> So keepalived inside the vserver needs to add and remove >> ip addresses by itself, without having to restart the vserver. > > adding and removing IPs from a guest can be done at runtime > but only from the admin context (i.e. host) > >> With CAP_NET_ADMIN and CAP_NET_RAW keepalived seems to work > > emphasis on _seems_ ... > >> fine from inside the vserver, but the assigned ip addresses >> are not bound to the vserver itself, but to the host system. > > all IPs are assigned on the host system, the guests are > just given a subset to bind to ... > >> They also only show up on the host system. > > naturally, as the guest's IP subset has not been modified > >> Is there another cap that allows keepalived to bind an >> ip inside the vserver? > > you need to use naddress to assign IPs to guests > >> (vserver-tools 0.30.216-pre2772 / Kernel 2.6.29.2-vs2.3.0.36.10) > > outdated kernel, outdated tools .... > >> Any hints would be highly appreciated. > > failover should be implemented on the host, as it is > the proper place to add/remove IPs and assign those > IPs to guest subsystems without compromising security > > best, > Herbert > >> Thanks in advance. > >> All the best, > >> Michael >