Yes, I'ld mark the old ones removed. I'm quite unsure where the id- field is referenced to, so if it was my management-node, I'ld use the entry with the last working id and mark the others as removed by setting a date in the past into the removed-fields.
I don't know if this is the promoted way, but that worked for our setup. cheers, - Stephan Am Freitag, den 07.10.2016, 09:05 -0700 schrieb Carlos Reátegui: > Thanks…. That makes sense. I do have a bond for my NICs which means > the OS will pick one of the underlying MACs for the bond MAC upon > boot (and not always the same one). > > And since my NIC card has been replaced twice that is why my table > looks like this: > > mysql> select id,hex(msid),runid,state,version,last_update,removed > from mshost; > +----+--------------+---------------+-------+---------+------------ > ---------+---------+ > > > > id | hex(msid) | runid | state | version | > > last_update | removed | > +----+--------------+---------------+-------+---------+------------ > ---------+---------+ > > > > 1 | 90B11C2005CF | 1438989683052 | Up | 4.5.1 | 2016-02-24 > > 23:11:01 | NULL | > > 2 | C81F66E36518 | 1472507558962 | Up | 4.5.2.1 | 2016-09-23 > > 16:30:06 | NULL | > > 3 | C81F66E36516 | 1474876304188 | Up | 4.5.2.1 | 2016-09-26 > > 07:54:20 | NULL | > > 4 | 44A8421593B2 | 1475849685464 | Up | 4.5.2.1 | 2016-10-08 > > 00:09:44 | NULL | > > 5 | 44A8421593B0 | 1475199571333 | Up | 4.5.2.1 | 2016-09-30 > > 02:01:31 | NULL | > +----+--------------+---------------+-------+---------+------------ > ---------+---------+ > 5 rows in set (0.00 sec) > > I’m going to set the hwaddress as you suggest to keep the bond MAC > from changing. > > Should I mark the “old” msids removed? > > thank you! > > > > > > > On Oct 7, 2016, at 12:51 AM, Stephan Seitz <s.seitz@secretresearchf > > acility.com> wrote: > > > > Hi Carlos, > > > > we encountered the same issue after introducing nic-bonding on the > > management net which changed the MAC. > > > > The msid includes the MAC of the interface which has the service_ip > > bound to. If that MAC changes, your management node encounters an > > identity crisis ;) > > > > We solved that, by updating the msid field in the cloud.mshost > > table. > > > > The msid is the decimal representation of the MAC. So, in our case > > 57177340185274 (dec) = 3400a30d0aba (hex) (34:00:a3:0d:0a:ba) > > > > This currently shows: > > > > mysql> select * from mshost where id=1 \G > > *************************** 1. row *************************** > > id: 1 > > msid: 57177340185274 <------------------- > > runid: 1474366224657 > > name: acs-management-1 > > state: Up > > version: 4.9.0 > > service_ip: 10.97.13.1 > > service_port: 9090 > > last_update: 2016-10-07 07:43:59 > > removed: NULL > > alert_count: 0 > > 1 row in set (0.00 sec) > > > > > > # ip addr show dev bond0 > > 4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc > > noqueue state UP group default qlen 1000 > > link/ether 34:00:a3:0d:0a:ba brd ff:ff:ff:ff:ff:ff > > inet 10.97.13.1/22 brd 10.97.15.255 scope global bond0 > > valid_lft forever preferred_lft forever > > > > > > Another way to solve this issue could be changing the MAC of the > > management interface to a known (and fixed) value. E.g. by using > > ethtool. > > > > If you know the removed hardware is no longer used in the same > > network > > segment, and you do know the previos MAC, you could change your > > network > > configuration by setting the MAC on the new hardware to the > > previously > > one. > > > > To be safe from further changes, we did this additionally by using > > the > > hwaddress keyword in /etc/network/interfaces. This is the > > debian/ubuntu > > way. > > > > auto bond0 > > iface bond0 inet static > > address 10.97.13.1 > > netmask 255.255.252.0 > > gateway 10.97.12.1 > > dns-nameservers XXXXXXXXXXXXXXXX > > dns-search XXXXXXXXXXXXXXXXXXXXXXX > > hwaddress 34:00:a3:0d:0a:ba > > bond-slaves eth0 eth1 > > bond-mode 4 > > bond-lacp-rate 1 > > bond-miimon 100 > > bond-updelay 200 > > bond-downdelay 200 > > > > > > Hope this helps! > > > > cheers, > > > > - Stephan > > > > Am Donnerstag, den 06.10.2016, 23:41 -0700 schrieb Carlos Reátegui: > > > > > > Hi, > > > I have had this issue a few times now with my management > > > server. I > > > have had a couple unfortunate hw issues that have caused the > > > machine > > > to crash (have replaced motherboard, backplane and network > > > cards…. > > > don’t ask). Upon restoring the machine there is a new entry in > > > the > > > mshost table. However the host table mgmt_server_id still > > > references > > > the old mshost.msid and therefore my management server is unable > > > to > > > “manage” the hosts. > > > > > > The only way to fix this is to : > > > update host set mgmt_server_id=<new msid> where > > > mgmt_server_id=<old > > > msid>; > > > > > > Anyone else run across this? Is there a proper way to restore a > > > management server? How does the management server decide it is a > > > new > > > mshost and create a new entry in the mshost table? > > > > > > Currently my mshost table has 5 entries and they all claim to be > > > in > > > the “Up” state even though there is only 1 management > > > server. One of > > > the entries is for the original 4.5.1 install. The other 4 are > > > for > > > the current 4.5.2.1 upgrade. They all have the same IP address. > > > > > > thanks, > > > Carlos
