Bug 821433

Summary:	Add a new function in libvirt.c
Product:	[Community] Virtualization Tools	Reporter:	xuanmao <xuanmao_001>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	dallan, dyasny, eblake
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-05-15 22:13:15 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.