Well, Lets see what we need to for this.
WebSphere Hypervisor version 7. Follow this URL http://www-01.ibm.com/software/webservers/appserv/hypervisor/
You need to download the following
When searched in infocenter for hypervisor, it gave me very clear instructions. Here are those links
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.virtualimages.doc/info/ae/ae/welcome_virtual.html
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.virtualimages.doc/info/ae/ae/tins_virt_install_vmware_esx.html
So, you those files from IBM. Whatelse you need?
1. SLES 10, sp3.
Goto novell.com, get SuSE Linux Enterprise Edition.
2. VirtualBox -
http://www.virtualbox.org/
Download virtualbox, install it, create a suse virtual machine.
3. Get cygwin.
http://www.cygwin.com/
4. Before you begin, you need to mount these tgz files to cygwin.
When cygwin is installed it creates directories like this
Directory Structure
Cygwin attempts to duplicate the directory structure of a Linux System within the "c:\cygwin" folder:
To not waste time on mounting another directory into cygwin, simply copy those tgz files to c:\cygwin\tmp, which are avaliable thru cygwin shell.
5. Now, openup a cygwin shell.
You have downloaded tgz file. A tgz file is a gunzip file. To uncompress it, in general, one can use gunzip command.
gunzip filename.tgz
is an example.
Or, on linux platforms, tar gives a switch *z* to uncompress gz, tgz files
Now, at the cygwin prompt -
cd /tmp
tar xvzf filename.tgz
Use the above command and replace filename.tgz with all those four files.
This uncompresses tgz file to a tar file and tar file will be uncomplressed.
6. Above command creates files like
vmdk, vmx files.
7. For ease of use, I have created another directory say, c:\vmdk_files
and copied all these files into that directory. These are the files -
8. So, we have vmdk files, and virtual machine. By the way, what is a vmdk file? :)
vmdk = virtual machine disk.
When we create a virtual machine, it will create a hdd readable by it. virtualbox by default creates vdi file. vmdk is another kind of such virtual disk file. Now, we need to add that virtual disk to the virtual machine as a secondary disk.
9. This is how you do it -
Open ur virtualbox
point to the virtual machine
As pointed in the above, I have selected suse, under that, select *Storage*.
10.
As shown above, hit on that *Add Attachment*, it gives two options, add hard disk or cd/dvd/. Select, obviously, disk.
11.
So, we mounted these vmdsiks to our virtual machine. Lets start and see -
12. These 4 are the mounted disks -
1/31/10
1/30/10
tar
was.7005.nd.linux.vmware.esx.sles.os.tgz is big file, 2.33GB. When uncompress, its 12GB.
$tar xvfz was.7005.nd.linux.vmware.esx.sles.os.tgz
SLES10SP2-32-flat.vmdk
tar: SLES10SP2-32-flat.vmdk: Wrote only 4607 of 10240 bytes
SLES10SP2-32.vmdk
tar: Exiting with failure status due to previous errors
What to do??
$tar xvfz was.7005.nd.linux.vmware.esx.sles.os.tgz
SLES10SP2-32-flat.vmdk
tar: SLES10SP2-32-flat.vmdk: Wrote only 4607 of 10240 bytes
SLES10SP2-32.vmdk
tar: Exiting with failure status due to previous errors
What to do??
Labels:
Linux,
tar,
VirtualBox,
vmdk,
WAS 7
1/29/10
vmdk disks
While I was going through Dileep Kumar's Blogpost WebSphere Hypervisor Edition and VirtualBox, Hypervisor version attracted me a lot. So, I wanted to tryout installation the Hypervisor version 7.0.0.5 on my VirtualBox.
I have lot to share on this and tomorrow I will publish that.
I have lot to share on this and tomorrow I will publish that.
1/28/10
InfoCenter 6.1
Today, InfoCenter URL is spitting with this message
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /infocenter/wasinfo/v6r1/advanced/searchView.jsp.
Reason: Error reading from remote server
IBM_HTTP_Server/6.0.2.13 Apache/2.0.47 (Unix) Server at publib.boulder.ibm.com Port 80
According to IBM Technote http://www-01.ibm.com/support/docview.wss?rs=177&context=SSEQTJ&dc=DB560&dc=DB520&uid=swg21316599&loc=en_US&cs=UTF-8&lang=en&rss=ct177websphere
Problem(Abstract)
A Proxy Error in IBM® HTTP Server (IHS) causes a 502 error response in the browser.
Symptom
The user sees a 502 Proxy Error in the browser that says:
The proxy server received an invalid response from an upstream server. The proxy server could not handle the request ....
The IBM HTTP Server error log displays errors similar to:
proxy: Error reading from remote server returned by ....
Cause
The most common cause of this problem is when the back-end web server is either not using KeepAlive, or is using too low of a value for KeepAlive.
Environment
IBM HTTP Server is configured as a proxy or reverseproxy in front of some other back-end web server.
Resolving the problem
There are two possible solutions to this problem:
1) Disable KeepAlive in IBM HTTP Server, by adding these directives into your IBM HTTP Server config (httpd.conf):
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
OR
2) Increase the KeepAlive value in the back-end web server. The KeepAlive value for the back-end web server should be at least double or triple whatever IBM HTTP Server is using for KeepAlive. The default KeepAlive for IBM HTTP Server is 15 seconds. So the back-end web server should be configured to use KeepAlive of 30 or 45 seconds.
-------------------------------------
Here the question is, who is going set those values on the IBM remote servers? :):)
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /infocenter/wasinfo/v6r1/advanced/searchView.jsp.
Reason: Error reading from remote server
IBM_HTTP_Server/6.0.2.13 Apache/2.0.47 (Unix) Server at publib.boulder.ibm.com Port 80
According to IBM Technote http://www-01.ibm.com/support/docview.wss?rs=177&context=SSEQTJ&dc=DB560&dc=DB520&uid=swg21316599&loc=en_US&cs=UTF-8&lang=en&rss=ct177websphere
Problem(Abstract)
A Proxy Error in IBM® HTTP Server (IHS) causes a 502 error response in the browser.
Symptom
The user sees a 502 Proxy Error in the browser that says:
The proxy server received an invalid response from an upstream server. The proxy server could not handle the request ....
The IBM HTTP Server error log displays errors similar to:
proxy: Error reading from remote server returned by ....
Cause
The most common cause of this problem is when the back-end web server is either not using KeepAlive, or is using too low of a value for KeepAlive.
Environment
IBM HTTP Server is configured as a proxy or reverseproxy in front of some other back-end web server.
Resolving the problem
There are two possible solutions to this problem:
1) Disable KeepAlive in IBM HTTP Server, by adding these directives into your IBM HTTP Server config (httpd.conf):
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
OR
2) Increase the KeepAlive value in the back-end web server. The KeepAlive value for the back-end web server should be at least double or triple whatever IBM HTTP Server is using for KeepAlive. The default KeepAlive for IBM HTTP Server is 15 seconds. So the back-end web server should be configured to use KeepAlive of 30 or 45 seconds.
-------------------------------------
Here the question is, who is going set those values on the IBM remote servers? :):)
1/27/10
Migration Notes #2
The migration tools are used as part of a four-step migration process:
1. Run WASPreUpgrade on the existing WebSphere Application Server configuration.
2. Uninstall the existing version of WebSphere Application Server.
3. Install the new version of WebSphere Application Server.
4. Run WASPostUpgrade on the new version.
In the second step, it is recommended that rather than uninstalling the existing version, it be made dormant. By keeping the existing software installed on the machine, it will be much easier to back out of the migration should unexpected problems arise.
The fully automated migration includes the following steps:
1. Migrate the existing Version 5.x deployment manager to Version 6.0 using the migration
tools.
2. Migrate the HTTP servers and HTTP server plug-ins on all Web tier nodes.
3. Individually migrate the application server nodes using the migration tools.
The WASPreUpgrade and WASPostUpgrade tools effectively move the existing configuration into WebSphere Application Server Version 6.0.
1. Run WASPreUpgrade on the existing WebSphere Application Server configuration.
2. Uninstall the existing version of WebSphere Application Server.
3. Install the new version of WebSphere Application Server.
4. Run WASPostUpgrade on the new version.
In the second step, it is recommended that rather than uninstalling the existing version, it be made dormant. By keeping the existing software installed on the machine, it will be much easier to back out of the migration should unexpected problems arise.
The fully automated migration includes the following steps:
1. Migrate the existing Version 5.x deployment manager to Version 6.0 using the migration
tools.
2. Migrate the HTTP servers and HTTP server plug-ins on all Web tier nodes.
3. Individually migrate the application server nodes using the migration tools.
The WASPreUpgrade and WASPostUpgrade tools effectively move the existing configuration into WebSphere Application Server Version 6.0.
Labels:
MIGRATION,
Migration Notes,
WAS
1/26/10
Migration Notes #1
Why to migrate?
Two important things to my understanding.
For new features.
For maintenance support.
-> New Features
Again two views. Developer view and support view.
ex., My developer called me one day, said, struts framework x.xx version is throwing error on the development. I paid a look into the log and search for the errors in the IBM. Found that, that version of JVM donot support this version of struts. So, what to do? Its the developers call to have the latest copy the JVM which can support this version of struts and apps.
This is what is developer initiated migration.
Admin initiated migration -
Admin may initiate the migration too. Some of the app server errors must have been addressed in the new version of the application server and so the need for migration.
-> Support
If the product is end of the support, there is a need to migrate to supported version.
While migrating, one should need to understand inconsistencies and deprecations between the target and source environments.
In considering the incompatibilities and deprecations, we look at these major areas:
* J2EE differences
* J2SE/JDK differences
* Application Server runtime differences
* Programming Model Extension differences
* Third Party Library differences
-> J2EE Differences
Java Code, as we all know, is forward compatible. Meaning that, code compiled in JDK 1.3.0 runs on 1.4.0, but, may throw some deprecation warnings.
Its a good practice for the developers to address those deprecations in the code. So, when one plans to migrate from x version to y version, the development team should plan to revisit their code.
Two important things to my understanding.
For new features.
For maintenance support.
-> New Features
Again two views. Developer view and support view.
ex., My developer called me one day, said, struts framework x.xx version is throwing error on the development. I paid a look into the log and search for the errors in the IBM. Found that, that version of JVM donot support this version of struts. So, what to do? Its the developers call to have the latest copy the JVM which can support this version of struts and apps.
This is what is developer initiated migration.
Admin initiated migration -
Admin may initiate the migration too. Some of the app server errors must have been addressed in the new version of the application server and so the need for migration.
-> Support
If the product is end of the support, there is a need to migrate to supported version.
While migrating, one should need to understand inconsistencies and deprecations between the target and source environments.
In considering the incompatibilities and deprecations, we look at these major areas:
* J2EE differences
* J2SE/JDK differences
* Application Server runtime differences
* Programming Model Extension differences
* Third Party Library differences
-> J2EE Differences
Java Code, as we all know, is forward compatible. Meaning that, code compiled in JDK 1.3.0 runs on 1.4.0, but, may throw some deprecation warnings.
Its a good practice for the developers to address those deprecations in the code. So, when one plans to migrate from x version to y version, the development team should plan to revisit their code.
Labels:
MIGRATION,
Migration Notes,
WAS
Subscribe to:
Posts (Atom)