2014-10-06 13:07:13 |
Stefan Bader |
description |
Now that libvirt also checks for the right contents of /proc/xen/control_d there are some cases where things are not quite ready when libvirt checks. Looking at the upstart rules, libvirt currently starts on entering runlevel 2345. kvm/qemu also uses the same trigger and xen is still using init.d scripts. Since there is no way of exactly predicting which hypervisor has to come up (could be kvm/qemu or xen or none), the sanest approach right now seems to delay startup until rc emulation has finished. This should cover them all. So instead:
start on startup runlevel [2345]
we would use
start on stopped rc RUNLEVEL=[2345] |
Now that libvirt also checks for the right contents of /proc/xen/capabilities there are some cases where things are not quite ready when libvirt checks. Looking at the upstart rules, libvirt currently starts on entering runlevel 2345. kvm/qemu also uses the same trigger and xen is still using init.d scripts. Since there is no way of exactly predicting which hypervisor has to come up (could be kvm/qemu or xen or none), the sanest approach right now seems to delay startup until rc emulation has finished. This should cover them all. So instead:
start on startup runlevel [2345]
we would use
start on stopped rc RUNLEVEL=[2345] |
|