> We are going with a lot of Linux Guests under VM. Close to 20 > per IFL and are wondering about the experiences with the > basevol/guestvol scenario. How many People accually use this > scenario?
At least a dozen of our customers do. CA obviously does (see Bill's paper). It's proven to be a pretty good choice when you need a lot of fairly similar machines that don't change configuration too often. > How much DASD does this really save you? Is it > worth the time and effort it takes to set this up? It depends a lot on how well-behaved your applications are in terms of keeping all their files together. A lot of ISVs violate Mother's Second Rule (Thou Shalt Not Mix Your Code and System Code), which makes it more a maintenance issue than a disk space issue. IF your application is well-behaved enough to keep all it's pieces together, then it makes a fair amount of difference. > Could you > just setup Links to specific disks in VM for a Guest like if > you just wanted to share the binaries for say Oracle, or the > /usr directory or /home directory? No, because in the case of Oracle and a lot of the ISV software you mentioned, the application wants to dump code outside the directory that holds the main binaries. You also need to have write access to the RPM catalog and some other stuff (something I consider to be a design flaw in RPM -- no provision for concatenated user and system software catalogs). /home is difficult because of the multi-system caching problem -- virtal machines are really separate systems, and each does separate caches of R/W data that are completely ignorant of each other. Without something like AFS or GFS to coordinate writes, you get bad corruption problems. Best solution there is to use NFS or one of the more sophisticated filesystems mentioned previously to handle /home. > Wouldn't this accomplish > the same thing? What would be the best way to go about this? See above. You're somewhat mixing up two problems: shared resources and operational maintenance. The basevol/guestvol concept is attempting to handle the operational maintenance problem (ie, how do you distribute fixes and do configuration control). Sharing disks takes it into configuration management (how do I share binaries, but deal with the fact that the applications expect stuff to appear in places outside the directory holding the binaries). "Best" is a hard thing to define. What I'd suggest is: 1) Use the basevol/guestvol setup to manage the system configuration information and /usr, which tend not to be particularly volatile (changes are usually infrequent). 2) Set up a separate guest LAN and create some dedicated guests for the function of NFS file servers. Mount the "shared" application information via NFS, ie /opt, /usr/local, etc. Same thing for shared R/W filesystems like /home. 2a) (more sophisticated variation) Set up separate guest LAN and use some dedicated guests as AFS servers. This takes more sophistication at the start, but it's more scalable and secure than NFS, and allows better disk management from a enterprise standpoint. > Does SUSE support the basevol/guestvol out > of the box, or are their some packages that need installing > to make this work? Not out of the box -- it's a configuration decision, not a code thing. It requires modifying two of the SuSE startup scripts to overmount the common /etc with the system specific ones during boot. > How stable is it running under this > basevol/guestvol scenario? Very. Maintenance planning is the key to making this work. Day to day, it's a no-brainer. I'd venture to say that if more ISVs used a method like this, we'd finally be able to stamp out the assumption that it's OK to scatter files around the filesystem, and end up with a lot better world. I'm *very* glad that CA has adopted this approach. Now we need to work on IBM, and Tivoli, and ... 8-( -- db ---------------------------------------------------------------------- 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
