cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Reátegui <create...@gmail.com>
Subject Re: Cloudstack management server changing msid
Date Fri, 07 Oct 2016 16:05:46 GMT
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@secretresearchfacility.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


Mime
View raw message