(Bill) Vass (of Sun) expects to spend about $300 million this year on Sun’s IT needs, a figure that represents about 2% of the company’s expected revenue this year. The average company spends between 3% and 4% of its revenue, most figures show — and most of Sun’s direct competitors spend far more.

For a long time I’ve been working on building a thin client solution for my business to make life easier for me. I’ve blogged previously about NX and SRSS, although at that time I can out in favour of NX, I’m still interested in SRSS. Some trouble with FreeNX and the !machine client, plus lack of good Amd64 support and a seeming slow down in FreeNX development maybe be consider my options again recently. Plus the whole Java Card Sun Ray seems very useful. One of the things holding me back for deciding either way at the moment is a good analysis of the bandwidth requirements.

The spec is complicated by our situation with two main offices and five staff in each office. My original plan was to run a v20z in the colo I’ve set up and centralise both offices to this server. One office has a 3Mbit wireless link, the other office a 1Mb/386Kb frame link. Its the second link I’m not sure can handle the bandwidth requirements which has slowed my planning up.

The main reason I’ve planned to use one core server at a colo is power security, secondly one server makes for easier maintenance. Given bandwidth issues, I might consider setting up a server at the slower office just for those desktops.

However numbers like the above make me realise I’m on the right track. They also provide me with a good benchmark to consider the cost of these options and how they compare to standard business practice.

Technorati Tags: nx, thinclient, srss

Luckily, I was using NFS home directories and avoided “where is that month old backup” mode.

When I first started using Xen, I thought I’d be clever and devolve all services from dom0 to the domUs. This included the NFS file service running in a Base domU. Centralising the mail spool, various web roots and databases instances to this Base, making backups and other management easier. By moving everything including NFS services from the dom0 I intended to improve the security profile, restricting dom0 to purely domU guest management and dns caching. All the other external services would then run in separate domUs as appropriate to the desired security envelop.

On this colo machine for instance, I have a Base domU providing NFS to a mail domU running smtp and imap. Then for personal mail use I run mutt on a shell domU. The Base also provides web roots to other domUs and runs mysql instances. All this is being driven by a single 2.8GHz Xeon. I’m not running a high load desktop domU and not pushing the hardware.

One of the first problems I noticed was periodically mutt would stall. Locking up, the interface acting like it was connected via an old 2400 baud link. The stalled session could be restarted quickly by suspending, killing and restarting mutt. It was annoying but I lived with it.

Later in June I started working on my first NX desktop experiment. Great I thought, Xen makes it easy to built a domU snapshot, break my desktop, and then revert without touching the bare metal. Plus I can have one physical machine and not mess up my desktop OS with databases and random libraries to get some interesting application running.

I pulled out an old P4 1.8GHz, added 2Gb of memory and installed with Xen using the same basic template from the colo above. A Base domU providing NFS, particularily a NFS home directory to the desktop domU. As indicated elsewhere in this blog, the FreeNX installation from source was flawlessly. During the following week I experienced a similar annoyance, this time with the whole desktop stalling. Firefox would periodically act like Netscape waiting for a dns request. Occasionally the whole NX desktop would halt and I’d have to wait for a few moments before it started operating again.

As I was busy and didn’t have time to investigate it much, my initially thoughts were it was a single processor contention problem. So I pull out my old desktop machine installed a bare-metal, without Xen, Ubuntu and FreeNX. Then pointing the home directory via NFS back over the network to the initial Base domU. This time there were less problems. So for the following two months I was happily working on Ubuntu via NX. Running large OpenOffice 2.0 and Firefox processes. Suspending my laptop in the evening, then restarting in the morning right back were I was the prior evening via NX resume. Almost productivity heaven.

In the meantime a few weeks ago, I pulled the HDD from the P4 1.8GHz which was now purely a server and put it into a spare 2.4GHz Xeon SMP machine. I had the intention of finding a free weekend and testing SMP as a solution to the performance issues. Of course, being Linux I didn’t even have to bother recompiling the kernel.

Then of course on Friday the HDD failed on my desktop machine. I guess this was meant to be this weekend. Nothing like a hardware fault to kill your fun.

I quickly resurrected the desktop LVM image I’d first used. Did a quick apt-get dist-upgrade. Pointed the NFS home directory back at the base domU on the same machine and started trying out ‘xm pincpu’ in the host dom0. Same desktop stalling. Even with base and desktop domUs on completely different CPUs. Double Damn!

Instead I spent Saturday getting the photo gallery imported into flickr with Flick::Upload.

Later in that day while thinking about something else, I had a “I am stupid brainwave” moment. Realising I had been silly in continuing to force over-optimising in the security envelop. NFS Net I/O was stalling when the base domU guest ran out of CPU slice time while requesting LVM Disk I/O via the dom0 block device.

So I moved the NFS files service into the dom0 host.

