Bug 237377 - in ha cluster VIP can't be out of server's IP address range
in ha cluster VIP can't be out of server's IP address range
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: rgmanager (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Lon Hohberger
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-21 12:31 EDT by Jean-Pierre Joerg
Modified: 2009-04-16 16:22 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-31 14:29:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Allows you to specify " (4.90 KB, text/x-patch)
2007-04-26 11:59 EDT, Lon Hohberger
no flags Details
Allows you to specify "ethernet_device" in cluster.conf (4.90 KB, patch)
2007-04-26 11:59 EDT, Lon Hohberger
no flags Details | Diff

  None (edit)
Description Jean-Pierre Joerg 2007-04-21 12:31:54 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.0.10) Gecko/20070221 Red Hat/1.5.0.10-0.1.el4 Firefox/1.5.0.10

Description of problem:
in HA cluster it is not possible to set a public VIP on servers having private addresses. The VIP should be in same class as the network your servers are configured in.
ex: your 2 servers HA cluster is built on network 10.90.20.0
Server A has address 10.90.20.1
Server B has address 10.90.20.2
You want to have a service offering the virtual IP 213.130.20.110/25 
It doesn't work if you use the IP service 
It doesn't work if you use a script doing the job

Version-Release number of selected component (if applicable):
cman-1.0.11-0

How reproducible:
Always


Steps to Reproduce:
1. A two servers HA cluster is built on network 10.90.20.0
Server A has address 10.90.20.1
Server B has address 10.90.20.2
You want to have a service offering the virtual IP 213.130.20.110/25 

2.It doesn't work if you use the IP service 
3.It doesn't work if you use a script doing the job

Actual Results:
nothing

Expected Results:
expected address set

Additional info:
As you must be in the same class as your HA servers it is not possible to set the netmask of the VIP.
It's important to have a way to set it if this problem is solved.
Comment 1 Jean-Pierre Joerg 2007-04-21 13:16:14 EDT
Oops, it seems t work with a script
Comment 2 Lon Hohberger 2007-04-26 11:59:40 EDT
Created attachment 153527 [details]
Allows you to specify "
Comment 3 Lon Hohberger 2007-04-26 11:59:49 EDT
Created attachment 153528 [details]
Allows you to specify "ethernet_device" in cluster.conf
Comment 4 Lon Hohberger 2007-04-26 12:07:25 EDT
Patch notes:

(1) The patch will bring up interfaces if they were previously down, but not
vice-versa
(2) The patch was tested with an eth1 device.

Doing anything more than the patch above will move routing configuration to
rgmanager, which is a bad idea.


Comment 5 Lon Hohberger 2007-05-16 17:27:15 EDT
After talking with Fabio, we need:

* a placement policy
  * subnet (default).  Like we use now.  Requires an IP in the same subnet
    as the VIP
  * manual.  Require ethernet_device (like the patch provides)
  * [future] auto intelligent placement / first ethernet device that's up,
    non-slave, etc.; maybe default router
* ethernet device specification (already in patch)
  
Comment 6 Lon Hohberger 2007-05-16 17:29:19 EDT
[17:18:57] <fabbione> May 03 17:37:09 <lon>   placement = subnet (default)
[17:18:57] <fabbione> May 03 17:37:10 *       fabbione needs to think
[17:18:57] <fabbione> May 03 17:37:12 <lon>   placement = auto
[17:18:57] <fabbione> May 03 17:37:19 <lon>   placement = manual (specify
ethernet_device)
[17:19:04] <lon> right
[17:19:08] <lon> auto = first eth device
[17:19:15] <fabbione> May 03 17:38:11 <fabbione>      no placement we keep the
same behaviour as now
[17:19:20] <fabbione> May 03 17:38:23 <fabbione>      placement = auto (first up
iface != lo)
[17:19:23] <lon> how ugh-lee.
[17:19:29] <fabbione> May 03 17:38:35 <lon>   fabbione, right, "subnet" == ""
for placement
[17:19:29] <fabbione> May 03 17:38:41 <fabbione>      placement = manual Depends
on ether_device
[17:19:42] <fabbione> May 03 17:38:58 <fabbione>      lon: ok we agree.. sounds sane
[17:19:48] <lon> how about I just have subnet and manual+require device for pass 1
[17:20:01] <fabbione> lon: sure
[17:20:05] <lon> auto is funky, esp when you start getting in to like
[17:20:09] <lon> bonded configs
[17:20:12] <lon> vpn devices
[17:20:14] <lon> crap like that.
[17:20:18] <fabbione> tunnels
[17:20:23] <lon> you got the point :)
[17:20:44] <fabbione> yeah
[17:20:50] * fabbione thinks one extra second
[17:21:00] <fabbione> i don't recall exactly why we thought about auto
[17:21:01] <fabbione> ....
[17:21:03] <fabbione> oh yes
[17:21:08] <lon> makes it easier
[17:21:17] <fabbione> only one common use case
[17:21:33] <lon> one ethernet device; eth0
[17:21:36] <fabbione> when there is only one interface != lo
[17:21:37] <lon> like most people have
[17:21:40] <lon> right
[17:21:42] <fabbione> and the subnet is differnt
...
[17:22:32] <fabbione> yeah let's do pass 1 with subnet and manual
[17:22:43] <fabbione> we can think more about auto at a later stage
[17:22:48] <fabbione> like..
[17:22:54] <fabbione> the devide that has the default gw associated
[17:23:00] <lon> right
Comment 7 Lon Hohberger 2007-05-29 16:44:57 EDT
Is the implemented behavior (ethernet_device -> assign to this device, up or
not) sufficient?

Note You need to log in before you can comment on or make changes to this bug.