Upgrading to Oracle VM Server for SPARC 3.1 using Solaris 11.1

The previous blog entry described new features in Oracle VM Server for SPARC 3.1, and I commented that it was "really easy" to upgrade. In this blog I'll show the actual steps used to do the upgrade.

The Plan

Oracle VM Server for SPARC 3.1 is delivered in Solaris 11.1 SRU 10.5, and includes device driver improvements used in service domains and guests, so the primary task is to update each domain to the new SRU.

Additionally, the domain setting ldm set-domain extended-mapin-space=on needs to be set for service and guest domains. The command improves performance by enlarging a shared I/O buffer and reducing buffer copying during network I/O. This option requires rebooting the domain being changed, so it should be scheduled with the reboot needed to implement the updated Solaris version.

Check the current version

First thing I did was simply check which version of Solaris 11 was already running on each domain. On the control domain, I also displayed the version of the Oracle VM Server for SPARC 3.1 logical domains manager.

# pkg info entire
          Name: entire
       Summary: entire incorporation including Support Repository Update (Oracle Solaris 11.1.8.4.0).
   Description: This package constrains system package versions to the same
                build.  WARNING: Proper system update and correct package
                selection depend on the presence of this incorporation.
                Removing this package will result in an unsupported system.  For
                more information see https://support.oracle.com/CSP/main/article
                ?cmd=show&type=NOT&doctype=REFERENCE&id=1501435.1.
      Category: Meta Packages/Incorporations
         State: Installed
     Publisher: solaris
       Version: 0.5.11 (Oracle Solaris 11.1.8.4.0)
 Build Release: 5.11
        Branch: 0.175.1.8.0.4.0
Packaging Date: May 31, 2013 08:34:15 PM 
          Size: 5.46 kB
          FMRI: pkg://solaris/entire@0.5.11,5.11-0.175.1.8.0.4.0:20130531T203415Z
# ldm -V

Logical Domains Manager (v 3.0.0.3)
        Hypervisor control protocol v 1.7
        Using Hypervisor MD v 1.4

