[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FW: [Xen-devel] organizing virtual machines

  • To: <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
  • From: "Tom Hibbert" <tom@xxxxxxxxx>
  • Date: Tue, 22 Feb 2005 12:52:55 +1300
  • Delivery-date: Mon, 21 Feb 2005 23:53:34 +0000
  • List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
  • Thread-index: AcUYbS5Lm7RaU0MlTqOZY9YIKMs5hgAACfZgAACxQ0A=
  • Thread-topic: [Xen-devel] organizing virtual machines

-----Original Message-----
From: Eric S. Johansson [mailto:esj@xxxxxxxxxx]
Sent: Tuesday, 22 February 2005 12:29 p.m.
To: Tom Hibbert
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] organizing virtual machines

Tom Hibbert wrote:
>> There is no requirement for seperating partitions on installation. 
>> This is considered a best practice because in the event of a
>> 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.

Aha, I only have to read down to this level to see your issue. Gentoo is
a moving target. That means there is no advanced warning for major
updates such as the one you describe. Gentoo is best suited to
developers or hardline BSD refugees who cannot bear to let go of their
ports system.

Other distributions are different. Debian for instance is divided into
'stable' and 'unstable' distributions. For a package to be accepted into
'stable', it must cleanly upgrade from the previous version, including
the config files. Debconf handles most upgrades cleanly and the package
will at least issue a warning that a manual update is required. In a
production environment you have already tested your upgrades on a
staging server - don't even try and complain about not having enough
hardware to run a staging server, you have Xen now! - and you know what
configuration changes need to be made before you initiate an upgrade.
This is best practice for any system admin, even one running CP/M on a
cluster of dead badgers.

>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.

Great idea. You might want to take a look at debconf and read the Debian
packagers guide to give you some inspiration.


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.
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.