[libvirt-users] About libvirtd daemon start issue

Dennis Chen dennis.chen at tnsoft.com.cn
Fri Jul 6 03:41:52 UTC 2012


On 07/05/2012 07:57 PM, Eric Blake wrote:
> 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 at 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 at 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 at 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




More information about the libvirt-users mailing list