I have virtual machines on drbd devices, so i need to start the drbd init script before libvird starts during bootup. I did try putting rc_use="drbd" into /etc/conf.d/libvirtd and rc_before="libvirtd" into /etc/conf.d/drbd, tried uppercase and lowercase rc_use and rc_before keywords, tried baselayout-1 and baselayout-2, neither did work. Finally i found out the problem: In /etc/init.d/libvirtd: before sshd And in /etc/init.d/drbd: after sshd This means the startup sequence will look like this: libvirtd -> sshd -> drbd. To solve my issue i needed to delete the before line from libvirtd and the after line from the drbd init script. After this, everything worked as expected. I could not think of any reason why libvird should be started before sshd and why drbd should be started after sshd. Maybe it is needed in some specific setups, but then these should be configured by the user in the corresponding /etc/conf.d/ files. So please remove "before sshd" from /etc/init.d/libvirtd and remove "after sshd" from /etc/init.d/drbd.
Actually the full before line in /etc/init.d/libvirtd is the following: before sshd ntp-client ntpd nfs nfsmount rsyncd portmap dhcp ntp-client ntpd: I do not understand these either, is it not better to have a synchronized clock before the virtual machines gets started? nfs: Is there any reason to start libvirtd before the nfs server starts? nfsmount: Maybe this is useful when somebody has an nfs server on a virtual machine, but the virtual machine would need some time to start up. rsyncd: Is there any connection between libvirtd and rsyncd? portmap: nfs and nfsmount already needs portmap, this is redundant here. dhcp: Virtual machines probably use dhcp to get their ip address. So in my opinion libvirtd should be started after dhcp, not before.
The guys who wrote those scripts probably have reasons for writing them that way. I don't know whether others are the "specific setups" or if yours, is also "specific". In that last case, please hack your scripts manually/create your own. I'm going to resolve the bug as NEEDINFO. If you are *absolutely sure* that you are right about this, reopen the bug, and we will process it.
