cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Seitz <s.se...@secretresearchfacility.com>
Subject Re: Cloudstack management server changing msid
Date Mon, 10 Oct 2016 14:01:26 GMT
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

Mime
View raw message