On Fri, Feb 16, 2007 at 02:51:07PM +0000, Mark McLoughlin wrote: > Hey, > We need some way to have libvirtd automatically start guests and > networks. > > We had said we should have autostart directories containing config > files of guests/networks which should be autostarted. One problem I see > with that is that we'd need a new API to define autostart configs. > > So, I suggest we add an "autostart" flag to the toplevel element of the > configs. > > We could discuss this one at length and I, for one, don't like using > the XML format as an API like this, but ... comments? I'm not sure that adding a flag to the XML is neccessarily the correct way to do this. The XML is intended to be a description of the VM's virtual hardware / resources. Whether a domain autostarts or not is really administrator defined policy which doesn't match up with intended use of the XML. Similar reason we don't put VCPU pinning information in the XML, because its local machine / administrator defined policy rather than a part of the VM hardware description. I think I'd probably be more inclined to add a formal API for querying whether a domain autostarts, and a second for setting the autostart flag on/off.

The old Xend just stuffs VM configs into a special directory to autostart, so we can detect that by looking for appropriate symlins, and change it by adding/removing the symlinks. The newer Xen 3.0.4 or later has a formal API for setting/querying autostart I believe, but can't remember the details just at the minute.

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've no objection to allowing multiple locations and making that configurable, but there is a few things to bear in mind:

- The common idiom for this is a stack of directories where definitions in later dirs higher in the stack override definitions in lower dirs - When a definition is saved, should it be saved in the highest dir in the stack, or where it was originally defined, or the later if it's writable but fall back to the former? - What about the mismatch between filenames and domain names? 1) Identical filenames with different domain names - if you have domain Foo in /etc/libvirt/qemud/foo.xml and domain Bar in /mydomains/foo.xml, should both domains be loaded or just the highest foo.xml in the stack? (If the former - think about saving. If e.g. you save Foo, it may be saved to /mydomains/foo.xml, overwriting the definition for Bar)

2) Identical domain names with different file names - if you have domain Foo defined in /etc/libvirt/qemud/foo.xml and another definition of domain Foo from /mydomains/bar.xml, should the highest definition win?

On Fri, Feb 16, 2007 at 02:51:07PM +0000, Mark McLoughlin wrote: > Hey, > We need some way to have libvirtd automatically start guests and > networks. > > We had said we should have autostart directories containing config > files of guests/networks which should be autostarted. One problem I see > with that is that we'd need a new API to define autostart configs. > > So, I suggest we add an "autostart" flag to the toplevel element of the > configs. > > We could discuss this one at length and I, for one, don't like using > the XML format as an API like this, but ... comments? I'm not sure that adding a flag to the XML is neccessarily the correct way to do this. The XML is intended to be a description of the VM's virtual hardware / resources. Whether a domain autostarts or not is really administrator defined policy which doesn't match up with intended use of the XML. Similar reason we don't put VCPU pinning information in the XML, because its local machine / administrator defined policy rather than a part of the VM hardware description. I think I'd probably be more inclined to add a formal API for querying whether a domain autostarts, and a second for setting the autostart flag on/off. The old Xend just stuffs VM configs into a special directory to autostart, so we can detect that by looking for appropriate symlins, and change it by adding/removing the symlinks. The newer Xen 3.0.4 or later has a formal API for setting/querying autostart I believe, but can't remember the details just at the minute.