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/getpatch.pl?documentId=119376

or

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

http://sunsolve.sun.com/pub-cgi/getpatch.pl?documentId=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

Rich Skywalker wrote:
 > Yep, I'm proud to say that I've never owned a peecee, and I don't plan to
 > either (although Sun's Opteron based workstations are tempting...).


First came an imperial Ferrari Athlon64 laptop.....

And then,

Rich Vader wrote:
> Hi all,
> 
> I'm thinking of getting a new server, and one I'm considering
> is the V20z.  


Don a big black cape, and the transition to the dar-x86-ide is complete...

;)

It looks like this temptation you speak of, has become a serious threat
(for those that can afford it ;) )

Rob


-- 
Rap it up for the common good
Let us enlist the neighbourhood
It's OK, I've overstood
This is a wordy rappinghood. OK, bye.

                   Tomtomclub, 1980.

In article <slrndbv89f.sa6.usenet@gaia.roc2.gblx.net>,
 Dan Foster <usenet@evilphb.org> wrote:

> More V20Z tips for other V20Z owners or prospective buyers:

Thanks for the tips.

Unless I'm missing something, it doesn't seem possible to do an OS 
install/upgrade via the SP (with "platform console"). Although you can 
use the "set keyboard/input=ttya" trick, the "eeprom" appears be to 
virtual. So, you can remotely tell to boot off the CD, but once it 
starts booting it uses the "eeprom" from the CD and switches back to the 
console.

Does anyone know of a way around this? Or do I have to cart a screen and 
keyboard to the co-lo to install Solaris 11 or whatever the next OS will 
be?

Other than that, the SP works great and saves me buying a terminal 
server.

> 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.]

You really want one of these in your house? The noise it makes is 
horrendous. I can barely tolerate it when it's in the little "server 
room" next to my office; I certainly wouldn't want it next to my desk. 
The quicker I get it installed in the co-lo the better.

-- 

Sak Wathanasin
Network Analysis Limited
http://www.network-analysis.ltd.uk

Rich Teer <rich.teer@rite-group.com> writes:

>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"?

Yes, it's possible. Sort of. It emulates a PC text console
and thus is *slow* (screen updates all over the window). Forget
about anything faster than 9600 bps also. Forget about cut-and-paste
into the redirected console window - it'll lose 90% of your pasted
input.

It can also have problems with add-on PCI adapters that have
their own BIOS code that writes to the screen.

And then depending on which operating system you intend of
running you might have problems getting the BIOS, the boot loader
and the operating system to all have the same idea on where the
console is located... It worked pretty well with Solaris 10, but I
had problems like hell getting both the BIOS redirection working, at
the same time having GRUB output being sent to the redirected console
and then also getting Linux to output to the same one. After much
tinkering I finally got two out of three working - but never all three
at the same time.

Stupid PC hardware. *Sigh*

- Peter

-- 
-- 
Peter Eriksson <peter@ifm.liu.se>            Phone:    +46 13  28 2786
Computer Systems Manager/BOFH                Cell/GSM: +46 705 18 2786
Physics Department, Link�ping University     Room:     Building F, F203

In article <d9p3k4$sbt$1@news.island.liu.se>,
 Peter Eriksson <peter@ifm.liu.se> wrote:

> Forget about anything faster than 9600 bps also.

I have it at 57.6K here, even without Mr Foster's changes (which I will 
try real soon now...) Perhaps you need to update the BIOS?

-- 

Sak Wathanasin
Network Analysis Limited
http://www.network-analysis.ltd.uk

Sak Wathanasin wrote:
> In article <slrndbv89f.sa6.usenet@gaia.roc2.gblx.net>,
>  Dan Foster <usenet@evilphb.org> wrote:
> 
..... lines deleted to save space ....

> 
> You really want one of these in your house? The noise it makes is 
> horrendous. I can barely tolerate it when it's in the little "server 
> room" next to my office; I certainly wouldn't want it next to my desk. 
> The quicker I get it installed in the co-lo the better.
> 

I agree about the noise pollution; when we first plugged in our v20z I 
believed it was defective because it was so loud.   I cannot imagine it 
in any place near a work environment, IMO somebody nearly deaf must have 
   evaluated the acoustical design.

In article <d9pb0u$nli$1@alageremail2.agere.com>, Charles Meeks <cmeeks@agere.com> wrote:
>
> I agree about the noise pollution; when we first plugged in our v20z I 
> believed it was defective because it was so loud.   I cannot imagine it 
> in any place near a work environment, IMO somebody nearly deaf must have 
>    evaluated the acoustical design.