Without much issue I shutdown all the domains dependent on the NFS service plus the base domU guest. Removed the LVM home and export slices from the base domU guest. Edited all the fstab entries and restarted. The work of 10 minutes, including the time debugging a typo. Linux/Xen is great.

Pow! Things started work as they should. The domU based desktop started working flawless, backed by NFS home directories on the xen0 NFS host. For the last couple day I’ve been back in NX thin client heaven.

Moral of this story. NFS home directories are good, but not from a domU.

Turns out, working together or only working together, was the main issue I keep hitting into. OSX is just not flexible. Mac keyboard and mouse, just don’t work well in any form with X11, Linux consoles or much else other than OSX. After about three weeks of progressively moving applications from the thin client desktop back to the fat OSX client, dealing with Fink, struggling with being forced to copying files back and forth over the network and not wanting to face figuring out how to change all the local OSX uids to match my Linux uids for decent NFS without reinstalling OSX and setting up NIS, I gave up.

So I started using the spare R40 WinXP laptop I had which was in-between jobs. Within days I was back up to speed. OpenOffice 2, firefox and mutt. No problems. Everything just worked again. Plus with Ubuntu install the desktop and applications became a breeze, apt-get just works. This month at least. With the advent of klik on ubuntu, sanding boxing bleeding edge software just became easier.

The MiniMac is sitting there somewhat lonely now. Mainly being used for playing iTunes and doing the odd Photoshop job. As much as I want to like OSX, it is just not flexible enough for a good business desktop. Too much under the hood that is not quite Unix and requires an Apple degree. Now my desktop focus is firmly on thin client technology. I’ll planning to have move primary work environment into a colo. Then combined with openvpn I’ll be able to securely access it transparently. The network truly does become my machine.

That said, I still like OSX very much. Its the perfect companion for the non-tech family member. Web, mail and iTunes. That pretty much covers 90% of primary usage. There are many SIP softphone clients and Skype works very well. I’ll probably continue to evolve usage patterns for myself on the MiniMac. Mostly these will be play things, and not works.

So the short term plan is a new T52 Thinkpad. 2.0GHz P-M with up to 9 hours of battery life and a 15″ screen. For the same price as a iBook.

Of course next year, when Apple release a x86 based Powerbook, I’ll probably rethink the above. Dual booting OSX, WinXP and Ubuntu will allow me to have the best of all worlds any time. Plus the P-M based tech will improve the Powerbook battery life sufficiently and making it into a decent mobile workstation and some not glorified portable desktop.

Sun Ray = Office Supplies. You can’t “Fix” a Sun Ray. Out of the 33,000 Sun Ray desktops inside of Sun, how many “desktop” techs do you think are required to manage that install base? How does the number zero grab you? On the ultra rare occasion that something happens to your Sun Ray (let’s say a power supply failure), you replace it and send it back for a warranty replacement (5 years on the SR1g). In the meantime you walk to the closet, grab a spare and plug it in and pick up exactly where you left off. Anyone who can replace staples in a stapler or replenish their supply of post-it notes can replace a Sun Ray

Some people would this say I should just consider using SunRays, but that would force a vendor lock. I’d have to spend a whole pile of cash now, replacing all my current desktop hardware. Instead using NX and PXES I can save this whole of cash, spending it later. Furthermore, it is probably possible to consider a staged migration to a complete SunRay solution, by mixing NX and SRSS. Run SRSS on one Xen domU and NX on another. NFS home-dir and things are going to work reasonably well.

SunRay/SRSS vendor lock is a big issue even for those with lots of cash to spend. Deciding to change and being forced to replace all your very workable SunRays with, say, new HP thin clients is defeating the thin client purpose. Kinda like paying for a new Windows client license. Five years is not an unreasonable amount of time for thin client hardware to last, as Suns states with their warranty. However, many software and server system choices will be made over this period to meet changing an organisations needs, goals and environments. Using SRSS is going to cut down the choices.

That’s the nice thing about NX, its vendor neutral and pretty much runs everywhere. Even on Solarias.

Anyway, I had a remote NX desktop running on his machine to my colo Xen machine about 256kbps (50ms) DSL away and on mine I had the local NX desktop which I’ve been using as a test install for the past two weeks. Compression was set at modem speeds for the remote and LAN speeds for the local desktops. I decided I need a test to show off NX off to him and figured a quick look at my gallery would be good. And it was. It surprised even myself.

The remote desktop loaded this page faster than the local desktop. There was a definitely noticeable difference in page display speed in Firefox. The quality of the remote desktop on the two screens was hardily different. The thumbnails on the remote were slightly blurry, but not by much.

The remote machine is sitting next (Xen-wise) to the gallery web server and obviously my local desktop load the thumbnails over the DSL link. So this is a certain testament to NX’s performance given that same page and images were rendered and presented faster from the remote location.