Bug 821433 - Add a new function in libvirt.c
Add a new function in libvirt.c
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Libvirt Maintainers
Depends On:
  Show dependency treegraph
Reported: 2012-05-14 09:19 EDT by xuanmao
Modified: 2012-05-15 18:13 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-05-15 18:13:15 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description xuanmao 2012-05-14 09:19:47 EDT
Description of problem:
I was add a new libvirt function in ./src/libvirt.c. name like virDomainAddCustomOptions(virDomainPtr domain, char *opt), then I declared it in ./include/libvirt/libvirt.h. and declared function name in ./src/libvirt_public.syms. finally I configure && make && make install. The whole process is OK. Libvirt source code will generic python code automaticlly. I call the python api name like (def addCustomOptions()), but failed. I checked out it Passed an error domain pointer to virDomainAddCustomOptions. The domain pointer passed to virDomainCreate in libvirt.c is "QEMU" driver. but it passed to virDomainAddCustomOptions is "remote" driver. I don't know why. please help me figure it out. thanks!

Version-Release number of selected component (if applicable):
Libvirt-0.9.8. qemu-1.0.50

How reproducible:
like upon

Steps to Reproduce:
1. add a new function in src/libvirt.c
2. declare this function in include/libvirt/libvirt.h
3. declare this function name in libvirt_public.syms
4. configure && make && make install
5. call it in python.
Actual results:
"remote" driver

Expected results:
"QEMU" driver

Additional info:
Comment 1 Eric Blake 2012-05-14 11:20:13 EDT
This sort of question is probably better asked on the upstream development mailing list, libvir-list@redhat.com.

What custom options are you trying to add, and why?  Isn't the qemu-specific XML already sufficient for the purpose?

As to your specific question, the reason that your code goes through the remote driver first is that ALL commands issued by libvirt.so for qemu must go through the remote driver to reach the libvirtd instance that will then re-execute the command locally with the correct privileges to reach the qemu driver.  Adding a new API for qemu involves touching both src/qemu _and_ src/remote.  Again, this is something better suited for discussion on the upstream list, rather than via a BZ.
Comment 2 xuanmao 2012-05-14 13:05:09 EDT
thanks, I will try to understand more about remote driver and qemu driver.
Comment 3 Dave Allan 2012-05-15 18:13:15 EDT
I'm closing as not a bug as I agree that it's better to discuss on the upstream list.

Note You need to log in before you can comment on or make changes to this bug.