Results 1 to 5 of 5

Thread: SLES upgrade dilemma

  1. #1

    SLES upgrade dilemma

    Hi guys

    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

    1) 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.

    2) 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

  2. #2

    Re: SLES upgrade dilemma

    Quote Originally Posted by stevenau1 View Post
    Hi guys

    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

    1) 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.

    2) 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
    Hi and welcome to the SUSE forums.

    I prefer your option #2 and here's why:

    • 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.
    Kevin Boyle - Knowledge Partner
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below this post. Thanks.

  3. #3

    Re: SLES upgrade dilemma

    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

  4. #4

    Re: SLES upgrade dilemma

    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??

    Thank you

  5. #5

    Re: SLES upgrade dilemma

    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:

    XFS => xfsdump/xfsrestore:
    https://forums.suse.com/showthread.p...7862#post57862

    BTRFS => System Recovery and Snapshot Management with Snapper
    https://forums.suse.com/showthread.p...7836#post57836

    Or use a dedicated vm snapshot for the root partition. Big updates should be tested on a test server before deliver to a production server...
    Last edited by AndreasMeyer; 22-Jun-2019 at 16:33.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •