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