Jump to content
Welcome to our new Citrix community!
  • 0

First attempt at upgrading Xenserver 8.1 to 8.2LTSR


Andy White1709154166

Question

Hello,

I’ve been asked to upgrade the 2 x 8.1 Xenserver to 8.2 LTSR which sit in the same cluster.

 

1. I’ve never done this before and wonder how long it normally takes and do they both have to be upgraded at the same time as I’d like to keep some applications running on 1 Xenserver if possible?

 

Helps with my Change Request form with regards to down time.

 

2. Do you use the GUI to upgrade or console onto the system and upgrade from there as it seems I can do it 2 ways.

 

3. From what I read you can have 1 HyperVisor (Xenserver) on 8.1 and server users still, but upgrade the other to 8.2 LTSR, but you need to do the pool master first?

 

To update I read I can just do it from the GUI (XenXenter > Tools > Install Updates > Then in the download section). 

 

image.thumb.png.42a69b7219d389cf7b5afe2d17edfb34.png

 

Any help/advise would be great.

 

Thanks

Link to comment

3 answers to this question

Recommended Posts

  • 0

Read all the update notes first to ensure something isn't going to bite you later, like something incompatible, a changed or removed feature, licensing / license server requirements, etc.

 

Make sure things like load balancing and high availability are all turned off beforehand.

 

The whole pool needs to be upgraded within a reasonable amount of time. Depending on what VMs to move to keep things running, it can take from a few hours to a better part of a day.

Once you start, there's really no going back. Weird partition tables and lac of space on dom0 can be issues. If you have a test VM, it's always a good idea to test an upgrade on it first, especially to be sure it's compatible (assuming you have the same or similar hardware).

 

Yes, the pool master gets the first upgrade. Not that when you have a pool with mixed upgraded and non-upgraded hots, you can only migrate from lower to newer versions of XS/CH, hence be careful to have enough capacity to shuffle things around.

 

I have always used the GUI. Sometimes, it fails partway because a VM won't migrate or some other dumb thing. Check all your hotfixes ahead of time and make sure all hosts are at identical patch levels! Worst case, if a VM won't migrate on its own from one host to another, you can force it via the CLI (yes, I have had to do this a number of times). Note that local SR based  VMs won't migrate; you'll have to shut them down ahead of time.

 

You can either do the automated or manual updates, as preferred. Probably easier to let it do all the updates instead of tracking them one-by-one on each host.

 

Hope this helps,

-=Tobias

Link to comment
  • 0

Strongly agree with Tobias about reading release notes and testing if possible. This will allow you to distinguish between things that no longer work and things that are unsupported by Citrix, but still work. For instance, I have some PV guests I need to keep running for the moment and some hosts with older Xeon CPUs both of which are described as unsupported, but continue to work on 8.2 CU1.

 

I recommend doing a pool metadata backup from xsconsole and also using xe pool-dump-database. If you have any custom crontabs or scripts in /root take a copy.

 

As for the methodology, I tend not to use the GUI for patches that require a host reboot as you don't have control over when VMs may be migrated or hosts put into maintenance mode. Some VMs will not migrate safely (a prime example being Citrix ADC VPX) and to maintain uptime in your ADC HA pair, it is safest to shutdown and restart on a different host manually. XenCenter will tend to migrate VMs away, then migrate them back before moving onto the next host, but this is not particularly efficient especially if you want to do the upgrade ASAP.  I manually evacute the pool master and check that any crucial VMs are still running after migration (because while it is rebooting you won't be able to do much) before I manually apply the patches on the pool master and reboot. Once that is all good, you can manually migrate/move crucial VMs to the pool master. The remaining pool members can be upgraded either with the GUI or manually.

Link to comment
  • 0

Stephen,

Evacuating the pool master ahead is a smart move.  Big issues can include failure to readily take XenTools updates after an up grade (under some circumstances) and as you said,

the inability to easily migrate existing VMs. Also as I think I noted above, and VMs on local SRs will have to be dealt with separately. Making sure you have enough space on hosts to accommodate shuffling VMs among hosts.

It's quite the process, and amazing how often it does work with few issues!

-=Tobias

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...