We are running 20 Oracle/Linux VMs across 2 IFLs. The savings with DCSS are not compelling enough with our fairly small number of instances. Larger shops would benefit though. Shared Oracle directories, not supported last time I checked, would be welcomed, but thats a different issue. We gave up on shared /usr because of the complexity involved with patching. As it is, our open systems designers considered every worst-case scenario, hence our images are more bloated than they should be. Our primary goals are simplicity and reliability, and in that regard Oracle and Linux/390 kicks butt.
If the appliance images are small enough, sharing wouldn't be a big issue so they can be completely self-contained. Ideally, customers can be OS-agnostic, with just an awareness that Linux is controlling the application, similar to the way Tivo functions at home. As long as there are appropriate hooks (via standardized config) to add user file systems and utilites (backup agents, etc.) it shouldn't matter beyond making sure that whatever is added has the expected support. Similarly for an upgrade or patch, the appliance minidisk would be completely replaced, and the configurator would look for and reapply all user customizations. Maybe put network, swap, and user minidisk/filesystem data in a CMS file to be read at startup. We do something similar to this now. In all cases, the steps would be: DDR restore, configure, go; A hybrid of black-box and custom built server, of sorts. There is so much good stuff out there that should really be coming together. Imagine going to the Oracle website and downloading the latest 10g server appliance DDR image. 8-) Ray Mrohs Energy Information Administration U.S. Department of Energy -----Original Message----- From: Carsten Otte [mailto:[EMAIL PROTECTED] Sent: Thursday, November 03, 2005 5:19 AM To: [email protected] Subject: Re: Question for Oracle shops Mrohs, Ray wrote: > Some people might see this as "dumbing down", but in reality competition calls > for a streamlined portable plug-n-play appliance, as opposed to complicated > and > redundant site-specific exercises. Its also our best shot at getting *supported* > read-only shared Linux code. Shared installations are supported today: You can install on a DCSS with xip2fs in Sles8+9, and I think that in the future my execute in place soloution which is in the vanilla kernel tree will also become available on all distributions. On the other hand, doing a shared installation (and maintaining it) requires a skilled system programmer who is willing to dig into this. An appliance-type "inflate an forget" installation would definitely help. -- Carsten Otte IBM Linux technology center ARCH=s390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
