Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 405341

Summary: app-emulation/libvirt - init.d-script doesn't shut down the running guest on stop()
Product: Gentoo Linux Reporter: Eugen Mihailescu <eugenmihailescux>
Component: [OLD] UnspecifiedAssignee: Doug Goldstein (RETIRED) <cardoe>
Status: RESOLVED FIXED    
Severity: normal CC: virtualization
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Eugen Mihailescu 2012-02-22 21:23:17 UTC
I have a libvirtd (OpenRC) 0.9.8.4 on a Linux 3.2.6 SMP x86_64
The problem is the /etc/init.d/libvirtd script.

I have a Win2k3-r2 guest running.
If I call /etc/init.d/libvirtd stop then the daemon stops but the guest (qemu-kvm process) is still running.

It seems that the line 73 is not set properly:
   libvirtd_virsh ${LIBVIRTD_KVM_SHUTDOWN} ${dom_id} > /dev/null

I've seen that if I replace that line with:
   libvirtd_virsh qemu ${LIBVIRTD_KVM_SHUTDOWN} ${dom_id} > /dev/null

then it works as it is supposed to.

I don't really know if this is a bug or maybe it is just something wrong with my configuration, but in case that it can be confirmed by others then you know where the problem lies.
Comment 1 Doug Goldstein (RETIRED) gentoo-dev 2012-02-23 07:36:38 UTC
What version of libvirt? This is fixed in the tree for current versions for a few days afaik.
Comment 2 Eugen Mihailescu 2012-02-23 07:42:06 UTC
app-emulation/libvirt
      Latest version available: 0.9.10-r2
      Latest version installed: 0.9.10-r2
      Size of files: 18,642 kB
      Homepage:      http://www.libvirt.org/
      Description:   C toolkit to manipulate virtual machines
      License:       LGPL-2.1

The version I have installed is 0.9.10-r2.

I saw a similar fix at the line 105:
   libvirtd_virsh qemu net-destroy ${net_name} > /dev/null

From that line I got inspired when I've tested this fix:
   libvirtd_virsh qemu ${LIBVIRTD_KVM_SHUTDOWN} ${dom_id} > /dev/null

But, if I'm not totally wrong, the version that I emerged does not came with this fix by default, I had to do it myself (it's not a problem, but it is better to fix it in the main stream source).
Comment 3 Doug Goldstein (RETIRED) gentoo-dev 2012-02-23 16:54:10 UTC
I see what you mean now. This is fixed in the tree. Thanks for reporting it.
Comment 4 Eugen Mihailescu 2012-02-23 17:25:27 UTC
I've tried to install app-emulation/libvirt-9999 (which I suppose it's the latest available version on tree) and I've got an build error, something like:

...
>>> Unpacked to /var/tmp/portage/app-emulation/libvirt-9999/work/libvirt-9999
 * Running eautoreconf in '/var/tmp/portage/app-emulation/libvirt-9999/work/libvirt-9999' ...
 * Running aclocal -I m4 -I gnulib/m4 ...
 [ !! ]

 * Failed Running aclocal !
 * 
 * Include in your bugreport the contents of:
 * 
 *   /var/tmp/portage/app-emulation/libvirt-9999/temp/aclocal.out

 * ERROR: app-emulation/libvirt-9999 failed (prepare phase):
 *   Failed Running aclocal !
 * 
 * Call stack:
 *     ebuild.sh, line   85:  Called src_prepare
 *   environment, line 5816:  Called eautoreconf
 *   environment, line 1521:  Called eaclocal
 *   environment, line 1439:  Called autotools_run_tool '--at-m4flags' 'aclocal' '-I' 'm4' '-I' 'gnulib/m4'
 *   environment, line 1181:  Called die
 * The specific snippet of code:
 *           die "Failed Running $1 !";

I've tried to run:
 aclocal -I m4 -I gnulib/m4
in /var/tmp/portage/app-emulation/libvirt-9999/work/libvirt-9999
and I've found that it complains about:
  aclocal-1.11: couldn't open directory `gnulib/m4': No such file or directory

I've searched and there is no gnulib/m4 directory but lib/ and tests/

If I run:
  aclocal -I m4 -I gnulib 
it succeed, but I don't know how/where to make/try this change permanently (if it's safe this fix and do not break other things later).

Any advice?
Comment 5 Doug Goldstein (RETIRED) gentoo-dev 2012-02-23 21:35:39 UTC
(In reply to comment #4)
> I've tried to install app-emulation/libvirt-9999 (which I suppose it's the
> latest available version on tree) and I've got an build error, something like:
> 

Completely unrelated to the issue at hand. There's another ticket where -9999 is being fixed in. The only people that should be using -9999 are people developing against the upstream project.