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

Re: [Libvir] Autostarting guests and networks

On Wed, Feb 21, 2007 at 01:29:31PM +0000, Daniel P. Berrange wrote:
> On Wed, Feb 21, 2007 at 11:54:13AM +0000, Mark McLoughlin wrote:
> > On Sat, 2007-02-17 at 14:12 +0800, Daniel Veillard wrote:
> >  
> > > Agreed let's not mix policies and data. However I assume the API would allow
> > > to define directories for autostarted configs. I guess having predefined dirs for
> > > such data is a common concept. And trying to hard code it like /etc/xen is
> > > really not the best. IIRC we already have a config file now for some daemons,
> > > can we have such directories entries in the config file ? I guess it would give
> > > the flexibility required for most uses while keeping a relatively sane API and
> > > avoiding putting the policy in the data themselve.
> > 
> > 	I don't think this is specific to the autostart support - i.e. we
> > already define /etc/libvirt/qemu as the location for qemud domain
> > definitions and don't have a configurable way of allowing other
> > directories.
> I think it is fine to hardcode at build time - simply allow use of a flag to
> configure to change the default, or let the user override the default with a
> flag to the libvirt_qemud process
> > 
> > 	I've no objection to allowing multiple locations and making that
> > configurable, but there is a few things to bear in mind:
> I think allowing multiple directories is complete overkill and unnneccessarily
> complicates the code, as you point out below...  We're not really expecting
> admins to manage these config files directly in any case, so I can't really
> see any benefit to using many dirs.

  I was thinking of case where we have unified daemons, and
where is may serve for example local QEmu virtualization but
also cluster like one where all data are expected to be on some
shared storage. Compile time only setting are IMHO not okay
in the long term, and I'm not even convinced that a single 
directory will be sufficient either. I could perfectly see
how an user need one kind of network data, and that the cluster
softare being used on that box too needs completely different 
data on a external storage. At least make it a runtime option
in some ways, or I'm just missing something :-)


Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

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