- Devel - libvirt List Archives

[Libvir] [PATCH] Allow modifying existing block device, making virDomainAttachDevice modify the device if it already exists
by Hugh Brock 10 Sep '07

10 Sep '07

The attached patch adds code to xend_internal.c:xenDomainAttachDevice that checks to see if the device mentioned in the passed-in XML already exists, and if so calls op_device_configure to modify the device. It is particularly useful for connecting and disconnecting a hardware cdrom device to an FV guest. I considered making new API a la virDomainModifyDevice, but decided overloading virDomainAttachDevice was cleaner (and didn't change existing API). I have tested the patch on f7 with xen 3.1 and a windows 2000 guest. Since the patch merely wraps Xen's device_configure call, we're not adding much risk of breakage. Please ACK. Take care, --Hugh -- Red Hat Virtualization Group http://redhat.com/virtualization Hugh Brock | virt-manager http://virt-manager.org hbrock(a)redhat.com | virtualization library http://libvirt.org

3 4

[Libvir] Documentation errors and shortcomings
by Tóth István 10 Sep '07

10 Sep '07

Hello! I am currently working on java bindings for libvirt, and in the process I have found a few bugs with the documentation, and also what I believe to be a design problem in the API. 1. The parameterized C macros do not have their arguments listed either on libvirt.org, or in the docs folder in the distribution list, even though there is a a documentation block in the actual source file. I guess it's some kind of problem with the tool used for generating the docs. 2. The virConnectGetCapabilities function docs says that it returns an opaque pointer to a struct, when in fact it returns an XML string describing the capabilities. 3. I have found no sanctioned way to actually get the data from DomainBlockStats and DomainInterfaceStats. The strucures are defined as _virDomainBlockStats and struct _virDomainInterfaceStats, and there is only an *Ptr type typedef-ed on them, as in the case of, say virConnectPtr, which IS really meant to be opaque. I believe that the fields of these structs ARE meant to be read by the applications linking the library, and are not really meant to be opaque. (or if they are, they should have some functions/macros that you can access their contents with) I think the right way to fix this would be simply to typedef them as typedef struct _virDomainBlockStats virDomainBlockStats; typedef struct _virDomainInterfaceStats DomainInterfaceStats; expose their fields in the documentation, and not call them opaque ( i.e. treat them just like virSchedParameter) best regards István

4 3

[Libvir] [PATCH] Support Sun's Compiler
by Mark Johnson 08 Sep '07

08 Sep '07

The following patch allows libvirt to be compiled with Sun's CC compiler. tested on today's CVS bits on a FC7 dom0 (LD_PRELOAD=src/.libs/libvirt.so src/.libs/virsh) Thanks, MRJ

2 3

[Libvir] Documentation errors and shortcomings
by Toth Istvan 08 Sep '07

08 Sep '07

Hello! I am currently working on java bindings for libvirt, and in the process I have found a few bugs with the documentation, and also what I believe to be a design problem in the API. 1. The parameterized C macros do not have their arguments listed either on libvirt.org, or in the docs folder in the distribution list, even though there is a a documentation block in the actual source file. I guess it's some kind of problem with the tool used for generating the docs. 2. The virConnectGetCapabilities function docs says that it returns an opaque pointer to a struct, when in fact it returns an XML string describing the capabilities. 3. I have found no sanctioned way to actually get the data from DomainBlockStats and DomainInterfaceStats. The strucures are defined as _virDomainBlockStats and struct _virDomainInterfaceStats, and there is only an *Ptr type typedef-ed on them, as in the case of, say virConnectPtr, which IS really meant to be opaque. I believe that the fields of these structs ARE meant to be read by the applications linking the library, and are not really meant to be opaque. (or if they are, they should have some functions/macros that you can access their contents with) I think the right way to fix this would be simply to typedef them as typedef struct _virDomainBlockStats virDomainBlockStats; typedef struct _virDomainInterfaceStats DomainInterfaceStats; expose their fields in the documentation, and not call them opaque ( i.e. treat them just like virSchedParameter) best regards István

1 0

[Libvir] Documentation errors and shortcomings
by Toth Istvan 08 Sep '07

08 Sep '07

Hello! I am currently working on java bindings for libvirt, and in the process I have found a few bugs with the documentation, and also what I believe to be a design problem in the API. 1. The parameterized C macros do not have their arguments listed either on libvirt.org, or in the docs folder in the distribution list, even though there is a a documentation block in the actual source file. I guess it's some kind of problem with the tool used for generating the docs. 2. The virConnectGetCapabilities function docs says that it returns an opaque pointer to a struct, when in fact it returns an XML string describing the capabilities. 3. I have found no sanctioned way to actually get the data from DomainBlockStats and DomainInterfaceStats. The strucures are defined as _virDomainBlockStats and struct _virDomainInterfaceStats, and there is only an *Ptr type typedef-ed on them, as in the case of, say virConnectPtr, which IS really meant to be opaque. I believe that the fields of these structs ARE meant to be read by the applications linking the library, and are not really meant to be opaque. (or if they are, they should have some functions/macros that you can access their contents with) I think the right way to fix this would be simply to typedef them as typedef struct _virDomainBlockStats virDomainBlockStats; typedef struct _virDomainInterfaceStats DomainInterfaceStats; expose their fields in the documentation, and not call them opaque ( i.e. treat them just like virSchedParameter) best regards István

1 0

[Libvir] Memory leak in XenHypervisorMakeCapabilitiesXML?
by beth kon 08 Sep '07

08 Sep '07

Hi. Seems to me there is a memory leak with the strdup function in xenHypervisorMakeCapabilitiesXML. Looking up the chain of calls leading to xenHypervisorMakeCapabilitiesXML, I don't see the required free for the hidden malloc in the strdup. The same problem may exist with other strdups in the code. -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak(a)us.ibm.com

2 1

[Libvir] build problem
by Mark Johnson 08 Sep '07

08 Sep '07

I'm having problems building the libvirt cvs bits (clean) on FC 7. I'm sure I'm doing something stupid?? I don't see xdr_qemud_packet_client anywhere in the source? Any ideas? Thanks, MRJ ../src/.libs/libvirt_la-qemu_internal.o: In function `qemuProcessRequest': /home/mrj/libvirt/src/qemu_internal.c:312: undefined reference to `xdr_qemud_packet_client' /home/mrj/libvirt/src/qemu_internal.c:375: undefined reference to `xdr_qemud_packet_server' collect2: ld returned 1 exit status make[3]: *** [xmlrpctest] Error 1 make[3]: Leaving directory `/home/mrj/libvirt.hg/tests' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/mrj/libvirt.hg/tests' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/mrj/libvirt.hg' make: *** [all] Error 2

2 2

[Libvir] libvirt statistics
by Richard W.M. Jones 07 Sep '07

07 Sep '07

[Using `pahole' and friends - see http://git.kernel.org/?p=linux/kernel/git/acme/pahole.git;a=summary and https://ols2006.108.redhat.com/2007/Reprints/melo-Reprint.pdf ] These are all on x86-64. You'll get slightly different results on a 32 bit arch. Largest structures, by size: qemud_vm_def: 16608 4 qemud_vm_os_def: 16436 1 _testConn: 14504 2 qemud_vm: 12368 2 qemud_network: 8240 0 qemud_vm_disk_def: 4376 2 qemud_driver: 4192 1 qemud_vm_net_def: 4136 2 xenXMConfCache: 4112 0 _virProxyFullPacket: 4096 0 _xmlParserCtxt: 696 5 _virDriver: 432 1 utsname: 390 0 _testDom: 360 0 _xmlXPathContext: 352 4 xenUnifiedDriver: 328 0 dirent: 280 0 _xmlSAXHandler: 256 1 _IO_FILE: 216 2 _xenUnifiedPrivate: 192 1 qemud_network_def: 192 2 _xmlDoc: 168 2 _virConnect: 168 0 _testNet: 156 0 Structures with holes which could be made smaller by packaging (third number is how many bytes you'd save per allocation): qemud_vm 12368 12360 8 qemud_vm_def 16608 16600 8 private_data 56 48 8 remote_domain_get_info_ret 40 32 8 XDR 48 40 8 xen_v0_vcpuinfo 40 32 8 _xmlValidCtxt 112 104 8 _xmlEntity 136 128 8 _xmlParserCtxt 696 672 24 _testConn 14504 14496 8 _xmlURI 80 72 8 _xmlXPathObject 72 56 16 _xmlXPathParserContext 80 72 8 _xmlXPathContext 352 336 16 _xmlError 88 80 8 _xmlAttr 96 88 8 _xmlDoc 168 160 8 _xmlNode 120 112 8 _IO_FILE 216 208 8 _virDomainInfo 40 32 8 Longest functions (NB: long functions are not a bad thing -- read Steve McConnell). qemudParseVMDef: 9680 doRemoteOpen: 6631 xenXMParseXMLToConfig: 5678 xenXMDomainFormatXML: 5678 xend_parse_sexp_desc: 5424 qemudBuildCommandLine: 5204 virDomainParseXMLDesc: 3503 qemudGenerateXML: 2556 __virErrorMsg: 2332 testOpenFromFile: 2210 call: 2206 qemudStartNetworkDaemon: 2105 virDomainParseXMLOSDescHVM: 2078 qemudParseNetworkDef: 2023 xenHypervisorMakeCapabilitiesXML: 1838 virDomainParseXMLDiskDesc: 1686 qemudStartVMDaemon: 1683 xenXMConfigCacheRefresh: 1547 xenXMParseXMLDisk: 1545 virConfParseValue: 1516 virConfParse: 1457 qemudScanConfigDir: 1396 testLoadNetwork: 1353 dhcpStartDhcpDaemon: 1259 virXen_getvcpusinfo: 1257 testLoadDomain: 1244 qemudDomainSave: 1194 virDomainParseXMLIfDesc: 1164 xenHypervisorInit: 1104 xenXMDomainDefineXML: 1083 iptablesAddRemoveRule: 1081 testOpen: 1075 Functions with the most variables (perhaps a better indicator of "complexity", I know that doRemoteOpen is a bloody complicated function for example): xenXMDomainFormatXML: 18 virDomainParseXMLDesc: 18 doRemoteOpen: 18 testLoadDomain: 17 xenHypervisorMakeCapabilitiesXML: 16 testLoadNetwork: 15 xenXMParseXMLDisk: 14 xenStoreLookupByName: 13 xend_parse_sexp_desc: 13 virDomainParseXMLDiskDesc: 13 testOpenFromFile: 12 qemudBuildCommandLine: 12 xenStoreDomainGetNetworkID: 10 xenDaemonDomainGetVcpus: 10 virDomainParseXMLOSDescHVM: 10 qemudParseInterfaceXML: 10 xenXMParseXMLVif: 9 xenXMParseXMLToConfig: 9 xenXMDomainDefineXML: 9 query_parse: 9 iptablesAddRemoveRule: 9 xenStoreListDomains: 8 xenHypervisorLookupDomainByUUID: 8 xenHypervisorInit: 8 xenDaemonListDomainsOld: 8 virDomainParseXMLOSDescPV: 8 virDomainParseXMLIfDesc: 8 testNetworkDumpXML: 8 testDomainDumpXML: 8 qemudNetworkIfaceConnect: 8 qemudGenerateXML: 8 qemudDomainSave: 8 Functions with more than one "goto" label: qemudAddIptablesRules: 10 doRemoteOpen: 4 xenDaemonOpen: 3 qemudStartNetworkDaemon: 3 qemudExtractVersionInfo: 3 xenXMDomainFormatXML: 2 xenHypervisorInit: 2 xend_parse_sexp_desc: 2 virParseXMLDevice: 2 __virGetNetwork: 2 __virGetDomain: 2 virDomainXMLDevID: 2 remoteForkDaemon: 2 query_parse: 2 qemudStartup: 2 qemudNetworkIfaceConnect: 2 qemudGenerateXML: 2 qemudBuildCommandLine: 2 negotiate_gnutls_on_connection: 2 Functions with the most parameters (in C these are dangerous because of C's lousy typechecking): __virRaiseError: 12 xenXMConfigSetIntFromXPath: 8 xenUnifiedDomainMigratePrepare: 8 xenDaemonDomainMigratePrepare: 8 __virDomainMigratePrepare: 8 remoteDomainMigratePrepare: 8 qemudReadMonitorOutput: 8 call: 8 xenXMConfigSetStringFromXPath: 7 xenUnifiedDomainMigratePerform: 7 xenDaemonDomainMigratePerform: 7 _virExec: 7 __virDomainMigratePerform: 7 remoteDomainMigratePerform: 7 xenUnifiedDomainMigrateFinish: 6 xend_op_ext2: 6 virXen_getvcpusinfo: 6 virExecNonBlock: 6 virExec: 6 virDomainParseXMLOSDescHVM: 6 __virDomainMigrateFinish: 6 virDomainMigrate: 6 remoteDomainMigrateFinish: 6 All global variables (nothing wrong with global variables, I say): extern unsigned int __invalid_size_argument_for_IOC; /* 0 */ struct qemu_feature_flags arch_info_i686_flags[4]; /* 0 */ struct qemu_feature_flags arch_info_x86_64_flags[3]; /* 0 */ struct qemud_driver * qemu_driver; /* 0 */ struct qemu_arch_info qemudArchs[7]; /* 1 */ extern struct _IO_FILE * stderr; /* 9 */ extern struct _IO_FILE * stdin; /* 23 */ extern struct _IO_FILE * stdout; /* 23 */ enum /**/ virDrvOpenRemoteFlags; /* 0 */ struct xenUnifiedDriver xenDaemonDriver; /* 1 */ struct xenUnifiedDriver xenHypervisorDriver; /* 1 */ struct xenUnifiedDriver xenProxyDriver; /* 1 */ struct xenUnifiedDriver xenStoreDriver; /* 1 */ struct xenUnifiedDriver xenXMDriver; /* 1 */ extern xmlFreeFunc xmlFree; /* 3 */ extern xmlMallocFunc xmlMalloc; /* 0 */ Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

3 3

[Libvir] feature sujestions
by Márcio Parise Boufleur 06 Sep '07

06 Sep '07

Hello, I'm a grad student from Brazil. I was looking for some interesting project to do as my final work and it I think that contributing to your project would be a great achievement to me. Do you have some kind list with feature suggestions? I am particularly interested in remote administration. I helped a colleague to write a graphical tool to administrate a remote Xen site last year. Thank you. MB -- Computers are useless; they can only give you answers! -- Picasso

5 7

[Libvir] Compiling libvirt v0.3.2 on centos5
by Meng Kuan 05 Sep '07

05 Sep '07

Hi, Here is what I did when I tried to upgrade the libvirt on my centos5 system to the latest version. sudo yum install python-devel xen-devel libxml2-devel readline- devel gnutls-devel wget ftp://libvirt.org/libvirt/libvirt-0.3.2-1.src.rpm sudo rpmbuild --rebuild libvirt-0.3.2-1.src.rpm ... ... RPM build errors: InstallSourcePackage: Header V3 DSA signature: NOKEY, key ID de95bc1f user veillard does not exist - using root user veillard does not exist - using root Installed (but unpackaged) file(s) found: /usr/share/doc/libvirt-0.3.2/html/FAQ.html /usr/share/doc/libvirt-0.3.2/html/Libxml2-Logo-90x34.gif /usr/share/doc/libvirt-0.3.2/html/examples.xml /usr/share/doc/libvirt-0.3.2/html/examples.xsl /usr/share/doc/libvirt-0.3.2/html/html/book1.html /usr/share/doc/libvirt-0.3.2/html/html/home.png /usr/share/doc/libvirt-0.3.2/html/html/index.html /usr/share/doc/libvirt-0.3.2/html/html/left.png /usr/share/doc/libvirt-0.3.2/html/html/libvirt-bridge.html /usr/share/doc/libvirt-0.3.2/html/html/libvirt-conf.html /usr/share/doc/libvirt-0.3.2/html/html/libvirt- gnutls_1_0_compat.html /usr/share/doc/libvirt-0.3.2/html/html/libvirt-lib.html /usr/share/doc/libvirt-0.3.2/html/html/libvirt-libvirt.html /usr/share/doc/libvirt-0.3.2/html/html/libvirt-util.html /usr/share/doc/libvirt-0.3.2/html/html/libvirt-uuid.html /usr/share/doc/libvirt-0.3.2/html/html/libvirt-virterror.html /usr/share/doc/libvirt-0.3.2/html/html/right.png /usr/share/doc/libvirt-0.3.2/html/html/up.png /usr/share/doc/libvirt-0.3.2/html/info1.c /usr/share/doc/libvirt-0.3.2/html/libvir.html /usr/share/doc/libvirt-0.3.2/html/redhat.gif /usr/share/doc/libvirt-0.3.2/html/suspend.c /usr/share/doc/libvirt-python-0.3.2/TODO /usr/share/doc/libvirt-python-0.3.2/examples/basic.py /usr/share/doc/libvirt-python-0.3.2/examples/create.py /usr/share/doc/libvirt-python-0.3.2/examples/error.py /usr/share/doc/libvirt-python-0.3.2/examples/node.py /usr/share/doc/libvirt-python-0.3.2/examples/uuid.py I tried to get around this by putting the following in the ~/.rpmmacros file (according to this webpage http://www.rpm.org/ hintskinks/unpackaged/): _unpackaged_files_terminate_build 0 _missing_doc_files_terminate_build 0 However, that does not seem to help. Any ideas? Should I just install the binary packages instead of building from source? cheers, mengkuan

4 5