[Libvir] Autostarting guests and networks
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? Cheers, Mark.
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. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On 2/17/07, Daniel P. Berrange <berrange@redhat.com> wrote:
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.
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.
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.
Do we need to match the new Xend mechanism ? Daniel
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? Cheers, Mark.
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.
- 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)
We should assume filename == domain name - all the files we save have that property and we should either complain about files which don't match, or 'fix them up' as we load them.
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?
Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
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 :-) Daniel -- 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/
Daniel P. Berrange wrote:
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.
A case just came up on Fedora-Xen where someone wanted to ensure that one particular domU started before the others. Made me think that we ought to include some well defined way to order the domains we want to autostart. Maybe a sysV init-style thing since we're talking about putting autostart configs in a directory... --H -- Red Hat Virtualization Group http://redhat.com/virtualization Hugh Brock | virt-manager http://virt-manager.org hbrock@redhat.com | virtualization library http://libvirt.org
Hugh Brock wrote:
A case just came up on Fedora-Xen where someone wanted to ensure that one particular domU started before the others. Made me think that we ought to include some well defined way to order the domains we want to autostart. Maybe a sysV init-style thing since we're talking about putting autostart configs in a directory...
Do you mean waiting for a domain to start completely before starting the next one? That sounds hard. On the other hand, in vanilla Xen it's simple just to order the files in /etc/xen/auto/ alphabetically, and the domains will start in the same order (or at least they did in 3.0.2): $ ls -1 /etc/xen/auto/ 00-nfs 10-database 20-ftp 20-mail 20-web 30-bid 30-stats 40-blog 70-dev 80-aigars 80-dpress 80-gallery 80-jlo Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)
participants (6)
-
Daniel P. Berrange -
Daniel Veillard -
Daniel Veillard -
Hugh Brock -
Mark McLoughlin -
Richard W.M. Jones