Will be migrating some SLES11 physical hosts to vmâs in the near future and Iâm wondering what is the best approach. Upgrading the OS is also required. Have considered the following options
migrate as is. Then upgrade to SLES12SP4 once on vmâs. Like this idea, have the safety of vm snapshots in case of upgrade issues. Can upgrade to SLES15 at a later date.
build new SLES15 vmâs and migrate data. Read itâs better to build new vm rather than upgrading but this brings in a lot of potential issues with OS settings like application tuning, security settings, local accounts etc as something may be missed.
These are mission critical servers so canât afford mishaps.
Will be migrating some SLES11 physical hosts to vmâs in the near future and Iâm wondering what is the best approach. Upgrading the OS is also required. Have considered the following options
migrate as is. Then upgrade to SLES12SP4 once on vmâs. Like this idea, have the safety of vm snapshots in case of upgrade issues. Can upgrade to SLES15 at a later date.
build new SLES15 vmâs and migrate data. Read itâs better to build new vm rather than upgrading but this brings in a lot of potential issues with OS settings like application tuning, security settings, local accounts etc as something may be missed.
These are mission critical servers so canât afford mishaps.
All suggestions appreciated.
Thanks[/QUOTE]
Hi and welcome to the SUSE forums.
I prefer your option #2 and here’s why:
[LIST]
[]Your option #1 would require as much work to get SLES 12 SP4 installed as it would to get SLES 15 installed (option #2), then you would still have to upgrade to SLES 15.
[]When you upgrade an existing system, it’s important that the upgrade doesn’t break anything. When new features involve major architectural changes it may be too complex or too risky to attempt a retrofit on a production server so the upgrade may not upgrade a specific feature and continue to use what is already installed. If you have been doing in-place upgrades over many versions you may have a number of old features left in place from long ago.
[]Option two will create a new install giving you access to all new features.
[]You have the option to make configuration changes you couldn’t do on a production system: file systems, partition sizes, etc.
[*]Your original server continues to function while you install and test your new VM(s), and, should your cut over encounter issues, the old physical server is still available for a quick fallback.
[/LIST]
Hi Kevin
That approach does make a lot of sense. Might as well go through the pain once rather than twice and have the system setup the way you want it.
Thanks
Another question I have regarding upgrades in SLES.
What fail safe âback outâ methods are the most common when performing OS upgrades?
In AIX I can use the rootvg unmirror disk concept to quickly boot back to my pre upgrade version in case of problems.
Some of my VMâs are huge so cannot perform snapshot backups. Using rear restore is too drastic and not without its own occasional issues so what âsimpleâ method can I use to guarantee fast fail back when encountering OS upgrade issues??
The root partition “/” (where operating system and all programs are installed) should be a XFS or BTRFS file system. The root partition is not really big, so a full backup and restore is not a big time consuming job: