Hi  David,

with a bit of delay...

those steps need to be tested - I would skip the whole
"environment.properties" file and see how it behaves today - the reason
being that, though the article on shapeblue.com was old, it does mention
both "Unmanage" cluster and Maintenace mode - so I'm not quite sure what is
the difference today vs. how it behaved back in time of ACS 4.3 / XS 6.2 -
the explanation that you've found on the mailing thread may not make sense,
I mean specifically the "There wasn't an 'unmanage' button at the time",
since the article clearly mentions it).

There is also no need to manually migrate VM's away from a host (i.e. pool
master) - simply put it into the Maintenance mode and it will move VMs away
to other hosts.

Assuming that putting the pool-master into Maintenance mode in ACS will,
these days, NOT trigger a new host to become a master, your steps look fine.

For the records, I've updated&&tested the official documentation, for
XenServer 6.5+ : https://github.com/apache/cloudstack-documentation/pull/140
 /
https://acs-www.shapeblue.com/docs/WIP-PROOFING/pr140/installguide/hypervisor/xenserver.html#upgrading-xenserver-versions
-
i.e. removed unneeded steps and explained what each script is doing. This
guide assumes a much longer management plane downtime, as the cluster is
unmanaged while you update all the hosts in the pool. Works fine also for
XCP-ng upgrades, etc.

Either way, I prefer doing it based on the plan you laid out here.

Regards,
Andrija

On Fri, 19 Jun 2020 at 23:24, David Merrill <david.merr...@otelco.com>
wrote:

> Hi All,
>
> I have a production deployment of ACS managing three XenServer Clusters
> (XenServer pools of 6 hosts each) in two different Zones. I now find myself
> in the position of needing to do a major version upgrade of those hosts.
> Happily I have a ACS lab managing a XenServer cluster running the same
> (old) version of XenServer that I can practice on.
>
> I have plenty of practice operating ACS to “quiesce things” for XenServer
> patches (start with the pool master, move guest VMs off, put that host into
> maintenance mode, unmanage the cluster, patch the host, then reverse & move
> onto the next host with the same steps except we don’t bother
> w/un-managing/re-managing the cluster), but as I understand a XenServer
> version upgrade backs up the whole original XenServer installation to
> another partition and makes a clean installation of XenServer on the
> original partition (the problem there being that when the upgraded
> XenServer boots up all the ACS provided/copied scripts are not there & ACS
> can’t manage the host).
>
> So not much of an ask here (OK maybe at the end – have I missed something
> obvious or doing anything foolish?), I wanted to share a bit research & lay
> out a set of steps that I think will work to get a pool of XenServers in a
> cluster upgraded and end up in a place where ACS is happy with them.
>
> Bear with me it’s a little long,
>
>
>   1.  In XenCenter – if HA is enabled for the XenServer pool, disable it
>   2.  Stop ACS management/usage services
>   3.  Do MySQL database backups
>   4.  Start ACS management/usage services
>   5.  Start with the pool master.
>   6.  In ACS – Migrate all guest VMs to other hosts in the cluster
>   7.  In ACS – Prepare to put the pool master into maintenance mode (so no
> new guest VMs)
>      *   A caveat here related to this item I found when researching –
> https://www.shapeblue.com/how-to-upgrade-an-apache-cloudstack-citrix-xenserver-cluster/
>
>                                                                i.      A
> recommendation is made here to edit
> /etc/cloudstack/management/environment.properties
>
>                                                              ii.      And
> set manage.xenserver.pool.master=false
>
>                                                            iii.      And
> restart CloudStack management services
>
>                                                            iv.
> BECAUSE if one didn’t I understand CloudStack WOULD force an election for
> another host to become the pool master (which is “bad” as ASCs is
> configured to speak to the currently configured pool master)
>
>      *   HOWEVER THIS MAY NOT BE NECESSARY
>
>                                                                i.
> Found a thread titled “A Story of a failed XenServer Upgrade” here –
> http://mail-archives.apache.org/mod_mbox/cloudstack-users/201601.mbox/browser
>
>                                                              ii.      At
> the end of the thread Paul Angus states that Geoff’s ShapeBlue blog article
> was written in the ACS 4.3 era and that ACS’ behavior “used to be that
> putting a host that was the pool master into maintenance would cause
> CloudStack to force an election for another host to become pool master -
> stopping you from then upgrading the active pool master first. There wasn't
> an 'unmanage' button at the time.”
>
>                                                            iii.      The
> implication, (in my humble estimation) is that, today, one no longer needs
> to make these edits to /etc/cloudstack/management/environment.properties
>
>   1.  In ACS – Put the pool master into maintenance mode (so no new guest
> VMs)
>   2.  In ACS – Un-manage the cluster
>   3.  NOW – Upgrade the XenServer pool master to the latest release
>      *   Exercise left to the reader…(I’ll share what I end up doing)
>   4.  In XenServer – Do the following (found this nugget in a thread last
> November about XenServer upgrades & how to re-setup the host – thanks
> Richard Lawley!)
>      *   Remove this host tag: xe host-param-remove uuid=HOSTUUID
> param-name=tags
> param-key=vmops-version-com.cloud.hypervisor.xenserver.resource.XenServer650R
>      *   This makes management server set the host back up, presumably
> since ACS has credentials to the host in the database it can copy all the
> scripts back
>   5.  In ACS – Re-manage the cluster
>   6.  In ACS – Exit maintenance-mode for the newly upgraded host
>   7.  In ACS – Observe that the newly upgraded host is “Enabled” and “Up”
> in the UI (Infrastructure --> Hosts)
>   8.  In ACS – Testing (e.g. move an existing router/VM to the upgraded
> host, create new networks/VMs on the upgraded host)
>   9.  Rinse & repeat with the remaining XenServer pool members in the ACS
> cluster.
>      *   WITH THIS EXCEPTION: No need to manipulate management of the
> cluster in ACS
>   10. In XenCenter – if HA is required re-enable it
>
> Now all of this completely bypasses steps that are spelled out here (which
> I *suspect* might now be “old”?):
>
>
>   *
> http://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/xenserver.html#upgrading-xenserver-versions
>
> which asks one to run a lot of scripts (cleaning VLANs, preparing for
> upgrade etc.) in addition to copying files from the management server to
> the XenServer host (to set it back up again for ACS). I’m really hoping
> that step 11 saves me from that.
>
> So (asks after all):
>
>
>   1.  Is this a reasonable/viable plan?
>   2.  Is my take on step 7 correct?
>
> Thanks for taking a look,
> David
>
> David Merrill
> Senior Systems Engineer,
> Managed and Private/Hybrid Cloud Services
> OTELCO
> 92 Oak Street, Portland ME 04101
> office 207.772.5678<callto:207.772.5678>
> http://www.otelco.com/cloud-and-managed-services
>
> Confidentiality Message
> The information contained in this e-mail transmission may be confidential
> and legally privileged. If you are not the intended recipient, you are
> notified that any dissemination, distribution, copying or other use of this
> information, including attachments, is prohibited. If you received this
> message in error, please call me at 207.772.5678<callto:207.772.5678> so
> this error can be corrected.
>
>

-- 

Andrija Panić

Reply via email to