|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Comment:
Changes (1)
View page history... {section} {column:width=65%} {column} {column:width=35%} [!icons^back-org-small.png|alt="back"! Upgrading to Sun xVM Ops Center 2.1|Upgrading to Sun xVM Ops Center 2.1] {column} {section} ---- {excerpt} h1. Upgrading to Sun xVM Ops Center 2.1 on RHEL 5.0 Systems If you are using Sun xVM Ops Center version 2.0, you can upgrade the Enterprise Controller and Proxy Controllers using an update bundle. The update bundle stops the services on the Enterprise Controller or Proxy Controller, then backs up the current data. The 2.1 packages are installed, and the Enterprise Controller or Proxy Controller services are restored to their initial state. If the upgrade fails, the installed 2.1 material will be removed, and the product will be reinstalled using the 2.0 installer. The Enterprise Controller or Proxy Controller will then be restored using the backup file. {panel:title=Contents} {toc:anchor=true|includePages=true} {panel} ---- h2. Before You Begin Acquire the Enterprise Controller and Proxy Controller update bundles and copy them to the appropriate systems. To get these bundles, contact Sun Support Services. When upgrading your Sun xVM Ops Center environment, you should upgrade the Enterprise Controller first, followed by the Proxy Controllers. Agents can be upgraded through the BUI once the Proxy Controller that manages them has been upgraded. To upgrade to Sun xVM Ops Center 2.1, the install directory that you used to install Sun xVM Ops Center 2.0 must be present. This directory is used to back out the upgrade changes if the upgrade fails. If you have removed this directory, it must be replaced. If the initial install media are no longer present, contact Sun Support Services to replace them. ---- |
| h2. Performing the Upgrade When upgrading your Sun xVM Ops Center environment, you should upgrade the Enterprise Controller first, followed by the Proxy Controllers. Agents can be upgraded through the BUI or manually once the Proxy Controller that manages them has been upgraded. |
| Upgrade log files are stored in the {{/var/scn/update-saved-state}} directory on the Enterprise Controller. |
h3. Upgrading an Enterprise Controller |
... You can upgrade an Enterprise Controller to the 2.1 version of Sun xVM Ops Center. The co-located Proxy Controller will be upgraded as well. This procedure requires root access. If an error occurs during this process, the system will be restored to version 2.0. *Note* -- At the beginning of the upgrade process, the Enterprise Controller will be shut down. This might cause any jobs that are currently running on the Enterprise Controller to be canceled and marked as failed. # Create a temporary directory on your system, then copy or move the update bundle to the temporary directory that you created. The Enterprise Controller upgrade requires 5G of free space. {code} # mkdir /var/tmp/xVM/update # cp enterprise-controller-2.1.0.900-SunOS_sparc.tar.gz /var/tmp/xVM/update {code} # Change to the directory containing the update bundle. {code} # cd /var/tmp/xVM/update {code} # Use the {{gunzip}} and {{tar}} commands to uncompress and un-{{tar}} the update bundle. Note that the following command example retains the original compressed archive file. {code} # gunzip enterprise-controller-Linux.i686.2.1.0.900.tar.gz # tar xf enterprise-controller-Linux.i686.2.1.0.900.tar {code} # Change to the {{xvmoc_full_bundle}} directory and run the {{install}} script. {code} # cd xvmoc_full_bundle # ./install --install <location of Sun xVM Ops Center 2.0> {code} The following options may be used with the {{install}} script: || Option || Option (Shortened) || Result || Default Without Option || | {{--acceptedlicense}} | {{-a}} | Accepts the license terms and conditions. | Display terms and conditions, and prompt for acceptance | | {{--install <install bundle path>}} | {{-i <install bundle path>}} | (Required option) Use the Sun xVM Ops Center 2.0 data at <location of Sun xVM Ops Center 2.0>. This allows the system to be rolled back in case of error. | (No default) | | {{--verbose}} | {{-v}} | Increase verbosity of output from update program. | Non-verbose output | You must accept the license terms and conditions to complete the upgrade. When the upgrade is complete, the install script indicates that all Sun xVM Ops Center components have been upgraded to version 2.1. # Restart or Shift-Reload your browser if it is running. Cached data from the earlier version can cause Sun xVM Ops Center to display incorrectly. Refreshing or logging out and logging in will not clear this data. h3. Upgrading a Proxy Controller Once you have upgraded your Enterprise Controller, you can upgrade any Proxy Controllers. The co-located Proxy Controller, if enabled, is upgraded along with the Enterprise Controller, but separate Proxy Controllers must be upgraded separately. This procedure requires root access. If an error occurs during this process, the system will be restored to version 2.0. # Create a temporary directory on your system, then copy or move the update bundle to the temporary directory that you created. The Proxy Controller upgrade requires 2G of free space. {code} # mkdir /var/tmp/xVM/update # cp proxy-controller.Linux.i686.2.1.0.900.tar.gz /var/tmp/xVM/update {code} # Change to the directory containing the update bundle. {code} # cd /var/tmp/xVM/update {code} # Use the {{gunzip}} and {{tar}} commands to uncompress and un-{{tar}} the update bundle. Note that the following command example retains the original compressed archive file. {code} # gunzip proxy-controller.Linux.i686.2.1.0.900.tar.gz # tar xf proxy-controller.Linux.i686.2.1.0.900.tar {code} # Change to the {{xvmoc_update_bundle}} directory and run the {{update.pl}} script. {code} # cd xvmoc_update_bundle # ./update.pl --install <location of Sun xVM Ops Center 2.0> {code} The following options may be used with the {{update.pl}} script: || Option || Option (Shortened) || Result || Default Without Option || | {{--acceptedlicense}} | {{-a}} | Accepts the license terms and conditions. | Display terms and conditions and prompt for acceptance | | {{--install <install bundle path>}} | {{-i <install bundle path>}} | (Required option) Use the Sun xVM Ops Center 2.0 data at <location of Sun xVM Ops Center 2.0>. This allows the system to be rolled back in case of error. | (No default) | | {{--verbose}} | {{-v}} | Increase verbosity of output from update program. | Non-verbose output | You must accept the license terms and conditions to complete the upgrade. When complete, the update.pl script indicates that all Sun xVM Ops Center components have been upgraded to version 2.1. h3. Upgrading Agents Using the User Interface Agents can be upgraded using the BUI. Before you upgrade an Agent, you must upgrade the Proxy Controller that manages it. # Log in to the BUI. # Select Administration in the Navigation panel. # Select Agent Controllers in the Center panel. # Select the Agents, then click the Upgrade to Latest Available Version icon. The Upgrade Agents window is displayed. # Select a method of providing credentials for the system or systems to be upgraded. #* The Re-use SSH Credentials Used During Discovery for the Selected Hosts option uses the same credentials used to discover the systems. *Note* -- If you did not save the discovery credentials for a system, or if you manually installed an Agent on a system, it will not have stored criteria. #* The Apply the Same SSH Credentials to All option prompts you for a single set of SSH credentials for all systems to be upgraded. #* The Enter SSH credentials For Each of the Selected Hosts prompts you for a separate set of credentials for each system to be upgraded. # Click Submit. A popup appears confirming that the job has been launched. # Click Ok. The Agent or Agents are upgraded. h3. Upgrading Agents Manually Agents can be upgraded manually or through the BUI. For an Agent to be upgraded, its Proxy Controller must be upgraded first. This procedure requires root access. # Stop the 2.0 agent. For example, on Solaris 8 or Solaris 9 Agents: {code} # sh /etc/init.d/SUNWscn_update_agent stop # /usr/sbin/cacaoadm -i scn-agent stop {code} On Solaris 10 Agents: {code} # svcadm disable svc:/application/scn/update-agent:default # svcadm disable svc:/application/management/common-agent-container-1:scn-agent {code} On Linux Agents: {code} # /etc/init.d/sun_scn_update_agent stop # /etc/init.d/common-agent-container-1 stop {code} # Copy the new agent bundle from the Enterprise Controller to the client and extract it. For example, on Solaris Agents: {code} # scp -p <IP of Enterprise Controller>:/var/opt/sun/xvm/images/agent/SunConnectionAgent.`uname -s`.`uname -p`.2.1.0.908.zip /var/tmp # cd /var/tmp # unzip SunConnectionAgent.`uname -s`.`uname -p`.2.1.0.908.zip {code} On Linux Agents: {code} # scp -p <IP of Enterprise Controller>:/var/opt/sun/xvm/images/agent/SunConnectionAgent.`uname -s`.i686.2.1.0.908.zip /var/tmp # cd /var/tmp # unzip SunConnectionAgent.`uname -s`.i686.2.1.0.908.zip {code} # Install the agent update. {code} # cd /var/tmp/SunConnectionAgent # sh ./install {code} # Copy the xVMOC Proxy Controller authentication token to the client: {code} # ssh root@<IP of Proxy Controller> cat /var/opt/sun/xvm/persistence/scn-proxy/connection.properties | sed -n -e 's;\\;;g' -e 's/^auto-reg-token=\(.*\)/\1/p' > /var/tmp/proxy_token.txt {code} *Note* -- The sed grabs only the value of the auto-reg-token parameter, and strips out all \ (backslash) characters. If you prefer, you can do that by hand and copy the result to {{/var/tmp/proxy_token.txt}}. # Configure the new Sun xVM Ops Center agent. For example, on Solaris agents: {code} # /opt/SUNWxvmoc/bin/agentadm configure -t /var/tmp/proxy_token.txt -x $<IP of Proxy Controller> -a $<IP of client primary hostname> {code} On Linux agents: {code} /opt/sun/xvmoc/bin/agentadm configure -t /var/tmp/proxy_token.txt -x $<IP of Proxy Controller> -a $<IP of client primary hostname> {code} This step also starts the agent. *Note* -- The following errors may safely be ignored. These refer to the addition of two {{sysidcfg}} scripts, which are already present from a prior {{agentadm configure}} step, such as from the original Sun xVM Ops Center 2.0 agent installation and configuration. The correct {{sysidcfg}} scripts will still be called properly by {{sysidcfg}}. {code} Failed to add the zone configuration automation. Failed to add the service tags recreate script. {code} *Note* -- On systems with zones, you should complete this step on the global zones before completing it on the local zones. # Verify the connection. {code} # sc-console list-connections scn-agent https://172.25.14.21:21165 urn:scn:clregid:1234567-aaaa-bbbb-cccc-123456789abc:YYYYMMDDHHMMSSss {code} ---- h2. Updating DHCP Settings After a system is upgraded to 2.1, OS provisioning jobs will silently fail to update DHCP. The DHCP configuration for each Proxy must be reset. *Note* -- This procedure must be performed for each Proxy Controller. # Log in to the BUI. # Click Administration in the Navigation Panel. # Select a Proxy Controller. # Click DHCP Config. The DHCP Configuration window is displayed. # Click Save Config. OS Provisioning jobs can now be performed. ---- h2. Known Issues There are three known issues involving the update process. Workaround procedures are described below. h3. Acquiring Update Bundles on Linux There is a known issue for Enterprise Controllers installed on Linux that prevents the update bundles from being downloaded directly. To acquire the update bundles, contact Sun Support Services. h3. Upgrading Proxy Controllers on Linux There is a known issue for some Proxy Controllers installed on Linux. Proxy Controllers with multiple network interfaces might not show all of the NICs in the Administration section of the BUI. Follow the procedure below to ensure that your Proxy Controllers are configured properly. This procedure requires root access. # Log on to the Proxy Controller. # Use the {{/opt/SUNWscnosp/sbin/as_dhcp_config.pl}} utility to configure DHCP. For example, on a system with interface e1000g0: {code} # /opt/SUNWscnosp/sbin/as_dhcp_config.pl -e -I e1000g0 -S isc {code} On a system with multiple interfaces: {code} /opt/SUNWscnosp/sbin/as_dhcp_config.pl -e -I 'e1000g0 e1000g1' -S isc {code} h3. Upgrading Manually Installed Agents There is a known issue that affects manually installed 2.0 Agents, preventing them from being automatically upgraded from the User Interface. If you manually installed Agents, then you will need to either manually upgrade the agents, or perform an SSH discovery of the Operating System for each client so that the upgrade using the BUI will function properly. To perform an Operating System discovery, follow this procedure: # Select Gear in the Navigation panel. # Click Custom Discovery in the Actions panel. # Create new criteria that include the gear with manually installed agents by clicking the Add Criteria icon. ## {expand:Enter new criteria, including:} !Custom Discovery^CustomDiscoveryWizard3-Top.jpg|alt="Top of Custom Discovery wizard"!{expand} ##* Criteria name If you check Save criteria for future use, the criteria will be saved under this name. ##* One or more IP addresses to scan These can be entered as a comma-separated list, an IP range specified by _starting address_-_end address_, or a subnet specified by _network address_/_bit mask_. ##* One or more Host names to scan All host names must be resolvable by the Enterprise Controller. ##* (Optional) A service tag passphrase Required if a service tag has been configured to be encrypted. ##* (Optional) A service tag port Required if a service tag has been configured to use a port other than the default of 6481. ##* (Optional) A service tag timeout The default value is 20 seconds. ##* The type of gear to target {expand:Specifying a type of gear will restrict the list of available discovery credential types.} !Custom Discovery^CustomDiscoveryWizard5-BottomSolaris.jpg|alt="Bottom of Custom Discovery wizard, showing Solaris as the gear type and ssh credentials"!{expand} {expand:To view all discovery credentials or discover multiple types of gear, select All.} !Custom Discovery^CustomDiscoveryWizard4-BottomAll.jpg|alt="Bottom of Custom Discovery wizard, showing all credentials"!{expand} ##* The discovery protocol or protocols to use and their credentials If you check Also Use Default Credentials, then Sun xVM Ops Center may use default credentials, including root credentials, in addition to those specified. If you select SSH, two sets of credentials can be entered. To use root credentials, enter the root credentials as the first set. To log in as a non-root user and then switch to root, enter the non-root credentials as the first set and the root credentials as the second set. ## (Optional) Check Save Criteria for Future Use to save the criteria for future use. ## (Optional) Check Save Password to save the passwords associated with discovery criteria. ## Click Save. # {expand:Select one or more discovery criteria.} !Custom Discovery^CustomDiscoveryWizard6-Done.jpg|alt="Completed wizard showing criteria selection."!{expand} # Click Discover Gear and wait for the discovery job to complete before upgrading your instance of Sun xVM Ops Center. {excerpt} ---- {panel:borderStyle=none|titleBGColor=#BDBEC0|bgColor=#f5f5f5} *Where to Go From Here* See [Obtaining Sun xVM Ops Center Software] for information about getting the software. See [Uninstalling Sun xVM Ops Center Software] to perform a clean uninstall, and then [Installation] for the steps to install the latest release. {panel} |