Bug 821433 - Add a new function in libvirt.c
Summary: Add a new function in libvirt.c
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-14 13:19 UTC by xuanmao
Modified: 2012-05-15 22:13 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-15 22:13:15 UTC
Embargoed:


Attachments (Terms of Use)

Description xuanmao 2012-05-14 13:19:47 UTC
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 15:20:13 UTC
This sort of question is probably better asked on the upstream development mailing list, libvir-list.

What custom options are you trying to add, and why?  Isn't the qemu-specific XML already sufficient for the purpose?
http://libvirt.org/drvqemu.html#qemucommand

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 17:05:09 UTC
thanks, I will try to understand more about remote driver and qemu driver.

Comment 3 Dave Allan 2012-05-15 22:13:15 UTC
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.