2nd vpar boot hangs both vpars

[Aaron_82]

I have to vpars that can boot from the mon with vparload -all. They both come up ok and I can reboot the first one with no problems but when I boot the second vpar it hangs both vpars. When this hang occurs I can ping the first the vpar but cannot login and if I am logged in I can't type anything. Also, this happens when the 2nd vpar boot not when it comes down because I can halt the partition with no incident. I have version 2.0.2 with every patch I could find(about 40). The new version is in the mail but I need this to be up this weekend. Any ideas? Here is the output from vparstatus -v.
root@scshp33v1:/ #vparstatus -v -p scshp33v1
[Virtual Partition Details]
Name: scshp33v1
State: Up
Attributes: Dynamic,Autoboot
Kernel Path: /stand/vmunix
Boot Opts:

[CPU Details]
Min/Max: 2/2
Bound by User [Path]:
Bound by Monitor [Path]: 0.10
0.11
Unbound [Path]:

[IO Details]
0.0.8
1.0.8
0.0.14
0.0.0
0.0.0.2.0.6.0.0.0.0.0 BOOT

[Memory Details]
Specified [Base /Range]:
(bytes) (MB)
Total Memory (MB): 2048

Name: scshp33v2
State: Down
Attributes: Dynamic,Autoboot
Kernel Path: /stand/vmunix
Boot Opts:

[CPU Details]
Min/Max: 2/2
Bound by User [Path]:
Bound by Monitor [Path]: 0.12
0.13
Unbound [Path]:

[IO Details]
0.0.10
1.0.10
1.0.14
0.0.10.0.0.4.0.11.0.0.0.0.2 BOOT

[Memory Details]
Specified [Base /Range]:
(bytes) (MB)
Total Memory (MB): 2048

This is on a rp8400

[RAC_1]

The one hangs when other one halted. Right?? Anything in syslog/dmesg??

The one that hangs, do TOC on it and it will create crash.

Analyse the crash dump to know what is going wrong.

[Aaron_82]

They both hang when vpar2 tries to boot. I'll see if there is anything in the logs.

[Aaron_82]

No significant errors in the dmesg or syslog. I just ignited vpar2 again from a image that I created today from vpar1 so we should have the same software and configuration.

[melvyn burnard]

have you checked your system firmware?
There are requirements that firmware be at least a particular version, dependant on machine. read the release notes for the version you are using to check this.

[harry d brown jr]

What does vparstatus -V return?

[root@vpart1 /tmp]# swlist -l product VirtualPartition
# Initializing...
# Contacting target "vpart1"...
#
# Target: vpart1:/
#

VirtualPartition A.03.01.05 HP-UX Virtual Partitions Functionality
[root@vpart1 /tmp]#


Do they have different IP's??

Can they be booted without vpars activated (normal boot without vpmon)??

If you boot each one seperately, do a print_manifest on each and post them here. Then do a vpar boot, BUT do NOT use vpload -all, boot one, wait til it comes up, then login and boot the second partition.

Also, you aren't using NPars are you? (it doesn't sound like it).

btw: I have over 200 partitions running across many servers and I am in the beta release program since day one.

live free or die
harry d brown jr

[Thierry Poels_1]

Hi,

I agree with RAC.
We had the same nasty experience with vPars in the beginning. All vPars hanged for a while when one partition was booting due to a crash dump. A system flag needed to be cleared to get rid of this issue.

regards,
Thierry.

[melvyn burnard]

If you are indeed using the A.02.02 release, this is unsupported since January 2005, and has been superseded by A.02.03, then A.03.01, and currently A.03.02
The A.04 release will be out later this year
Also, have you verified the version requirements for Parmanager, STM etc as per tyhe Release Notes?
There is a patch listed for boot "delays" see page 12 of http://docs.hp.com/en/T1335-90015/T1335-90015.pdf

[Marlou Everson]

We had similar problems. The first partition boots fine because the OS is on internal drives. The OS for the second partition is on a VA7400 connected through switches. Booting the second partition would take a long time and also affect the performance of the first partition - e.g., takes forever to log in. To fix this required vpar patches and the proper firmware on the switches.

Marlou