7:57 p.m.
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org