You might encounter problems while migrating from an older version of WebSphere® Application Server.
profileName: profileName cannot be empty profilePath: Insufficient disk space
These error messages might be displayed if you enter a profile name that contains an invalid character such as a space. Rerun the Migration wizard, and verify that there are no invalid characters in the profile name such as a space, quotes, or any other special characters.
If MIGR0286E: The migration failed to complete is displayed, attempt to correct any problems based on the error messages that appear in the log file. After correcting any errors, rerun the command from the bin directory of the product installation root.
ExtendedMessage: BBOO0221W: WSVR0022W: The value, {CLOUDSCAPE_JDBC_DRIVER_PATH}/db2j.jar, with Resource ID, DataSource_1000001, located at file:/WebSphere/V6R1/AppServer/profiles/default/config/cells/ <cell_name>/nodes/<node_name>/servers/<server_name> /resources.xml has an invalid variableYou can safely ignore this error until you have finished migrating all of your nodes. After you have migrated all the nodes from Version 5.1 or Version 6.0, and no longer need support for a cell-level Cloudscape database (for older release nodes), you can delete the custom property CloudscapeOldDBPath in your cell-level Derby databases that points to ${CLOUDSCAPE_JDBC_DRIVER_PATH}/db2j.jar.
This command results in a display of all objects in WebSphere Application Server's namespace, including the directory path and object name.
This produces a very large trace file; for example, it can exceed 1 GB for the WASPostUpgrade command.
This is the default.
If you do not specify the -traceString or -traceFile parameter, the command creates a trace file by default and places it in the backupDirectory/logs directory.
If you specify this parameter, you must also specify the -traceFile parameter.
If you do not specify the -traceString or -traceFile parameter, the command creates a trace file by default and places it in the backupDirectory/logs directory.
If you specify the -traceString parameter but do not specify the -traceFile parameter, the script does not generate a trace file.
See the "Tracing and logging configuration" article for information on configuring your tracing and logging settings to help diagnose problems.
For current information available from IBM® Support on known problems and their resolution, read the IBM Support page. IBM Support also has documents that can save you time gathering information needed to resolve this problem. Before opening a PMR, read the IBM Support page.
This problem can occur if you are trying to run the WASPreUpgrade tool from a directory other than the WebSphere Application Server Version 7.0 app_server_root\bin. Verify that the WASPreUpgrade script resides in the Version 7.0 app_server_root\bin directory, and launch the file from that location.
The administrative console no longer displays deprecated JDBC provider names. The new JDBC provider names used in the administrative console are more descriptive and less confusing. The new providers will differ only by name from the deprecated ones.
The deprecated names will continue to exist in the jdbc-resource-provider-templates.xml file for migration reasons (for existing JACL scripts for example); however, you are encouraged to use the new JDBC provider names in your JACL scripts.
MIGR0108E: The specified WebSphere directory does not contain a WebSphere version that can be upgraded.
This message indicates that you are running the WebSphere Application Server Version 5.1 migration utility, not the Version 7.0 migration utility.
MIGR0201I: The migration function initialized log file WASPreUpgrade.log. MIGR0300I: The migration function is starting to save the existing Application Server environment. MIGR0302I: The existing files are being saved. MIGR0303I: The existing Application Server environment is saved. MIGR0420I: The first step of migration completed successfully.but you might see a message similar to the following in the migration trace file:
[10/9/08 18:26:40:363 CDT] 00000000 Save 1 Skipped instance dmgr01 because user root /opt/migration_backup/profiles/dmgr01 does not exist.
The WASPreUpgrade tool writes out a copy of a profileList.ser file that contains pointers to the backup directory to be used by the WASPostUpgrade tool. If that file is not subsequently deleted by migration for any reason, the old paths are used instead of the real paths when you run the WASPreUpgrade tool in later migrations. To resolve this issue, you can safely delete the profileList.ser file and rerun the WASPreUpgrade tool.
Read for more information.
MIGR0304I: The previous WebSphere environment is being restored. MIGR0367I: Backing up the current Application Server environment. CEIMI0006I Starting the migration of Common Event Infrastructure. MIGR0486I: The Transports setting in file server.xml is deprecated. MIGR0486I: The PMIService:initialSpecLevel setting in file server.xml is deprecated. MIGR0486I: The PMIService:initialSpecLevel setting in file server.xml is deprecated. MIGR0404W: Do not use the node agent in the old configuration. It has been disabled. MIGR0351I: The migration function is attempting to synchronize with the deployment manager using the SOAP protocol. MIGR0241I: Output of syncNode. ADMU0116I: Tool information is being logged in file /usr/WAS70/profiles/AppSrv01/logs/syncNode.log ADMU0128I: Starting tool with the AppSrv01 profile ADMU0401I: Begin syncNode operation for node aaixae15aNode01 with Deployment Manager packppc.rtp.raleigh.ibm.com: 8879 ADMU0016I: Synchronizing configuration between node and cell. AWXJR0006E The file, /usr/WAS70/java/jre/PdPerm.properties, was not found. ArchiveUtil.toLocalURLs ArchiveUtil.toLocalURLs ArchiveUtil.toLocalURLs ADMU0402I: The configuration for node aaixae15aNode01 has been synchronized with Deployment Manager packppc.rtp.raleigh.ibm.com: 8879 MIGR0352I: The synchronization with the deployment manager is successful. CEIMI0007I The Common Event Infrastructure migration is complete. MIGR0307I: The restoration of the previous Application Server environment is complete. MIGR0271W: Migration completed successfully, with one or more warnings.This exception occurs during the syncNode operation, and it is listed as an error; but it does not cause any failures. The overall action completes successfully, and the message does not reoccur. After the server on the migrated federated node is started, the file in question is regenerated. You can ignore this message.
This problem can occur if you are trying to run the WASPostUpgrade tool from a directory other than the WebSphere Application Server Version 7.0 app_server_root\bin. Verify that the WASPostUpgrade script resides in the Version 7.0 app_server_root\bin directory, and launch the file from that location.
MIGR0102E: Invalid Command Line. MIGR0105E: You must specify the primary node name.
The most likely cause of this error is that WebSphere Application Server Version 5.1.x or Version 6.x is installed and the WASPostUpgrade tool was not run from the bin directory of the Version 7.0 installation root.
To correct this problem, run the WASPostUpgrade command from the bin directory of the WebSphere Application Server Version 7.0 installation root.
MIGR0304I: The previous WebSphere environment is being restored. com.ibm.websphere.management.exception.RepositoryException: com.ibm.websphere.management.exception.ConnectorException: ADMC0009E: The system failed to make the SOAP RPC call: invoke MIGR0286E: The migration failed to complete.
profile_root/properties
com.ibm.SOAP.requestTimeout=1800
backupDirectory/profiles/profile_name/properties
wsadmin -f application_script -conntype NONE
MIGR0304I: The previous WebSphere environment is being restored. java.lang.Exception: org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Class 'WASQueueConnectionFactory' not found. (file:app_server_root/config/cells/cell_name/nodes/node_name/resources.xml, 7, 221) MIGR0286E: The migration failed to complete.
An incomplete or unsuccessful installation of internal messaging on the target node might cause the migration to fail in this way. If your resources.xml file is corrupted by a failed internal-messaging installation, for example, the file might not include the namespace information that the WebSphere Common Configuration Model (WCCM) needs during WASPostUpgrade command processing.
xmlns:xmi="http://www.omg.org/XMI" xmlns:resources.jms="http://www.ibm.com/websphere/appserver/schemas/5.1/resources.jms.xmi" xmlns:resources.j2c="http://www.ibm.com/websphere/appserver/schemas/5.1/resources.j2c.xmi" xmlns:resources="http://www.ibm.com/websphere/appserver/schemas/5.1/resources.xmi" xmlns:resources.jms.internalmessaging="http://www.ibm.com/websphere/appserver/schemas/5.1/ resources.jms.internalmessaging.xmi" xmlns:resources.mail="http://www.ibm.com/websphere/appserver/schemas/5.1/resources.mail.xmi" xmlns:resources.url="http://www.ibm.com/websphere/appserver/schemas/5.1/resources.url.xmi"
xmlns:xmi="http://www.omg.org/XMI" xmlns:resources.jms="http://www.ibm.com/websphere/appserver/schemas/5.1/resources.jms.xmi" xmlns:resources.j2c="http://www.ibm.com/websphere/appserver/schemas/5.1/resources.j2c.xmi" xmlns:resources="http://www.ibm.com/websphere/appserver/schemas/5.1/resources.xmi" xmlns:resources.jms.internalmessaging="http://www.ibm.com/websphere/appserver/schemas/5.1/ resources.jms.internalmessaging.xmi" xmlns:resources.mail="http://www.ibm.com/websphere/appserver/schemas/5.1/resources.mail.xmi" xmlns:resources.url="http://www.ibm.com/websphere/appserver/schemas/5.1/resources.url.xmi"
MIGR0304I: The previous WebSphere environment is being restored. com.ibm.websphere.management.exception.DocumentIOException: Unable to copy document to temp file: cells/sunblade1Network/applications/LARGEApp.ear/LARGEApp.ear
Your file system might be full. If your file system is full, clear some space and rerun the WASPostUpgrade command.
MIGR0108E: The specified WebSphere directory does not contain WebSphere version that can be upgraded.
This message indicates that you are running the WebSphere Application Server Version 7.0 migration utility.
MIGR0253E: The backup directory migration_backup_directory does not exist.
Read WASPreUpgrade command for more information.
For example, the directory might have been a subdirectory of the Version 5.1.x or Version 6.x tree that was deleted after the WASPreUpgrade tool was run and the older version of the product was uninstalled but before the WASPostUpgrade tool was run.
During the course of a deployment manager or a federated node migration, WASPostUpgrade might disable the old environment. If after running WASPostUpgrade you want to run WASPreUpgrade again against the old installation, you must run the migrationDisablementReversal.jacl script located in the old app_server_root/bin directory. After running this JACL script, your Version 5.1.x or Version 6.x environment will be in a valid state again, allowing you to run WASPreUpgrade to produce valid results.
/websphere70/appserver/profiles/dm_profile/temp/nodeX_migration_temp
The logs and everything else involved in the migration for this node on the deployment manager node are located in this folder. This folder will also be required for IBM support related to this scenario.
If any of the Version 7.0 applications fail to install during a federated migration, they will be lost during the synchronizing of the configurations. The reason that this happens is that one of the final steps of WASPostUpgrade is to run a syncNode command. This has the result of downloading the configuration on the deployment manager node and overwriting the configuration on the federated node. If the applications fail to install, they will not be in the configuration located on the deployment manager node. To resolve this issue, manually install the applications after migration. If they are standard Version 7.0 applications, they will be located in the app_server_root/installableApps directory.
To manually install an application that was lost during migration, use the wsadmin command to run the install_application_name.jacl script that the migration tools created in the backup directory.
./wsadmin.sh -f migration_backup_directory/install_application_name.jacl -conntype NONE
Manually install the applications using the wsadmin command after WASPostUpgrade has completed.
To manually install an application that failed to install during migration, use the wsadmin command to run the install_application_name.jacl script that the migration tools created in the backup directory.
./wsadmin.sh -f migration_backup_directory/install_application_name.jacl -conntype NONE
[date time] 0000000a CommandMetada 3 Exception caught java.lang.OutOfMemoryError: PermGen space
-XX:PermSize=64m -XX:MaxPermSize=256m
Read WASPostUpgrade command for more information.
MIGR0327E: A failure occurred with stopNode. MIGR0272E: The migration function cannot complete the command.
WebSphere Application Server Version 6.0.2 uses a Java Virtual Machine (JVM) in 32-bit mode. The Migration wizard for WebSphere Application Server Version 7.0 calls the WASPostUpgrade.sh script, which attempts to run the JVM for Version 6.0.2 in the 64-bit mode when the server stops the Version 6.0.2 node.
cd /opt/IBM/WebSphere/AppServer/bin
. "$binDir" /setupCmdLine.sh
JVM_EXTRA_CMD_ARGS=""
app_server_root/bin/manageprofiles.sh -delete -profileName profile_name
The migration hangs, and the trace files indicate that there are out-of-memory (OOM) occurrences. The stack trace is not shown in the log or trace.
The applications that exist in the Version 5.1.x or Version 6.x configuration might have incorrect deployment information—typically, invalid XML documents that were not validated sufficiently in previous WebSphere Application Server runtimes. The runtime now has an improved application-installation validation process and will fail to install these malformed EAR files. This results in a failure during the application-installation phase of WASPostUpgrade and produces an "E:" error message. This is considered a "fatal" migration error.
In this case, the migration process does not install the failing applications but does complete all of the other migration steps.
Later, you can fix the problems in the applications and then manually install them in the new Version 7.0 configuration using the administrative console or an install script.
Exception = java.lang.ClassNotFoundException Source = com.ibm.ws.cluster.selection.SelectionAdvisor.<init> probeid = 133 Stack Dump = java.lang.ClassNotFoundException: rule.local.server at java.net.URLClassLoader.findClass(URLClassLoader.java(Compiled Code)) at com.ibm.ws.bootstrap.ExtClassLoader.findClass(ExtClassLoader.java:106) at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code)) at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code)) at java.lang.Class.forName1(Native Method) at java.lang.Class.forName(Class.java(Compiled Code)) at com.ibm.ws.cluster.selection.rule.RuleEtiquette.runRules(RuleEtiquette.java:154) at com.ibm.ws.cluster.selection.SelectionAdvisor.handleNotification(SelectionAdvisor.java:153) at com.ibm.websphere.cluster.topography.DescriptionFactory$Notifier.run(DescriptionFactory.java:257) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1462)
Exception = java.io.IOException Source = com.ibm.ws.cluster.topography.DescriptionManagerA. update probeid = 362 Stack Dump = java.io.IOException at com.ibm.ws.cluster.topography.ClusterDescriptionImpl.importFromStream(ClusterDescriptionImpl.java:916) at com.ibm.ws.cluster.topography.DescriptionManagerA.update(DescriptionManagerA.java:360) Caused by: java.io.EOFException at java.io.DataInputStream.readFully(DataInputStream.java(Compiled Code)) at java.io.DataInputStream.readUTF(DataInputStream.java(Compiled Code)) at com.ibm.ws.cluster.topography.KeyRepositoryImpl.importFromStream(KeyRepositoryImpl.java:193)
During migration, Version 7.0 cluster information is distributed throughout the cell. Version 6.x nodes that are not at Version 6.0.2.11 or later fail to read this information.
To avoid this problem, upgrade all Version 6.x nodes that will be contained in or interoperating with a Version 7.0 cell to Version 6.0.2.11 or later before migrating your deployment managers to Version 7.0.
[5/11/06 15:41:23:190 CDT] 0000000a SystemErr R com.ibm.ws.exception.RuntimeError: com.ibm.ws.exception.RuntimeError: org.omg.CORBA.INTERNAL: CREATE_LISTENER_FAILED_4 vmcid: 0x49421000 minor code: 56 completed: No [5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at com.ibm.ws.runtime.WsServerImpl.bootServerContainer(WsServerImpl.java:198) [5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at com.ibm.ws.runtime.WsServerImpl.start(WsServerImpl.java:139) [5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at com.ibm.ws.runtime.WsServerImpl.main(WsServerImpl.java:460) [5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at com.ibm.ws.runtime.WsServer.main(WsServer.java:59) [5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) [5/11/06 15:41:23:197 CDT] 0000000a SystemErr R at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
ADMU0016I: Synchronizing configuration between node and cell.
ADMU0111E: Program exiting with error:
com.ibm.websphere.management.exception.AdminException: ADMU0005E:
Error synchronizing repositories
ADMU0211I: Error details may be seen in the file:
/opt/WebSphere/70AppServer/profiles/AppSrv02/logs/syncNode.log
MIGR0350W: Synchronization with the deployment manager using the SOAP protocol
failed.
MIGR0307I: The restoration of the previous WebSphere Application Server
environment is complete.
MIGR0271W: Migration completed successfully, with one or more warnings.
These messages indicate the following:Read the "syncNode command" article in the information center for more information.
Read the "GenPluginCfg command" article in the information center for more information.
bash-3.00# ./syncNode.sh dmgrhostname 8879 -username MyAdminUser -password MyAdminPassword ADMU0116I: Tool information is being logged in file /usr/WebSphere/AppServer/logs/syncNode.log ADMU0401I: Begin syncNode operation for node My511Node with Deployment Manager dmgrhostname: 8879 ADMU0111E: Program exiting with error: com.ibm.websphere.management.exception. AdminException: ADMU2092E: The node and Deployment Manager must have the same product extensions, but they do not match. The node product extension is BASE and the Deployment Manager product extension is PME. ADMU0211I: Error details may be seen in the file: /usr/WebSphere/AppServer/logs/syncNode.log ADMU1211I: To obtain a full trace of the failure, use the -trace option.
Name: mixedEnterpriseCell Value: true
ejbModule/com/ibm/websphere/samples/trade/ejb/QuoteHome.java(17): The type Remote is ambiguous
[7/8/08 16:41:31:416 EDT] 0000001c DefaultTokenP E HMGR0149E: An attempt to open a connection to core group DefaultCoreGroup has been rejected. The sending process has a name of wasinst101Cell01\ndrack104Node08\server1 and an IP address of /9.42.92.86. Global security in the local process is Enabled. Global security in the sending process is Enabled. The received token starts with x2>W 9 Sv?. The exception is com.ibm.websphere.security.auth.WSLoginFailedException: Validation of LTPA token failed due to invalid keys or token type. at com.ibm.ws.security.ltpa.LTPAServerObject. validateToken(LTPAServerObject.java:876) at com.ibm.ws.security.token.WSCredentialTokenMapper. validateLTPAToken(WSCredentialTokenMapper.java:1178) at com.ibm.ws.hamanager.runtime.DefaultTokenProvider. authenticateMember(DefaultTokenProvider.java:214) at com.ibm.ws.hamanager.coordinator.impl.DCSPluginImpl. authenticateMember(DCSPluginImpl.java:723) at com.ibm.ws.dcs.vri.transportAdapter.rmmImpl.ptpDiscovery. DiscoveryRcv.acceptStream(DiscoveryRcv.java:266) at com.ibm.rmm.ptl.tchan.receiver.PacketProcessor. fetchStream(PacketProcessor.java:470) at com.ibm.rmm.ptl.tchan.receiver.PacketProcessor. run(PacketProcessor.java:917)
The deployment manager uses Version 7.0 and all of the nodes and alias nodes are using Version 6.1. To resolve this problem, Upgrade all Version 6.1 nodes to Version 6.1.0.17 or later.
In Version 5.1, there were two transport objects that defined access points for both admin and normal HTTP and HTTPS traffic. Starting in Version 6.0, the ports were split from two into four so that there were HTTP and HTTPS ports for admin traffic (WC_ adminhost and WC_ adminhost_secure) and a separate pair for default traffic (WC_ defaulthost and WC_ defaulthost_secure).
To resolve this problem, map any HTTP and HTTPS traffic that requires the default channel directly to the default endpoints rather than to the old transport ports.
If the Version 7.0 administrative console does not load based on the known port for the Version 5.1 environment, the port might have been changed during migration. The WC_adminhost_secure endpoint is the new administrative console secure port in Version 7.0.
<transports xmi:type="applicationserver.webcontainer:HTTPTransport" xmi:id="HTTPTransport_2" sslEnabled="true" sslConfig="kstelzer2Manager/DefaultSSLSettings"> <address xmi:id="EndPoint_2" host="" port="9043"/> <properties xmi:id="Property_9" name="MaxKeepAliveConnections" value="0" required="false"/> </transports>Delete this transport and save the file, change the WC_adminhost_secure port in the serverindex.xml file to the old port and save that file, and then restart the deployment manager. Deleting the transport allows the port to be used by the WC_adminhost_secure port. If you do not delete the transport and just change the WC_adminhost_secure port, you will see port binding errors in the log.
MIGR0463I: Nothing to migrate at this time. The current profile has already been migrated with all information from enabled features.
If you did not find your problem listed, contact IBM support.