From: "Eric S. Johansson" <esj@harvee.org>
To: Tom Hibbert <tom@nsp.co.nz>
Cc: xen-devel@lists.sourceforge.net
Subject: Re: organizing virtual machines
Date: Mon, 21 Feb 2005 18:29:17 -0500 [thread overview]
Message-ID: <421A6ECD.8030203@harvee.org> (raw)
In-Reply-To: <31F19452BA8B2042A359D849B74B1BF00C040A@aklexch01.nsp.local>
Tom Hibbert wrote:
> There is no requirement for seperating partitions on installation. This
> is considered a best practice because in the event of a partition
> faliure it increases the chance of recovering at least part of the
> system. In the purists world, / is mounted read-only and the only parts
> of the disk that can be written to without mounting readwrite are /var
> and /home.
(knock wood) I've never had a partition failure. They have always been
more on the lines of "*%#@%@ I lost another drive".
> Absolutely true. However, it is possible to have a shared root/usr using
> NFS, with independent /var, /home and /etc. This is a common
> configuration for clusters and big iron.
intriguing. Makes sense and one could also do this with the dom0
serving all the other virtual machines. would have some problems with
/etc however
> Dogs breakfast?
yea. a.k.a. "recycling" and in the wintertime "Poopsicles".
> Only in the event of badly constructed packages or an
> inexperienced aministrator installing from source should there ever be
> any configuration data stored outside of /etc. This is the sole reason
> /etc exists. I don't consider it a dogs breakfast at all, even under
> Gentoo.
I must politely disagree. In the example you gave above where root
end-user are shared, what happens when you change a program that also
has a related change in /etc? At best, nothing bad happens. At worst,
you start getting random failures that drive you mad until you finally
get all of the images changed. Sometimes it's a simple replication.
More often than not it's customized changes on all machines.
Even updating a single machine it can be a "this sucks" moment. I
cannot tell you the number of times I have updated gentoo and found that
I had to slog through 50 configuration file changes.
so, the reason I consider virtually all system configuration
directories, registries etc. a dogs breakfast is that they don't handle
change well and the changes are not replicated properly.
my fantasy world for proper system configuration management would record
baseline and changes so that when baseline changes one can re-create the
working configuration set (i.e. /etc). For a virtual machine
environment like xen, one could have virtual machine associated changes
with a common baseline so that when you update your executables and
configuration directory, all the changes replicate properly or can be
flagged for human attention.
I'm planning a working on this when I have some spare neurons.
---eric
--
http://www.salon.com/books/review/2004/12/18/heloise/index.html
The basis of Abelard's philosophy, which he taught to Heloise, was
that logic had to be applied to religion in order to arrive at the
truth.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
next prev parent reply other threads:[~2005-02-21 23:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-21 23:05 organizing virtual machines Tom Hibbert
2005-02-21 23:29 ` Eric S. Johansson [this message]
2005-02-22 0:45 ` Tim Freeman
[not found] <31F19452BA8B2042A359D849B74B1BF00C0415@aklexch01.nsp.local>
2005-02-22 1:10 ` Eric S. Johansson
2005-02-22 2:45 ` Eric S. Johansson
-- strict thread matches above, loose matches on Subject: below --
2005-02-21 22:53 Eric S. Johansson
2005-02-21 23:19 ` Andrew Theurer
2005-02-21 23:35 ` Anthony Liguori
2005-02-22 0:31 ` Mark Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=421A6ECD.8030203@harvee.org \
--to=esj@harvee.org \
--cc=tom@nsp.co.nz \
--cc=xen-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.