"NOT_SUPPORTED_DURING_UPGRADE()" error after yesterday's update
-
Were the hosts rebooting after the patches were applied?
-
@Danp
Nope! -
@archw I'd advise to read documentation at the part related to rebooting after package upgrades: https://docs.xcp-ng.org/management/updates/#-when-to-reboot
In this case "xen" updates were included in December package updates which results in one of the criteria for having to reboot being met.
Personally I reboot every time package updates were installed. You stay on the safe side by doing so.
-
@MajorP93
I always reboot at the conclusion of the update and did as well this time. -
@archw I'm confused by your recent responses. I asked --
Were the hosts rebooting after the patches were applied?
to which you replied --
Nope!
but then you stated
I always reboot at the conclusion of the update and did as well this time.
Which is correct?
-
@archw Mhh, Danp asked if you rebooted your hosts after applying the patches and you said nope.
-
@MajorP93
My bad....because of the word "rebooting" I took the statement "Were the hosts rebooting after the patches were applied?' to mean 'Were the hosts rebooting while the patches were being applied?'To recap:
I did reboot after the patches had been applied.Sorry !!
-
@archw Ohh I get it now! The "rebooting" instead of "rebooted" can be understood as "did applying the patches cause the systems to reboot" as in system crash or similar.
Gotcha!
Understood what you meant now.//EDIT: anyways, back to topic. In case the systems were already rebooted after applying the updates I currently do not have an idea what might cause this...
-
s/rebooting/rebooted
Apologies for the miswording on my end.
-
@Danp
WDE
-
@Danp said in "NOT_SUPPORTED_DURING_UPGRADE()" error after yesterday's update:
s/rebooting/rebooted
Apologies for the miswording on my end.
Please be careful of tenses (past tense etc), as it will change the meaning of the question and thus the answer. As rebooted can be understood as it has already completed rebooting the host, following the update reboot request.
-
@john.c said in "NOT_SUPPORTED_DURING_UPGRADE()" error after yesterday's update:
Please be careful of tenses (past tense etc),
Yeah... I was trying to be helpful, but I was clearly in too much of a hurry.
Mea culpa
-
@Danp said in "NOT_SUPPORTED_DURING_UPGRADE()" error after yesterday's update:
@john.c said in "NOT_SUPPORTED_DURING_UPGRADE()" error after yesterday's update:
Please be careful of tenses (past tense etc),
Yeah... I was trying to be helpful, but I was clearly in too much of a hurry.
Mea culpa
It’s alright great that you’re willing to help even during your own time. I posted what I did in order to help you get better with the English language.
Next time you think you’re in too much of a hurry say to yourself or in your mind, this old saying “Haste makes waste”.
-
Mystery solved:
There are numerous hosts under one master in the pool. I ran the yum update command on the master first, then rebooted, I then ran yum update on the rest and rebooted all but one. I could not reboot the last one until this morning (Saturday).I rebooted the last one a few minutes ago and all is well.
Because I think its interesting, I'd love someone smart to explain the process of why other hosts could not do a snapshot because a different host in the pool had not been rebooted.
-
Because doing an update without rebooting doesn't reload the updated main programs, like XAPI. A host in only updated after a full reboot.
-
@olivierlambert said in "NOT_SUPPORTED_DURING_UPGRADE()" error after yesterday's update:
Because doing an update without rebooting doesn't reload the updated main programs, like XAPI. A host in only updated after a full reboot.
Reply
Hi there
Is it just me or is this a chicken and egg situation.you upgrade the master... how the pool is in NOT_SUPPORTED_DURING_UPGRADE() stage. You cant move vms off the master so all you can do is close down vms.. reboot.. pray
then move the a non master.. you cant move the vms off here either NOT_SUPPORTED_DURING_UPGRADE(). So you have do the same..
needless to say I hit issues on each reboot which caused 30- 60 min delays in getting vms back up and running.
can you Warm migrate or is this dead also (to scared to test)
-
@magicker said in "NOT_SUPPORTED_DURING_UPGRADE()" error after yesterday's update:
@olivierlambert said in "NOT_SUPPORTED_DURING_UPGRADE()" error after yesterday's update:
Because doing an update without rebooting doesn't reload the updated main programs, like XAPI. A host in only updated after a full reboot.
Reply
Hi there
Is it just me or is this a chicken and egg situation.you upgrade the master... how the pool is in NOT_SUPPORTED_DURING_UPGRADE() stage. You cant move vms off the master so all you can do is close down vms.. reboot.. pray
then move the a non master.. you cant move the vms off here either NOT_SUPPORTED_DURING_UPGRADE(). So you have do the same..
needless to say I hit issues on each reboot which caused 30- 60 min delays in getting vms back up and running.
can you Warm migrate or is this dead also (to scared to test)
For me this workflow worked every time there were upgrades available:
-disable HA on pool level
-disable load balancer plugin
-upgrade master
-upgrade all other nodes
-restart toolstack on master
-restart toolstack on all other nodes
-live migrate all VMs running on master to other node(s)
-reboot master
-reboot next node (live migrate all VMs running on that particular node away before doing so)
-repeat until all nodes have been rebooted (one node at a time)
-re-enable HA on pool level
-re-enable load balancer pluginNever had any issues with that. No downtime for none of the VMs.
-
Exactly and that's what does the Rolling Pool Update feature
