----
From the Field: XenServer 7.X Pool Upgrades, Part 1: Background Information and Clean Install
// Latest blog entries
The XenServer upgrade process with XenServer 7 can be a bit more involved than with past upgrades, particularly if upgrading from a version prior to 7.0. In this series I'll discuss various approaches to upgrading XenServer (XS) pools to 7.X and some of the issues you might encounter during the process based on my experiences in the field.
Part 1 deals with some of the preliminary actions that need to be taken into consideration and the planning process, as well as the case for a clean installation. Part 2 deals with the alternative, namely a true in-place upgrade procedure, and what issues may arise during and after the procedure.
Why Upgrade to XenServer 7?
XenServer (XS) 7 has been out for a little over a year now and is currently up to release 7.2. A number of improvements in scaling, functionality and features are available in XS 7, which should encourage users to upgrade to take advantage of them.
First Step in Any XS Upgrade
The first step in any XenServer upgrade is to upgrade your XenCenter to at least the minimum version required to support the newest installation of XenServer you are or will be accessing.
This step is crucial. Failure to do this causes puppies to die. This is because older versions of XenCenter won't connect to newer versions of XS and in many cases, new features are built into the newer versions of XenCenter that are not available in older versions and support important components in the newer XS releases, including hotfix and rolling pool upgrade options, changes in licensing, and others such as supported pooled storage options. In short, your upgrade process will rapidly come to a screeching halt and there may be potential damage done unless you are working with the proper version of XenCenter.
It is also highly recommended to make backups of anything and everything prior to upgrading. More on that will be discussed later.
Summary of Pre-Upgrade Checks
From experience, the following are key activities to perform before upgrading any XenServer pool:
XenCenter has been upgraded to at least the version that does or will match your newest pool
- Assure the proper backups of virtual machines (VMs), metadata, etc. have been performed
- Make sure that all VMs are agile (can be migrated to other hosts within the pool) or in the case of a rolling pool upgrade, at least shut down on all local SRs
- All hosts must not only be running the same version of XenServer, but must have the identical list of hotfixes applied
- Clean up old messages in /var/lib/xcp/blobs/
I'd also recommend doing an "export resource data" for the pool, which has been available as a utility since XS 6.5 and can run from XenCenter.
To export resource data:
- In the XenCenter Navigation pane, click Infrastructure and then click on the pool.
- From the XenCenter menu, click Pool and then select Export Resource Data.
- Browse to a location where you would like to save the report and then click Save.
You can chose between an XLS or CVS output. Note that this feature is only available on XenCenter with paid-for licensed versions of XenServer. However, it can also be run via the CLI for any (including free) version of XS 6.5 or newer using:
# xe pool-dump-database file-name=target-file-name
Benefits of a XenServer 7 Upgrade
XenServer 7 is a significant jump from XS 6.5 SP1 in many ways, including improvements in scale and performance. It also has added a number of very nice new features (see what's new in XS 7; what's new in XS 7.1; XS 7.2 ).
While any upgrade can be a bit intimidating, ones that jump to a whole new edition can be more complicated and given the changes involved here, this case was no exception. I would also recommend trying to verify your hardware is present on the HCL though it's often slow to get populated. If in doubt and you have the extra resources, take as close as possible a spare server and try to do an installation on it first to make sure it's compatible. If you don't have such a machine and have the spare capacity, eject one of the hosts from your pool and use it to test out the upgrade. Before performing an upgrade on a production server or pool, it is always recommended to try this out first on a test configuration.
I do not recommend at this time the rolling pool or standalone upgrade that involves switching at the same time from the old to the new partition layout. Overall experiences within the user community have not been consistently positive.
It is hoped that the preparatory steps that are recommended before undertaking an upgrade do not prove to be too daunting. This series is intended to help with those preparations as well as give guidelines and tips how to go about the process and what to do if issues arise. There are clearly a number of ways to tackle upgrades and there are undoubtedly numerous other possible approaches. One might, for example, storage XenMotion VMs to other pools or make use of temporary pooled storage as part of the process. The detaching and attaching pooled storage to servers already running a newer version of XenServer is another possible route to explore.
Experimentation is always something that should be encouraged, albeit not on production systems!
Feedback is always appreciated and the XenServer forum https://discussions.citrix.com/forum/101-xenserver/ is one good option. Errors, on the other hand, should be reported to the XenServer bugs site with preferably sufficient detail to allow the engineers to be able to understand and reproduce the issues.
XS 7.X Leveraging a Clean Installation as an Upgrade Component
A clean install can become part of an upgrade procedure if for example an upgraded pool already exists and individual hosts or hosts from a whole different pool are to be merged into a pool running a newer version of XenServer. Hence talking about this option is relevant to upgrading. You can potentially storage Xenmotion VMs over to a new pool, then eject and dissolve individual pool members, perform a clean installation on them, and join the hosts to the new pool. Of course the target pool must have adequate resources to hold and run the VMs being moved over until the new hosts can be configured and added. This process might involve leveraging temporary external storage, for example, by creating an NFS SR.
The easiest installation scenario is a clean install, which has thankfully always been the case and this approach may work well in some instances. This is obviously suited best for a standalone server or as mentioned above, creating a server that will be joined to an existing pool.
Regardless of which upgrade process you undertake, be sure to review your VMs afterwards to see if XenTools need to be updated.
A Few Words About the XenServer 7 New Disk Layout
The main item to be aware of is that a clean installation will always create the new GPT partition layout as follows:
| Size | Purpose |
| 4GB | log partition (syslogd and other logs) |
| 18GB | backup partition for dom0 (for upgrades) |
| 18GB | XenServer host control domain (dom0) partition |
| 0.5GB | UEFI boot partition |
| 1GB | swap partition |
This adds up to 41.5 GB. There can be a sixth partition which is optionally used for creating a local storage repository (SR) or a portion of a local SR if spanning it to other storage devices. See also James Bulpin's XS 7 blog for more details about the XS 7 architecture.
Here is what a real-life partition table looks like after performing an installation. Note that the space for a local SR ends up in partition 3 (in this case, a default LVM partition 94.6 GB in size):
# fdisk -l /dev/sda
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
Disk /dev/sda: 146.2 GB, 146163105792 bytes, 285474816 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt
# Start End Size Type Name
1 46139392 83888127 18G Microsoft basic
2 8390656 46139391 18G Microsoft basic
3 87033856 285474782 94.6G Linux LVM
4 83888128 84936703 512M BIOS boot parti
5 2048 8390655 4G Microsoft basic
6 84936704 87033855 1G Linux swap
Why was the XenServer 7 Disk Layout Changed?
The XS 6.5 SP1 and earlier partition scheme was much smaller and simpler:
4 GB XenServer host control domain (dom0) partition
4 GB backup partition for dom0 (for upgrades)
The rest of the space was again available for use as a local SR in a third partition.
The default partition layout was changed under XS 7 for a number of reasons. For one, most storage devices these days start with a capacity of few hundred GB and so it makes sense to be able to allocate more space for the XenServer installation itself beyond just 8 GB. In that regard, running out of space has been a common problem caused by either a lot of hotfixes being stored or the accumulation of a lot of log files. Isolating /var/log to its own partition now helps keep XS from crashing in case it fills up. Before, /var/log was just another subdirectory on the system "/" partition and inevitably resulted in a system crash when the partition became 100% full. A separate UEFI boot area was also added. Plus, the Linux swap space was assigned to its own partition. In short, there was no reason not to make use of more space and provide an improved partitioning scheme that would also scale better for larger pools containing a lot of VMs.
Note: One idiosyncrasy of XS 6.5 SP1 is that it switched to a GUID partition table in order to use more than 2 TB of local storage if available, but this has evidently been undone in 7.0 since GPT is no longer limited as such when running a 64-bit OS based on CentOS 7.
Note: There are changes in the minimum host physical system requirements, including a recommended minimum of 46 GB of disk space. This will impact environments that used smaller partitions or SSDs for the XS OS.
Stage Complete: Level Up!
Well done – you've completed Part 1. In Part 2, I'll deal with the alternative to leveraging a clean install -- a true in-place upgrade procedure, and what issues may arise during and after the procedure.
Once again, I will reiterate that feedback is always appreciated and the XenServer forum is one good option. Errors, on the other hand, should be reported to the XenServer bugs site with as much information as possible to help the engineers understand and reproduce them.
----
Read in my feedly
Sent from my iPhone
No comments:
Post a Comment