[libvirt-users] How does libvirt interaction with KVM to create a VM?

[Dennis Chen]

On 06/29/2012 02:49 PM, Daniel Veillard wrote:
> On Fri, Jun 29, 2012 at 02:18:17PM +0800, Dennis Chen wrote:
>> On 06/28/2012 06:26 PM, Daniel P. Berrange wrote:
>>> The '/dev/kvm' device is the low level kernel interface for creating
>>> virtual domains. This is not actually used by libvirt at all. The
>>> QEMU binary has code that talks to /dev/kvm, so all libvirt does is
>>> to spawn a QEMU process which in turns creates the virtual machine
>>>
>>> All the libvirt code for this part is under $GIT/src/qemu/  in particular
>>> the qemu_command.c and qemu_process.c files
>>>
>>> Daniel
>> Thanks Daniel, now I understand that the libvirt code will play with
>> QEMU binary, for example, qemu-system-x86_64, the latter will talk
>> with KVM module .  But now the question is, I guess
>> qemuProcessStart() function was used to spawn a QEMU process, so I
>> built a virsh from the source package with "-g -O0" flag, I want to
>> gdb the virsh, but when I want to set a break point on
>> qemuProcessStart(), I encounter issue:
>>
>> #gdb virsh
>> (gdb) b main
>> Breakpoint 1 at 0x807d480: file virsh.c, line 20270.
>> (gdb) r
>> Starting program: /usr/bin/virsh
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
>>
>> Breakpoint 1, main (argc=1, argv=0xbffff294) at virsh.c:20270
>> 20270    {
>> (gdb) b qemuProcessStart
>> Function "qemuProcessStart" not defined.
>> Make breakpoint pending on future shared library load? (y or [n]) y
>> Breakpoint 2 (qemuProcessStart) pending.
>>
>> (gdb)c
>>
>> virsh # create guest.xml
>> Domain vdo created from vdo.xml
>>
>> virsh #
>>
>> continue instruction above doesn't hit the pending Breakpoint 2...
>>
>> So my question is, which kind of object file will be created from
>> $GIT/src/qemu folder during the build process, is it a .so file and
>> virsh will load it?
>    virsh talks to the libvirtd daemon, the libvirtd daemon run those
> calls from the qemu driver. The documentation is relatively sparse,
> but reading what is available will help:
>
>     http://libvirt.org/api.html
>     http://libvirt.org/internals.html
>
> so if you want to step though that function you must gdb the libvirt
> daemon, not the client application.
>
> Daniel

en, this Daniel is not that Daniel: ) I remember that I joined the 
presentation about
libvirt delivered by you in Nanjing University last year.

Yes, the document about libvirt is sparse, so I am often confused when I 
try to
understand the internals of the relationship between QEMU, KVM and 
libvirt...

Let me go through the link you mentioned to see if I can understand 
libvirtd comes from
and the relationship with libvirt...

BRs,
Dennis