Project

General

Profile

Actions

Bug #601

closed

VHID changes do not apply immediately on secondary

Added by Chris Buechler over 14 years ago. Updated about 14 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Virtual IP Addresses
Target version:
Start date:
05/17/2010
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:

Description

When changing the VHID on the primary, it's applied immediately on the primary and synced to the secondary so its config.xml is correct, but the secondary does not update its configured CARP IPs with the correct VHID. So you end up with dual master status, with each on a different VHID.

Actions #1

Updated by Jim Pingle over 14 years ago

This does not happen as expected. The VHID does sync in the config, but that change does not propagate to the actual CARP interface. I suspect this is due to the issue I found in ticket #643

It won't update a CARP interface on sync, only at boot or when you edit/save the VIP.

Actions #2

Updated by Chris Buechler over 14 years ago

  • Tracker changed from Todo to Bug
Actions #3

Updated by Chris Buechler over 14 years ago

  • Subject changed from verify VHID change applies immediately on secondary to VHID changes do not apply immediately on secondary
Actions #4

Updated by Jim Pingle over 14 years ago

Just tested this again, and it is still a problem. On the secondary box, the VHID changes under the CARP settings screen, but on Status > CARP, the interface name is still the old VHID, and even though it shows "backup" in the GUI, the output of ifconfig -a shows it as master.

So the logic for renaming the CARP VIP interface (e.g. vip55 -> vip41) as well as changing the VHID on the interface isn't happening after the xmlrpc sync.

Actions #5

Updated by Ermal Luçi over 14 years ago

  • Status changed from New to Feedback

I implemented the fix for this.
Though i think it is better to put even the reloading of carps through rpcxml in the same way i did for destroying the old ones, instead of relying on a xmlrpc call to bring them up again!

Actions #6

Updated by Jim Pingle about 14 years ago

  • Status changed from Feedback to Resolved

This works properly now.

Actions

Also available in: Atom PDF