Hi all,

I'm thinking of getting a new server, and one I'm considering
is the V20z. Given the x86's braindead approach to remote
consoles (i.e., they think that all machines have a keyboard
and monitor!), I'm concerned about remote management.

So the question arises, how does the V20z's remote management
capabilities compare to say ALOM on the V240 and co.? Is it
possible to watch one boot by using the equivalent of "console -f"?

TIA,

--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich

In <Pine.SOL.4.58.0506261524070.15926@zen.rite-group.com> Rich Teer <rich.teer@rite-group.com> writes:

>I'm thinking of getting a new server, and one I'm considering
>is the V20z. Given the x86's braindead approach to remote
>consoles (i.e., they think that all machines have a keyboard
>and monitor!), I'm concerned about remote management.

>So the question arises, how does the V20z's remote management
>capabilities compare to say ALOM on the V240 and co.? Is it
>possible to watch one boot by using the equivalent of "console -f"?

It's quite good actually, although ALOM is better. We have a V20z
running nicely with only an ethernet console. It requires an ssh
connection. The service processor runs embedded Linux. You can
power it on and off remotely, as well as boot it. The serial console
emulation uses that silly technique of mapping a DOS screen into a
curses terminal, but it's tolerable.

--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-

In article <d9nb7r$4nk$1@canopus.cc.umanitoba.ca>, Gary Mills <mills@mira.cc.umanitoba.ca> wrote:
> In <Pine.SOL.4.58.0506261524070.15926@zen.rite-group.com> Rich Teer <rich.teer@rite-group.com> writes:
>
>>I'm thinking of getting a new server, and one I'm considering
>>is the V20z. Given the x86's braindead approach to remote
>>consoles (i.e., they think that all machines have a keyboard
>>and monitor!), I'm concerned about remote management.
>
>>So the question arises, how does the V20z's remote management
>>capabilities compare to say ALOM on the V240 and co.? Is it
>>possible to watch one boot by using the equivalent of "console -f"?
>
> It's quite good actually, although ALOM is better. We have a V20z
> running nicely with only an ethernet console. It requires an ssh
> connection. The service processor runs embedded Linux. You can

Aye. It runs a PowerPC CPU with Linux. ('cat /proc/cpuinfo')

So Sun bloggers may not want to slag Linux just yet...

> power it on and off remotely, as well as boot it. The serial console
> emulation uses that silly technique of mapping a DOS screen into a
> curses terminal, but it's tolerable.

We have a pile (~20) of V20Zs and I'd have to agree with the comments above.

I haven't found any situation that I couldn't solve with the SP's remote
management capabilities. Kind of a non-negotiable requirement for us
because I'm about 3300 km away from the actual machines!

My only problems with the V20Z was when we once had a failed SP firmware
flash session, and when a Sun tech accidentally fried the board from
electrostatic discharge damage. To Sun's credit, they promptly replaced
both units without hassles.

Other than that, they have been ok for us so far, despite the x86
architectural warts (e.g. BIOS). Performance has been eye-popping. :-)

I've repeatedly joked to my boss (half jokingly) that I wouldn't mind or
object at all if they ever had "extra machines they didn't know what to
do with" :-) [implication: great for home workstation use, and then some.]

-Dan

P.S. Things are a lot more tolerable for the serial console when it's
set to 115200 bps + hardware flow control. :-) I have it working great
with the SP, BIOS, and the OS.

In article <slrndbue8u.sa6.usenet@gaia.roc2.gblx.net>,
Dan Foster <usenet@evilphb.org> wrote:
>So Sun bloggers may not want to slag Linux just yet...

Is Linux embedded in the service processor for the Galaxy servers?

John
groenveld@acm.org

In article <d9ng91$gf5$1@neuromancer.cse.psu.edu>, John D Groenveld <groenvel@cse.psu.edu> wrote:
> In article <slrndbue8u.sa6.usenet@gaia.roc2.gblx.net>,
> Dan Foster <usenet@evilphb.org> wrote:
>>So Sun bloggers may not want to slag Linux just yet...
>
> Is Linux embedded in the service processor for the Galaxy servers?

Hm? No idea.

Just pointing out it seems a bit silly and hypocritical to slag on Linux
(on a number of Sun blogs) when one's own company has adopted it to run
a service processor on some servers instead of making Solaris the basis
of the service processor's OS.

