[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt-users] About libvirtd daemon start issue



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/

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org



Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]