From the folks whom put up a mirror for the OpenSolaris launch:

http://sol10frominnerspace.blogspot.com/

<quote>
	But the included documentation indicated the requirement for a
	revision K2.5 motherboard [...]

	One (big) advantage of the updated motherboard is (IMHO)
	quieter speed controlled fans [...]
</quote>

Sounds like Sun may have made quieter V20Zs for later production units?

My colleagues do tell me the early ones are really loud. :)

-Dan

Dan Foster wrote:
[snip]
> 
> 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 slag on Sun for reselling Newisys[1] computers with Service Processors 
running Linux, but I also buy them because Sun did pick the niciest AMD 
boxes on the market to resell.

If you want to buy an x86 based Sun server I would wait for the next 
generation which is being designed and built by Sun.  Not that there is 
really anything wrong with the v20z and the v40z, they just don't have 
that last little bit of refinement I have come to expect (demand) from 
Sun hardware.

Neal

[1] the v40z: http://www.newisys.com/products/4300.html
     the v20z: http://www.newisys.com/products/2100.html

In article <1119865899.515147@docbert>,
Scott Howard  <scott@hunterlink.net.au> wrote:
>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.

When is (Open)Solaris the appropriate OS for tiny embedded hardware?

How much tinier is the service processor embedded in Galaxy vs the
an ATCA Blade?

John
groenveld@acm.org

Dan Foster <usenet@evilphb.org> wrote:

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

Just today I had a closer look the the SP and unfortunately 'resize' did
not work as usual when I switched from TERM=sun to TERM=xterm on the
console.

Could the missing flow control also be the cause for /usr/openwin/bin/resize
getting a timeout?

ciao
     Klaus

On Mon, 27 Jun 2005, Rob Shepherd wrote:

> Don a big black cape, and the transition to the dar-x86-ide is complete...

I find your lack of faith most disturbing...

I mean, curses!  caught red-handed!  :-)

> It looks like this temptation you speak of, has become a serious threat
> (for those that can afford it ;) )

Indeed.  I love the price/performance of amd64, but I'm still keeping
an eye on Sx86 SW availability before jumping ship.  I suspect it will
be a LONG time before I abandon SPARC, if ever.

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

President,
Rite Online Inc.

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

On Mon, 27 Jun 2005, Peter Eriksson wrote:

> And then depending on which operating system you intend of
> running you might have problems getting the BIOS, the boot loader

Heh; you don't know me very well!  There's only one OS I will consider
using: Solaris, be it on SPARC or x86/amd64.

> Stupid PC hardware. *Sigh*

Amen to that...

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

President,
Rite Online Inc.

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

In article <slrndbv89f.sa6.usenet@gaia.roc2.gblx.net>,
Dan Foster  <usenet@evilphb.org> wrote:
>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:

You'll also need the ITU if you use h/w mirroring of two 72GB drives.

John
groenveld@acm.org

In article <d9pf5c$pj0$1@mailhub227.itcs.purdue.edu>,
Neal A. Lucier <nlucier@math.purdue.edu> wrote:
>If you want to buy an x86 based Sun server I would wait for the next 
>generation which is being designed and built by Sun.  Not that there is 
>really anything wrong with the v20z and the v40z, they just don't have 
>that last little bit of refinement I have come to expect (demand) from 
>Sun hardware.

	As long as they keep the cute little LCD screens.  Those should be 
fitted on blades btw, since labelling blades is an exercise in teeny fonts 
and teeny fingers.


-- 
"When in doubt, use brute force."
- Ken Thompson

In article <d9pb0u$nli$1@alageremail2.agere.com>,
Charles Meeks  <cmeeks@agere.com> wrote:
>I agree about the noise pollution; when we first plugged in our v20z I 
>believed it was defective because it was so loud.   I cannot imagine it 
>in any place near a work environment, IMO somebody nearly deaf must have 
>   evaluated the acoustical design.

	And without PCIe, kinda not so fun as a workstation..  How else to 
get the 7800GTX card in for "work"?
-- 
"When in doubt, use brute force."
- Ken Thompson

On Wed, 17 Aug 2005, hennessy wrote:

> 	And without PCIe, kinda not so fun as a workstation..  How else to
> get the 7800GTX card in for "work"?

Get an Ultra 20?  :-)

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

President,
Rite Online Inc.

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