-Dan

On Mon, 27 Jun 2005, Dan Foster wrote:

> Just pointing out it seems a bit silly and hypocritical to slag on Linux
> (on a number of Sun blogs) when one's own company has adopted it to run
> a service processor on some servers instead of making Solaris the basis
> of the service processor's OS.

I agree with your sentiment, although there is quite a difference between
the OS for a service processor and one that is massively scalable, secure,
observable, etc.

But (as is so usualy with Usenet threads) we're starying off topic. :-)

Thanks all for your insight.

--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich

More V20Z tips for other V20Z owners or prospective buyers:

I forgot to also mention that to get 115200 bps + hardware flow control
working properly in Solaris, firmware updates for the SP and BIOS seems
to be required.

If the SP firmware rev is 2.1.x and BIOS is 1.30.5, then they need to be
at least 2.2.x/1.32.x. (Revs can be seen with 'inventory get software')

Then flow control magically starts working in the OS. :-)

It's easy to verify: just ssh into the SP and do 'platform console' then
login to the OS and do 'cat > /dev/null' and paste an URL or any long
line of text.

(This also assumes the BIOS has been set to 115200 bps + hardware flow
control, and that the SP console settings has been set to 115200 bps.)

If flow control is working, the line will paste perfectly. If it isn't,
characters will be missing.

Also, I had to update the Solaris console to use the faster speed with:

# sacadm -r -p zsmon
# cat >> /etc/ttydefs << myEOF
console8:115200 hupcl opost onlcr:115200::console8
myEOF

# cat >> /tmp/console-login << myEOF
setprop ttymon/label=console8
setprop ttymon/terminal_type=vt100
myEOF
# /usr/sbin/svccfg -s console-login -f /tmp/console-login
# rm -f /tmp/console-login > /dev/null 2>&1
# /usr/sbin/svcadm restart console-login

The above stuff, I do in a Jumpstart finish script, and only if it
detects running on an AMD64 as I can't guarantee our other machines
supports this.

115200 is a world of difference from 9600, mildly put. It feels as
crisp as ssh does.

The SP is no ALOM per se, but it's still pretty good.

It's got:

- Environmental reporting
- SNMP support to report host *and* SP status
- SNMP traps
- FRU info reported for various components
- Several tiers of users and ability to create users
- Ability to store ssh host keys for automated management
tools to do their job
- Can do forced power on/off of the host platform
- Can reset the SP itself
- Can reset SP to factory defaults
- Can redirect host console
- Can have multiple users watch the console in read-only
mode with only one person active in read-write mode (this
is because the SP uses conserver 8.1.4)
- Can send email alerts
- Supports a non-ssl and ssl web interface
- Supports ssh interface
- Supports host serial console interface
- Supports 'locate light' blinking functionality
- MAC address info for both SP and platform (good,
because there are 4 network interfaces; 2 for each)
- Ability to create test events on the fly to test
different email alert reporting levels
- Can report any observed hardware faults in an error log

The one big thing I *REALLY* wish the SP had was libreadline support.
It'd make a world of difference in certain situations for productivity,
but it's not absolutely required.

I also wish it had command completion like a number of other modern day
system or network management appliances do.

The only oddity is that to do a SP or BIOS flash update, you must be
able to NFS mount a specific directory. Bit of a PITA for us since we
have restrictive network access control lists (particularly for NFS!) in
the production subnets. Fortunately, we only need to do such work in the
lab, so far.

There is also a BIOS default that is easy to miss, and a setting that I
thought may not have had been the best-chosen default.

Specifically, the 'After Power Failure' option is set to 'Off' by
default... which means if power goes out then comes back on later, the
system will remain off.

A better option for us is to set that to 'Last State'. (If power comes
on, host will power on ONLY if it was previously powered on. Had it been
shut down prior to the power event, then it will remain off.)

But all considered, we're happy with the V20Zs despite the x86
architectural design issues. Sun also seems to have put in a tremendous
amount of work to work around that stuff on the OS side, too. We've
*really* put that machine through testing paces and beat it up, and it
still made it through the gauntlet. That's a good sign.

