On 07/05/2012 03:40 AM, Dennis Chen wrote:
> Hi libvirt team,
>
> I found there are very few documents to mention how to launch a libvirtd
> daemon when built from the source code.
That's because the daemon is usually launched by installing a package
via your distro package manager, rather than manually.
> A moment ago, I un-install all the kvm related stuff (kvm module,
> libvirt, virt-manager, virsh, qemu-kvm...) from my ubuntu system.
That means you uninstalled the service setups.
> Then I built the libvirt from the source tar package:
>
> 1. #./autogen.sh --system --with-phyp --enable-debug=yes CFLAGS=-g
This works for building a libvirtd that can be run in place of an
installed one, but...
> 2. #make
> 3. #make install
...does NOT install services. That is, developers use ./autogen.sh to
reuse their existing service setup from the distro installation
alongside their in-tree libvirtd to test out new libvirtd features.
Side note: './autogen.sh --system' is currently hard-coded to Fedora
distro layout; if Ubuntu has picked a different installation layout,
then it might not work. Patches to ./autogen.sh are welcome (I don't
use Ubuntu often enough myself to know if this is an actual or just a
theoretical issue).
> Everything is OK :), but wait a minute --
>
> According to the instruction in
libvirt.org, the option flag "--system"
> in above step 1 will make the environment is the same as the pre-built
> package installation, eg, apt-get install ... because I found that the
> "libvirtd" daemon is not active with "ps aux | grep libvirtd", so
I try
> to start it manually:
>
> Method 1: root@dennis-:/home/dennis/workspace/AIX# service libvirtd start
> libvirtd: unrecognized service
That's because your distro packaging takes additional steps beyond 'make
install' in order to actually activate the service. I don't know what
those steps are for Ubuntu, but I do know that in libvirt.spec.in, you
can find those additional steps for a Fedora system (and it differs for
Fedora 15 vs. Fedora 16 to match Fedora's change from initd to systemd
as the service manager - which explains why 'make install' does not
worry about distro-specific details like how to install a service).
> Method 2: root@dennis-:/home/dennis/workspace/AIX# /etc/init.d/libvirtd
> start
> bash: /etc/init.d/libvirtd: No such file or directory
Again, that sounds like a distro-specific file included in part of the
packaging beyond what 'make install' provides.
> Method 3: root@dennis-:/home/dennis/workspace/AIX# /usr/sbin/libvirtd start
'libvirtd' does not take a 'start' argument; but you are correct that
you can manually run libvirtd with correct permissions instead of having
a service run it, for testing out functionality.
> 2012-07-05 09:20:42.225+0000: 32749: info : libvirt version: 0.9.12
> 2012-07-05 09:20:42.225+0000: 32749: error : virDomainDefParseXML:8303 :
> unknown OS type hvm
That error message could perhaps be improved to list _which_ domain
cannot be parsed. I know at one point we cleaned up our code to start
warning about unknown OS type instead of silently ignoring it; it may be
that you have effectively upgraded from an older version of libvirt that
ignored bad XML and your self-built libvirtd is warning. Is libvirtd
still running at this point, though?
> I don't know if the method 3 is success or not, but I have no time to
> verify it now, because I have to leave the office now for the later
> traffic jam... Why "unknow OS type hvm"?
>
> If my experiment is useful, then please document it in the
libvirt.org
> page...
Patches welcome. The
libvirt.org page is generated from libvirt.git/docs/
Well, After go though Eric's detailed explanation very carefully, I
found currently seems no best practice to manipulate the libvirtd daemon
manually. So I think a reasonable approach is install the distro package
and replace the libvirtd daemon process with the one built from the
source code ( The purpose I am doing this is to try to debug, or I want
to have more flexible to control the daemon itself...)
Eric, for above statement, educate me if I am wrong or you can think
more better method to control the daemon (start, stop...) in runtime
life cycle...
BRs,
Dennis