I don't agree. In RHEL-6 we still use traditional init script for libvirtd so changing the error would be very misleading. The upstart job for libvirtd which vdsm uses is provided in /usr/share/doc and one needs to copy it to the right place first to start using it. And that's exactly what vdsm does.

Isn't this particular problem caused by libvirtd not removing the PIDfile on shutdown, thus preventing it working on next startup ?

Eyal, I agree with Jiri here, but I want to confirm something.  I don't see the error message currently referencing service; can you point out exactly the language that you think should be changed and what you think it should be changed to?

i think the point is if the service isn't managed by 'service' any more, than it should report so.
i.e.:
service libvirtd status should if it's running or not, regardless if it's running from service or initctl.
or at least should report an error that libvirtd is managed via initctl, rather than via service.

same for start.
i.e., instead of:
Starting libvirtd daemon: libvirtd: error: Unable to obtain pidfile. Check
/var/log/messages or run without --daemon for more info.

I'd expect something either checking the service is managed via initctl and warning about it:
"Starting libvirtd daemon: libvirtd: error: libvirtd is configured with initctl. please use initctl libvirtd start instead"

or (which i think would be more confusing):
"Starting libvirtd daemon: libvirtd: error: Unable to obtain pidfile. Check
/var/log/messages or run without --daemon for more info. This may also happen if libvirtd was started via initctl instead of the service command."

right now, it is very confusing to users that service libvirtd is saying it is not running and fails to start via the service command they know.

Thanks Itamar, that makes sense.  initctl status libvirt is pretty clear about whether it knows about libvirt.  I wonder if this will be an issue for systemd as well.

similar existing bug 726649.

I see your point, but this bz is about alerting the user to the fact that libvirt is being controlled by upstart, not the init script.

*** Bug 728758 has been marked as a duplicate of this bug. ***

*** Bug 726649 has been marked as a duplicate of this bug. ***

I think one of the major point of failure is that the upstart script
should not remove the pid file if the pointed process id is running and
a libvirt daemon.  Similary we must make sure that the init.d script
also fail to start a new daemon if there is one run under upstart control
(and again checking the pid file should be sufficient).

If we make sure those two case are correctly detected then I think the
probability of errors comming from confusion on how the daemon is started
in a RHEV environment with vdsm becomes very low. At least this won't result
in two daemon running concurrently !

Daniel

pkgs:
# rpm -q libvirt vdsm qemu-kvm kernel
libvirt-0.9.4-16.el6.x86_64
vdsm-4.9-106.el6.x86_64
qemu-kvm-0.12.1.2-2.195.el6.x86_64
kernel-2.6.32-206.el6.x86_64

Steps:
1.service vdsmd start
2.service libvirtd restart

Actual results:
# service vdsmd start
Stopping libvirtd daemon: libvirtd: libvirtd is managed by upstart and started, use initctl instead
vdsm: libvirt already configured for vdsm                  [  OK  ]
Starting iscsid: 
Starting up vdsm daemon: 
vdsm start                                                 [  OK  ]

# service libvirtd restart
Stopping libvirtd daemon: libvirtd: libvirtd is managed by upstart and started, use initctl instead

So, this is fixed.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause:
If both SysV init and Upstart scripts are installed (eg. when VDSM is installed) and libvirtd is managed by upstart, the SysV init script is unaware of this.

Consequence:
While libvirtd is managed by upstart, SysV init script reports confusing error messages to the user, as it is not aware of libvirtd running already. The user is unable to restart libvirtd using the SysV init script, and is unaware that libvirtd is managed by upstart.

Fix:
SysV init script now checks if libvird is managed by upstart, and in a positive case, user is notified, that he should use upstart tools to manage libvirtd.

Result:
Users are able to restart libvirtd without getting strange error messages from the SysV init script, while using upstart.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1513.html