XS71 CU2 pool update hung

[Philip John Gregg]

XS 7.1 CU2 installing 3 recent updates to a pool of two servers (rumi & hafez).

 

I auto-applied the three hotfixes to the pool. Rumi the master volunteered to go first. Patches were applied to rumi but when trying to migrate VMs back to hafez there was a storage error. The Xen Center options were "Retry" or "Finish". Retry went round the loop to same point so eventually Finish was chosen. I shutdown the offending VM and tried to apply the updates again. This time the slave node (hafez) was being updated.

 

After precchecks are done the following error occurs:

 

The following error occurred while automated updates were in progress: hafez: Internal error: /etc/xapi.d/extensions/pool_update.precheck

The automated updates process was not completed successfully. The update process has paused. Press Retry to resume it.

 

Retry has no effect. I tried applying updates one at a time but same error. Presumably rumi/hafez pool is in some wierd state and needs a slight adjustment or a bypass of the precheck script?

 

Many Thanks for reading.

 

Phil

 

 

 

 

 

 

 

[Tobias Kreidl]

NTP is properly symched and all hosts within a couple hundred milliseconds or less of each other? What if you abort the upgrade and start again?

[Philip John Gregg]

Hi,

 

Thanks for replying.

 

> NTP?

Yes, NTPs are synced.

 

> What if you abort the upgrade and start again?

It is not an upgrade it is a bunch (3) of updates/hotfixes.

 

Regards

 

[Alan Lantz]

since the master was successful you would think you could restart a slave host and then it apply correctly. 

I don't recall ever having a pool in an inconsistent state like that.

 

--Alan--

 

[Philip John Gregg]

Thanks.

 

I tried applying the first of the patches to the slave manually using "xe patch-pool-apply uuid=00e49b0d..." which gave me more to work on:

 

XenAPI.Failure: ['SR_HAS_NO_PBDS', 'OpaqueRef:32cba639-dae6-a952-...] which sort of point me back to the original storage error issue.

 

Maybe I should reboot the slave and try again.

 

Anyone know how to work out the UUID from the OpaqueRef?

 

Cheers

 

 

 

 

 

 

[Philip John Gregg]

Solved:  Luckily the failed SR had only one VM which was dispensible, so after deleting the VM and detaching/forgetting the SR the update went onto the slave smoothly.

Interestingly, when I did "Forget" on the SR I got a notification saying the Object OpaqueRef:32cba639-dae6-a952-... has been deleted.

 

[Tobias Kreidl]

You may have to apply the updates manually via the CLI, as the GUI sometimes hangs or will not work depending on the status of the pool thinking what has and has not been applied.