System PROM:
        Hypervisor      v. 1.10.7       @(#)Hypervisor 1.10.7 2012/03/14 09:27\015
        OpenBoot        v. 4.33.6       @(#)OpenBoot 4.33.6 2012/03/14 08:07

Upgrading

The nest step is to update Solaris. You should be pointing to the Oracle support repository or a local mirror you may have inside your company (this is common for systems that don't have external Internet access). The pkg publisher command shows which publishers are in use. Installing the software into a new boot environment takes just one command:
# pkg update
            Packages to remove:   1
            Packages to update: 161
           Mediators to change:   1
       Create boot environment: Yes
Create backup boot environment:  No

DOWNLOAD                                PKGS         FILES    XFER (MB)   SPEED
Completed                            162/162     6214/6214  327.6/327.6  2.6M/s

PHASE                                          ITEMS
Removing old actions                       1022/1022
Installing new actions                     2374/2374
Updating modified actions                  6895/6895
Updating package state database                 Done 
Updating package cache                       162/162 
Updating image state                            Done 
Creating fast lookup database                   Done 

A clone of solaris-1 exists and has been updated and activated.
On the next boot the Boot Environment solaris-2 will be
mounted on '/'.  Reboot when ready to switch to this updated BE.

---------------------------------------------------------------------------
NOTE: Please review release notes posted at:

http://www.oracle.com/pls/topic/lookup?ctx=E26502&id=SERNS
---------------------------------------------------------------------------

The update process mades the new OS boot environment active on the next boot. In the listing below, N indicates the boot environment in use now, and R indicates the one that will be used after a reboot. After reboot, we can easily revert to the previous environment by issuing beadm activate solaris-3 followed by a reboot.

# beadm list
BE               Active Mountpoint Space  Policy Created          
--               ------ ---------- -----  ------ -------          
solaris-1        -      -          35.94M static 2012-10-31 10:52 
solaris-2        -      -          6.08M  static 2013-04-02 13:41 
solaris-3        N      /          2.79M  static 2013-06-27 13:16 
solaris-4        R      -          11.49G static 2013-08-15 13:52  

Reboot to activate the update

Now, perform an init 6, and after reboot:
# pkg info entire
          Name: entire
       Summary: entire incorporation including Support Repository Update (Oracle Solaris 11.1.10.5.0).
   Description: This package constrains system package versions to the same
                build.  WARNING: Proper system update and correct package
                selection depend on the presence of this incorporation.
                Removing this package will result in an unsupported system.  For
                more information see https://support.oracle.com/CSP/main/article
                ?cmd=show&type=NOT&doctype=REFERENCE&id=1501435.1.
      Category: Meta Packages/Incorporations
         State: Installed
     Publisher: solaris
       Version: 0.5.11 (Oracle Solaris 11.1.10.5.0)
 Build Release: 5.11
        Branch: 0.175.1.10.0.5.0
Packaging Date: August  5, 2013 04:03:17 PM 
          Size: 5.46 kB
          FMRI: pkg://solaris/entire@0.5.11,5.11-0.175.1.10.0.5.0:20130805T160317Z
# ldm -V

Logical Domains Manager (v 3.1.0.0.24)
        Hypervisor control protocol v 1.7
        Using Hypervisor MD v 1.4

System PROM:
        Hypervisor      v. 1.10.7       @(#)Hypervisor 1.10.7 2012/03/14 09:27\015
        OpenBoot        v. 4.33.6       @(#)OpenBoot 4.33.6 2012/03/14 08:07

This took only a few minutes, and I only had to issue a few commands, and we're on Oracle VM Server for SPARC 3.1.

Set extended-mapin-space option

There is another step. What if I have existing domains with extended-mapin-space set to "off"? Turning this on is important for performance. The default is now on for new domains, but may have to be set for existing ones - which includes the primary domain. Note: this option was available in previous releases of Oracle VM Server for SPARC, so it might have been turned on already.

# ldm list -l primary
NAME             STATE      FLAGS   CONS    VCPU  MEMORY   UTIL  UPTIME
primary          active     -n-cv-  SP      16    8G       0.5%  6d 4h 22m

SOFTSTATE
Solaris running
UUID
    c80395bf-d12b-65ac-a871-b91b2fcd1335
MAC
    00:21:28:15:fb:ee
HOSTID
    0x8515fbee
CONTROL
    failure-policy=ignore
    extended-mapin-space=off
    cpu-arch=native
    rc-add-policy=
    shutdown-group=0
... snip ...
On this system this option remains turned off. My fault for not having planned ahead, as I could have done this before the previous reboot, but I'll do it now:
# ldm set-domain extended-mapin-space=on primary
Initiating a delayed reconfiguration operation on the primary domain.
All configuration changes for other domains are disabled until the primary
domain reboots, at which time the new configuration for the primary domain
will also take effect.
# init 6
When we return, the system is running the current version of Solaris 11.1, the latest version of Oracle VM Server for SPARC, and we've turned on the one setting we needed. It only cost me a few minutes, but I won't make that mistake on the other servers.

To complete the job, just repeat the Solaris update, set extended-mapin-space, and reboot, on each of your domains. Note how Solaris 11 makes it so easy to upgrade to the latest update level.

With Oracle VM Manager

I run some servers under Oracle VM Manager. The update procedure is identical, but the manager provides a nice operational advantage. Before I reboot the control domain, I place the server in "maintenance mode" in the Oracle VM Manager user interface. That causes guests to be live migrated to another server in the same pool. The Manager migrates them without any further intervention on my part. When the server is evacuated I reboot the control domain. When the control domain is up again, I take the server out of maintenance mode so the Manager can freely use it for deploying guests. With very little effort I repeated this process for each lab server I work with.

Summary

Updating to Oracle Solaris 11.1 to include Oracle VM Server for SPARC 3.1 takes little effort - it only requires a few commands and a few minutes per server. The commands needed to do this can be as few as three commands per domain:
Issued from control domain for every domain, including primary - if not already turned on, of course
# ldm set-domain extended-mapin-space=on domainname
Issued within each domain
# pkg update
# init 6
After the upgrade is complete, Oracle VM Server provides improved performance and flexibility. A similar update will be provided as a patch for Solaris 10. This will provide the same benefits, using a slightly different procedure for Solaris update.

Note: If we've configured for availability with a second service domain as illustrate in this blog post, we can perform the upgrade with continuous availabilty to guest domains. They continue operation while the control domain is rebooting. You can then update each service domain in turn for a "rolling upgrade" that lets you update your system without any outages.

Comments:

What is the impact on the running LDOMs while performing this update?
Do they need to come down, migrate to another CDOM?

Posted by guest on September 20, 2013 at 10:55 AM MST #

I didn't bother stopping or migrating them on all the systems I upgraded, but I went to the doc to make sure I wasn't doing the wrong thing :-)

Look at the section in the Admin Guide "Upgrading a System That Is Already Using Oracle VM Server for SPARC" at http://docs.oracle.com/cd/E38405_01/html/E38406/upgradeldomssystem.html#scrolltoc, especially the page at http://docs.oracle.com/cd/E38405_01/html/E38406/upgradingldomsmgrandsystemfirmware.html#scrolltoc which describes how to stop all the domains except the control domain, but says

"Perform this task only if you plan to perform a power cycle of the system or upgrade the firmware. Performing this task is not required if you are only upgrading the Logical Domains Manager software."

Certainly there's never any effect while installing the software into a new boot environment, and I recommend saving the configuration to the service processor, and backing up the configuration as described elsewhere in the same chapter of the Admin Guide, but there doesn't seem to be a requirement to shut the domains down or migrate them during the upgrade. You certainly can do either of those if you choose to.

Note that during a reboot of the control domain, the virtual devices it provides would be unavailable, as is always the case even without an upgrade. You can avoid any application outage by using the availability methods mentioned in the Admin Guide and in the July blog articles here.

I hope that helps! regards, Jeff

Posted by Jeff on September 22, 2013 at 09:10 PM MST #

Post a Comment:
Comments are closed for this entry.
About

jsavit

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today