> Oh, you can't do that. It's not supported; you have to use NFS for that."
The problem is not with VM or Linux,
but with software management tools and really more with
how the packages are built by the package creators.
RPM, for example, wants to lay things out in specific places.
If any given package has files that go to /usr and others that
go to /etc, and /usr is read-only, you've got a problem.
The "master" will have all the files, the sharers will not.
The sharers will have no knowledge that the package has been
installed (RPM database). This is not entirely RPM's fault.
> This really took me by surprise, because, unless Linux just flat
> won't work with a read-only disk, I'd think that'd be the way to
> share things... I mean,... It's VM, right? Why incur the overhead
> for NFS when you could just read the minidisk directly. And one
> image wouldn't really even know the other image was sharing the device...
>
> Am I way off base?
You're not off base at all.
It's just that Linux has some growing up to do here.
This is nothing new to VM, and it's really nothing new to UNIX.
Solaris, for example, has been able to run with a shared /usr
for more than a decade. But Solaris is tightly controlled.
Solaris shares /usr read only by way of NFS.
NFS has the same problems with shared storage from the point of
package management. The only thing NFS offers that DASD sharing
does not is read-write, and that's not universally true
(and doesn't help the package mgmt problem!).
The best candidates for sharing are /usr and opt.
I run with shared copies of that all the time.
I just have to be careful to keep the RPM databases up-to-date
(or use alternatives; not all packages come in RPM form,
and those which don't may have no problem with this).
When installing any package, with any package management tool,
those files which fall into "private storage" must be copied
to ALL sharing Linux instances.