Minimum OS version suggested for the V20Z is Solaris 9 09/04, but they
fixed some big issues (can't remember what now) better in Solaris 10/x86
FCS so we went with that and then smpatch update'd to latest. Works great.

No problems at all with DHCP/PXE booting for a jumpstart install.

With our main application, we went from an app load time of 3, 12, and
15-30 *minutes* on older IBM AIX servers to a little over 6 *seconds*
with the V20Z. We also boosted maximum number of queries per second by
somewhere around 50 to 80 times. Mind-blowing performance, to put it
mildly.

I only wish we had OBP and not the x86 BIOS in the V20Z :-) BIOS config
changes are hard to automate.

I understand there is a special caveat, however. There is a weird bug
that makes it impossible to install onto anything bigger than 73 GB
drives in existing Solaris/x86 GA releases. (We got 2x73GB)

Sun has a special patch to apply. So if you ever get 1x146 GB or 2x146
GB and a x86 box, you'll want to check:

ITU sd(7D) patch for Solaris 10/x86 manual installs:

http://sunsolve.sun.com/pub-cgi/getp...umentId=119376

or

Non-ITU sd(7D) patch to apply to the Jumpstart image for Solaris 10/x86:

http://sunsolve.sun.com/pub-cgi/getp...umentId=119375

-Dan

In article <slrndbuhkv.sa6.usenet@gaia.roc2.gblx.net>, Dan Foster <usenet@evilphb.org> wrote:
> In article <d9ng91$gf5$1@neuromancer.cse.psu.edu>, John D Groenveld <groenvel@cse.psu.edu> wrote:
>> In article <slrndbue8u.sa6.usenet@gaia.roc2.gblx.net>,
>> Dan Foster <usenet@evilphb.org> wrote:
>>>So Sun bloggers may not want to slag Linux just yet...
>>
>> Is Linux embedded in the service processor for the Galaxy servers?
>
> Hm? No idea.

Ahh, correction. If Galaxy includes V20Z, then yes.

I'm aware of some of the internal code names (e.g. Einstein for the
Ultra 5, Daktari for the V880, etc) but not for most of them. My apologies.

The V20Z service processor (a PowerPC at 64 MHz, possibly a PPC 860?)
runs a small OS off nonvolatile flash RAM -- Linux 2.4.18.

It's a rather minimal environment since the amount of flash RAM seems to
be constrainted, presumably for cost reasons. I don't recall the size
offhand, but want to say it's 16 MB or 32 MB?

It does make me slightly nervous because the ssh (both client and
server) on the SP is OpenSSH 3.4p1. Hopefully, it's well patched against
the holes found since 3.4p1.

We do limit access via network/firewall access control lists to minimize
the potential for malicious exploitation even if unpatched.

This is a common issue with any 'black box' appliances, Linux or not.

We've had remote root compromises with FreeBSD-based appliances because
the vendor configured it incredibly poorly and didn't let us have access
or tell us about its weaker points.

Unusual network traffic was how we noticed and found the underlying
culprit. We ended up not buying that particular vendor's hardware, by
the way. (We also isolated all appliances after that incident, years ago.)

The issue is compounded, over time, when the vendor eventually stops
introducing patches for an existing product as it ages -- including
security fixes.

So the policy with anything involving appliances and network
connectivity has always been to 'lock it down as much as possible'.

-Dan

In article <slrndbvg9r.sa6.usenet@gaia.roc2.gblx.net>, Dan Foster <usenet@evilphb.org> wrote:
>>>>So Sun bloggers may not want to slag Linux just yet...
>>>
>>> Is Linux embedded in the service processor for the Galaxy servers?
>>
>> Hm? No idea.
>
> Ahh, correction. If Galaxy includes V20Z, then yes.

Ahh, Galaxy is probably the next new batch of AMD64 boxes from Sun?

(Did a Google search)

If that is the case, then that's a good question, after all. :-)

-Dan

In comp.unix.solaris Dan Foster <usenet@evilphb.org> wrote:
> Just pointing out it seems a bit silly and hypocritical to slag on Linux
> (on a number of Sun blogs) when one's own company has adopted it to run
> a service processor on some servers instead of making Solaris the basis
> of the service processor's OS.

All OSes have their place - the OS you'd want to run on a tiny embedded
controller (Linux in this case) is most likely going to be a different OS
to what you'd want to run on a 140-odd core multiuser system.

Scott