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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
