Thanks Jérémy, That was what I needed. I was afraid to be headed to the wrong way. Now that I know what to do, I need to know where and when.
> you could create a template (xendomains@.service) and use drop-ins to do > per-instance overrides > (/etc/systemd/system/xendomains@vm1.service.d/append.conf) > that would allow you to individualize each domain while keeping the common > parts > > I would find a way to prevent a domain with no corresponding to start > (maybe by not defining a mandatory key in the template) to make sure no > rogue domains are created... > I would use a template like xendomains@.service in order to specify common stuff. However, the config of which vm are enabled (autostart) is only available at boot time. Is a systemd generator the way to go? Is is there another way to define it? Also, should I use a service patch (like append.conf you mentioned) or simply directly create /run/.../xendomains@vm1.service? It would be trivial to define a template xendomains@.service and start services like "systemctl start xendomains@vm1.service", that would read /etc/xen/vm/vm1 and launch it. I just don't know how I could define dynamic dependency for that instance depending on the content of /etc/xen/vm/vm1. Execstartpre can check requirements and prevent a service to run but not wait for a resource to be available. It would be something like ExecRequires=. Instances seems to be created only when asked directly (systemctl start xendomains@vm1.service), which might be triggered by something like udev event. Is there anything like ExecListStartInstances=, ExecListRunningInstances=? Generators can create something like that but they are triggered only at boot and daemon-reload. It would be interesting to somehow run "something like generators" when start/stop/status is called. >From what I know about systemd, I'm thinking of something like a generator that will create services for all autostart and saved vm. The current script-based xendomains.service will run after all xendomains@.service instances. This way, a new enabled-after-boot vm would be started with "systemctl restart xendomains". I could use the existence of /etc/xen/auto/vm or /var/lib/xen/save/vm as requirement for xendomains@vm.service, in order to avoid to start a disabled-after-boot vm. However, this does not look like an elegant solution. Regards, > -- Luiz Angelo Daros de Luca luizl...@gmail.com
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel