I got impatient waiting and decided to go ahead and edit the DB. Things really couldn't get any worse than they already were.
I am happy to report that I am back up and running and things look fine. I made the following changes: 1) Set removed in the mshost table for the 4.1.0 management server: update mshost set removed="2013-11-01" where msid=233845174730255; 2) Update the host table to have the vm hosts link to the 4.1.1 management server id from the 4.1.0 id: update host set mgmt_server_id=233845174730253 where mgmt_server_id=233845174730255; 3) Update the storage_pool_work table to link my storage to the 4.1.1 management server id from the 4.1.0 id: update storage_pool_work set mgmt_server_id=233845174730253 where mgmt_server_id=233845174730255; Started the MS and the SSVM came to life. I did have to destroy the CPVM and the VR and they came back. I also noticed that since the version of the hosts was still 4.1.0, the MS pushed its scripts out to the hosts and apparently updated version in the host table to have them as 4.1.1. The only thing that does not look right is that the state of the 4.1.0 mshost still shows as "Up". Looks like it does not matter since it is "removed" but I am guessing it would be better if I set it to "Stopped" or something along those lines. Any suggestions? I am guessing the problem happened as a result of a botched update (I used apt-get with the standard repo from the docs). The only thing I can think of is that the XenServers were not reachable during the update and therefore something got missed and I ended up in a state where the new MS software was installed but hosts and storage were not linked over to it because the scripts could not contact the hosts. Probably not a very common occurrence. cheers, -Carlos On Tue, Nov 5, 2013 at 3:22 PM, Carlos Reategui <create...@gmail.com> wrote: > Hi, > Can someone that has updated from 4.1.0 to 4.1.1 (ideally with XenServer > hosts) run the following queries in their db: > > select msid, state, version, service_port, removed from mshost; > select ms.msid, ms.version as ms_version, h.version as host_version, count( > h.id) from mshost ms, host h where ms.msid=h.mgmt_server_id; > > On my db I see the following: > mysql> select msid, state, version, service_port, removed from mshost; > +-----------------+-------+---------+--------------+---------+ > | msid | state | version | service_port | removed | > +-----------------+-------+---------+--------------+---------+ > | 233845174730255 | Up | 4.1.0 | 9090 | NULL | > | 233845174730253 | Up | 4.1.1 | 9090 | NULL | > +-----------------+-------+---------+--------------+---------+ > 2 rows in set (0.00 sec) > > mysql> select ms.msid, ms.version as ms_version, h.version as > host_version, count(h.id) from mshost ms, host h where > ms.msid=h.mgmt_server_id; > +-----------------+------------+--------------+-------------+ > | msid | ms_version | host_version | count(h.id) | > +-----------------+------------+--------------+-------------+ > | 233845174730255 | 4.1.0 | 4.1.0 | 2 | > +-----------------+------------+--------------+-------------+ > 1 row in set (0.00 sec) > > I don't think this is right and I am trying to see what it looks like for > others that have done the upgrade from 4.1.0 to 4.1.1. I believe the 4.1.0 > msid should have a date in there indicating that it is no longer active and > hosts in the host table should be linked to the 4.1.1 msid not the 4.1.0. > As well as have there version updated to 4.1.1. > > For the dev list guys, would it me ok for the to edit these values and see > if that fixes my broken installation? Also what should I do with entries > in the tables like op_ha_work, op_it_work and storage_pool_work. I am > guessing I also would need to update the later also but not sure about the > first 2. > > thank you > Carlos > > >
