What David said ^^^ above.

IMO, don't even bother without having a LAB first - you are making HUGE
jumps with both hypervisor and ACS version, and that needs to be tested
"the hell out of it" to put it that way - 4.11 sounds like a feasible
mid-version. XCP-ng needs to be 7.4 or 7.6 at most (please confirm in the
Release notes - and also please test upgrading XS to XCP-ng, as this is
again an exercise on it's own)

And please note 8.2 will be only supported in 4.15.1 which is not yet out -
8.1 is the latest one you can use in 4.15.0.0
Read the 4.11 Release notes to see if 6.2.0 is still supported (not being
officially supported, doesn't mean there is any piece of code really
removed from ACS - so if 6.5 is supported, 6.2 should also work 99.99% -
again, a thing to confirm in lab)

Best,

On Wed, 31 Mar 2021 at 19:33, David Merrill <david.merr...@otelco.com>
wrote:

> I suspect the answer is a qualified "maybe/yes"? A couple (humble)
> thoughts as it sounds like you've got the two upgrades in mind:
>
>  - focus first on the upgrade path to the latest ACS 4.*.* that still
> supports XS 6.2.0
>  - determine the upgrade path from XS 6.2.0 to XCP 8.2 (not sure - just
> something work considering - maybe you'd need/want to upgrade to XS 6.5/7.*
> first?)
>  - (sorry to be pedantic), lab it all up & test before doing anything in
> production!
>
> I'd defer to Andrija (& the rest of the list!) for any other advice.
>
> 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.
>
>
> On 3/31/21, 6:21 AM, "benoit lair" <kurushi4...@gmail.com> wrote:
>
>     Hello David,
>
>     We have an ACS 4.3 install with somes XS 6.2.0 clusters.
>     Would you think we could perform an upgrade from these XS 6.2.0 to ACS
> 4.11
>     with the same way ?
>
>     The finality would be to move our ACS 4.3 to ACS 4.15 in order to
> convert
>     in fine our XS 6.2 to XCP 8.2
>
>     @Andrija, would you think this could be achieved ?*
>
>     Thanks a lot
>
>     Le mar. 14 juil. 2020 à 04:34, David Merrill <david.merr...@otelco.com>
> a
>     écrit :
>
>     > Reporting in on this - turns out was fairly painless (I never ended
> up
>     > goofing around with host tags at all).
>     >
>     >
>     >
>     > Here's an updated to-do list (with some observations):
>     >
>     >
>     >
>     >   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
>     >               *   In ACS – Put the pool master into maintenance mode
> (this
>     > migrate all guest VMs to other hosts in the cluster)
>     >               *   In ACS – Un-manage the cluster (this keeps any
> activity
>     > from happening in the pool)
>     >               *   NOW – Upgrade the XenServer pool master to the
> latest
>     > release
>     >
>     >                               i.      Do this by picking up the
> “correct”
>     > ISO from Citrix, burning it to a CD/DVD/USB-stick, booting the host
> with it
>     > & performing a manual upgrade to the version of XenServer you’re
> going to
>     >
>     >                             ii.      Before upgrading the installer
> should
>     > make a backup of the existing installation
>     >
>     >                            iii.      When the upgrade is complete
> you’ll
>     > be prompted to reboot the host
>     >
>     >                            iv.      OBSERVATION (after booting):
>     >
>     >                     *   The XenServer console (the ncurses interface)
>     > still said XenServer 6.5 in the upper-left-hand corner (which led me
> to
>     > believe that the upgrade hadn’t worked)
>     >                     *   However when I reconnected with XenCenter it
>     > reported XenServer 7.1 CU2 was installed
>     >                     *   So…OK, fine?
>     >                     *   There were no host tags for that newly
> upgraded
>     > host, so my to-do to remove the tag wasn’t necessary
>     >               *   In ACS – Re-manage the cluster
>     >               *   In ACS – Exit maintenance-mode for the newly
> upgraded
>     > host
>     >               *   In ACS – Observe that the newly upgraded host is
>     > “Enabled” and “Up” in the UI (Infrastructure > Hosts)
>     >               *   OBSERVATION:
>     >
>     >                               i.      After finishing the 2 steps
> above on
>     > checking in XenCenter the host now had the host tag:
>     >
> vmops-version-com.cloud.hypervisor.xenerver.resource.XenServer650Resource-4.11.3.0
>     >
>     >                             ii.      Scripts in /opt/cloud/bin have a
>     > timestamp that coincides with the cluster being re-managed and the
> pool
>     > master coming out of maintenance mode
>     >
>     >   1.  In ACS – Testing (e.g. move an existing router/VM to the
> upgraded
>     > host, create new networks/VMs on the upgraded host)
>     >
>     >                               i.      OBSERVATION:
>     >
>     >                     *   Moving existing router/VMs to the upgraded
> host
>     > worked
>     >                     *   I was not able to create new VMs until all
> pool
>     > members were at the same level of XenServer
>     >   1.  Rinse & repeat with the remaining XenServer pool members in
> the ACS
>     > cluster
>     >               *   Follow the same steps as the pool master EXCEPT do
> not
>     > un-manage/re-manage the cluster in ACS (no need to do so really
> although
>     > from the perspective of operators new VM creation is clearly not
> possible
>     > until were done and who knows maybe you don’t really want folks
> trying to
>     > take actions while you’re in the middle of all this?)
>     >               *   OBSERVATION (unexpected):
>     >
>     >                               i.      I noticed that even before I
> had
>     > brought a newly upgraded pool member out of maintenance in ACS that
> the
>     > following host tag
>     >
> vmops-version-com.cloud.hypervisor.xenerver.resource.XenServer650Resource-4.11.3.0
>     > was already there
>     >
>     >                             ii.      AND that the Scripts in
>     > /opt/cloud/bin had a timestamp that coincides with the pool member’s
> recent
>     > reboot
>     >
>     >   1.  In XenCenter – if HA was enabled at the start, re-enable it
>     >
>     >
>     >
>     > So my lab pool is up and running upgraded from XenServer 6.5 to
> XenServer
>     > 7.1.2 CU2 LTSR and so far, CloudStack 4.11.3 seems to be happy with
> it.
>     >
>     >
>     >
>     > Next steps are to apply the latest XenServer hotfixes (following the
> same
>     > recipe above) and re-test activities in ACS.
>     >
>     >
>     >
>     > Thanks,
>     >
>     > 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