Activity log for bug #1377900

Date Who What changed Old value New value Message
2014-10-06 11:57:10 Stefan Bader bug added bug
2014-10-06 11:57:25 Stefan Bader libvirt (Ubuntu): status New Triaged
2014-10-06 11:57:29 Stefan Bader libvirt (Ubuntu): assignee Stefan Bader (smb)
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]
2014-10-06 14:11:23 Stefan Bader libvirt (Ubuntu): importance Undecided High
2014-10-06 17:31:45 Launchpad Janitor libvirt (Ubuntu): status Triaged Fix Released