September 2007 - Devel - libvirt List Archives

[Libvir] [PATCH] properly check buffer size in virDomainXMLDevID
by Hugh Brock 12 Sep '07

12 Sep '07

As promised, a patch to protect the 80-character "device id" buffer from overflow by the unbounded "device=" XML attribute. Before, a large "device" attribute gave a stack overflow error; now it merely results in an obscure (but non-fatal) xend error like so: libvir: Xen Daemon error : POST operation failed: (xend.err "invalid literal for int() with base 10: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'") (the long string of "x"es was my way of overflowing the buffer). Please ACK... --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

2 3

[Libvir] unsigned long
by John Levon 12 Sep '07

12 Sep '07

I just saw an email about unsigned long and max memory fly by along with a comment like "32-bit will never have more than 'X' Gb" ... This raises an obvious question: is libvirt explictly not 32/64 clean? On Solaris we build everything 32-bit by default unless there is a reason for it to be 64-bit. If a 32-bit libvirt can't handle a 64-bit kernel, then we have a problem. IMO an API should *always* use explicitly-sized integers when they contain range or size values (or use size_t etc.). Not doing so is both dangerous and confusing... (Xen does indeed have this problem, so we run all their tools with native word size. Currently we always use a 32-bit libvirt for 'virt-install', and it does seem to work fine. It would be a pity for this to change). cheers john

3 6

[Libvir] [PATCH] Remove warning when dumping XML from an inactive domain with Xen < 3.1
by Richard W.M. Jones 12 Sep '07

12 Sep '07

# virsh dumpxml solaris32fv libvir: Xen Daemon error : failed Xen syscall xenDaemonDomainDumpXML domain ID < 0 and xendConfigVersion < 3 0 [ and dump proceeds as normal ] The patch just removes the false error message and makes a note that this still needs a real fix later. 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] [PATCH] Fix enum virDrvOpenRemoteFlags
by Richard W.M. Jones 12 Sep '07

12 Sep '07

(Thanks Eduardo for pointing this one out ...) 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

2 2

[Libvir] Removing virDomainRestart typedef
by Richard W.M. Jones 12 Sep '07

12 Sep '07

virDomainReboot takes a flag argument which is documented as: * @flags: extra flags for the reboot operation, not used yet In fact, the test driver (alone) allows a virDomainRestart typedef to be passed as a flag, although it's not clear to me that anything actually does pass it. Certainly removing virDomainRestart typedef from <libvirt.h> doesn't break the build, and 'make check' is also OK. The attached patch moves virDomainRestart typedef into the test driver, which is the only thing using it. Another possibility would be to go further and remove the parts of the test driver which "test" this undocumented feature. (Thanks to Tóth István for pointing out that this typedef is unused). 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

1 0

[Libvir] PATCH: Fix KVM / QEMU pxe boot config
by Daniel P. Berrange 12 Sep '07

12 Sep '07

The XML config for PXE boot is being parsed/formatted incorrectly by the KVM tools. It is using 'net' instead of 'network' for the <boot> tag. I had even made this mistake in the test suite :-) Patch is simple - also fixed a flaw in the test suite code Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

3 2

[Libvir] Start NUMA work
by Daniel Veillard 12 Sep '07

12 Sep '07

Okay enclosed is a first patch to add the new entry point for getting the available memeory in the NUMA cells: /** * virNodeGetCellFreeMemory: * @conn: pointer to the hypervisor connection * @freeMems: pointer to the array of unsigned long * @nbCells: number of entries available in freeMems * * This call allows to ask the amount of free memory in each NUMA cell. * The @freeMems array must be allocated by the caller and will be filled * with the amounts of free memory in kilobytes for each cell starting * from cell #0 and up to @nbCells -1 or the number of cell in the Node * (which can be found using virNodeGetInfo() see the nodes entry in the * structure). * * Returns the number of entries filled in freeMems, or -1 in case of error. */ int virNodeGetCellsFreeMemory(virConnectPtr conn, unsigned long *freeMems, int nbCells) based on the feedback, it seems it's better to provide an API checking a range of cells. This version suggest to always start at cell 0, it could be extended to start at a base cell number, not a big change, is it needed ? The patch adds it to the driver interfaces and put the entry point needed in the xen_internal.c module xenHypervisorNodeGetCellsFreeMemory() . From there it needs a new function (or set of functions) actually doing one hypercall to get the free mem for a NUMA cell, and the loop to fill the array @freeMems. The hard part is of course to set the definitions and code doing the hypercall: We will need to check the current hypercall version since this was added recently, see how xenHypervisorGetSchedulerType() does the versionning, we will have to write a similar routine , extend xen_op_v2_sys to add support for the availheap call structures, add the define for the availheap system call, glue the whole and call the new function from the loop in xenHypervisorNodeGetCellsFreeMemory() ... this can be a little fun to debug. Now for extending virConnectGetCapabilities() it is a bit messy not not that much. First it's implemented on Xen using xenHypervisorGetCapabilities, unfortunately it seems the easiest way to get the NUMA capabilities is by asking though xend. Calling xend_internals.c from xen_internals.c is not nice, but xenHypervisorGetCapabilities() is actually noty using any hypervisor call as far as I can see, it's all about opening/parsing files from /proc and /sys and returning the result as XML, so this could as well be done in the xend_internals (or xen_unified.c) module. so we will have a bit of surgery to do, but for the first steps of writing the patch I would not be too concerned by calling a function in xend_internal.c from xenHypervisorGetCapabilities (or xenHypervisorMakeCapabilitiesXML) we will just move those 2 in the end (only problem may be the access to hv_version variable). Hope this helps, I will not be online most of the week but I will try to help when possible :-) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

3 4

[Libvir] can't start windows guest domains
by Thomas Antony 11 Sep '07

11 Sep '07

Hi. I'm running F7 x86_64 with kernel 2.6.20-2931.fc7xen and libvirt-0.3.2-1.fc7. Since i updated to the latest versions i can't start any windows domains anymore. I thought undefine and reinstall the domains could resolve the problem, but i get the exact same error message. There is also a F7 x86_64 guest domain runnning fine on the same host. Why i can't start any windows domains anymore? [thomas@srv1 ~]$ sudo virt-install -d -n sbs -r 512 --vcpus=1 -f /dev/VolGroup01/sbs -w bridge:virbr0 --vnc -k DE -v --arch=i386 --os-type=windows --os-variant=win2k3 -c /var/www/html/install/SBS2003R2DE_DVD.iso Mon, 10 Sep 2007 20:38:28 DEBUG Path is block file: Assuming Block disk type. Disk /dev/VolGroup01/sbs is already in use by another guest! Do you really want to use the disk (yes or no)? y Starting install... libvir: Xen Daemon error : GET operation failed: libvir: Xen Daemon error : GET operation failed: Mon, 10 Sep 2007 20:38:31 DEBUG Creating guest from '<domain type='xen'> <name>sbs</name> <currentMemory>524288</currentMemory> <memory>524288</memory> <uuid>5f73764f-897c-401c-e9e5-17cb21333334</uuid> <os> <type arch='i386'>hvm</type> <loader>/usr/lib/xen/boot/hvmloader</loader> <boot dev='cdrom'/> </os> <features> <apic/><acpi/><pae/> </features> <on_poweroff>destroy</on_poweroff> <on_reboot>destroy</on_reboot> <on_crash>destroy</on_crash> <vcpu>1</vcpu> <devices> <emulator>/usr/lib64/xen/bin/qemu-dm</emulator> <console device='pty'/> <disk type='block' device='disk'> <source dev='/dev/VolGroup01/sbs'/> <target dev='hda'/> </disk> <disk type='file' device='cdrom'> <source file='/var/www/html/install/SBS2003R2DE_DVD.iso'/> <target dev='hdc'/> <readonly/> </disk> <interface type='bridge'> <source bridge='virbr0'/> <mac address='00:16:3e:33:eb:7b'/> </interface> <graphics type='vnc' port='-1' keymap='DE' /> </devices> </domain> ' libvir: Xen Daemon error : POST operation failed: (xend.err "Error creating domain: (12, 'Cannot allocate memory')") virDomainCreateLinux() failed POST operation failed: (xend.err "Error creating domain: (12, 'Cannot allocate memory')") Domain installation may not have been successful. If it was, you can restart your domain by running 'virsh start sbs'; otherwise, please restart your installation. Mon, 10 Sep 2007 20:38:31 ERROR virDomainCreateLinux() failed POST operation failed: (xend.err "Error creating domain: (12, 'Cannot allocate memory')") Traceback (most recent call last): File "/usr/bin/virt-install", line 474, in <module> main() File "/usr/bin/virt-install", line 438, in main dom = guest.start_install(conscb,progresscb) File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 710, in start_install return self._do_install(consolecb, meter) File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 727, in _do_install self.domain = self.conn.createLinux(install_xml, 0) File "/usr/lib64/python2.5/site-packages/libvirt.py", line 563, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: virDomainCreateLinux() failed POST operation failed: (xend.err "Error creating domain: (12, 'Cannot allocate memory')") [thomas@srv1 ~]$ free total used free shared buffers cached Mem: 6154240 1312276 4841964 0 144660 600632 -/+ buffers/cache: 566984 5587256 Swap: 8323064 0 8323064 kind regards, Thomas

3 5

[Libvir] Extending libvirt to probe NUMA topology
by Ryan Harper 11 Sep '07

11 Sep '07

Hello all, I wanted to start a discussion on how we might get libvirt to be able to probe the NUMA topology of Xen and Linux (for QEMU/KVM). In Xen, I've recently posted patches for exporting topology into the [1]physinfo hypercall, as well adding a [2]hypercall to probe the Xen heap. I believe the topology and memory info is already available in Linux. With these, we have enough information to be able to write some simple policy above libvirt that can create guests in a NUMA-aware fashion. I'd like to suggest the following for discussion: (1) A function to discover topology (2) A function to check available memory (3) Specifying which cpus to use prior to domain start Thoughts? 1. http://lists.xensource.com/archives/html/xen-devel/2007-06/msg00298.html 2. http://lists.xensource.com/archives/html/xen-devel/2007-06/msg00299.html -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ryanh(a)us.ibm.com

5 13

Re: [Libvir] Extending libvirt to probe NUMA topology
by beth kon 11 Sep '07

11 Sep '07

Daniel, I'm taking a stab at this work and want to be sure I'm taking the right approach. I'm new to xen and even newer to libvirt, so have a bit of a learning curve. For the topology information, I assume that this will be a call through xend, similar to xenDaemonNodeGetInfo. It would seem natural to somehow extend the xenDaemonNodeGetInfo with this additional information except that you suggested having the output in XML. Can you explain why you chose XML? -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak(a)us.ibm.com

3 3

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

11 Sep '07

Thanks for the replays > If an individual stats field isn't supported by the hypervisor, it > will be returned as ((long long) -1) [for various reasons we're using > long long here, but really we mean 64 bit signed int]. Thats very useful info, I spent quite a lot of time messing with BigIntegers, because I didn't want to loose the top bit. By the way, there are quite a few unisgned ints, and unsigned longs in the API. Am I right to assume that "unsigned int" is 32 bits, so It will only fit into a java long, and "unsigned long" is 64 bits, so it won't fit safely in any java primitive variable? (Apart form the stats members, as you wrote above) > Interesting, so you're using JNI direct access to the C library, right ? > I looked at this a few weeks ago, but it was looking like accessing using the > remote access would have made the Java bindings more platform independant > but I had troubles with the RPC/TLS support, and didn't go very far. Maybe > a JNI based solution is good enough for most potential Java users. I thought about that too, but then I read the stern warnings about not using the private on-the-wire protocol, so I settled on JNI. I think getting all the crypto and protocol stuff right would be more work than the JNI version, anyway. Of course since most people won't want to run the JVM as root, having to use a network URI is almost required through JNI, too. Also, I have found an other possible problem in the API/documentation: The Enum virDomainRestart is defined, but it is not referenced anywhere. Is it the flag parameter to reboot? (I've made the mistake of signing up for the digest version of the mailing list, so I can't directly reply, but I hope I won't mess up the threading) regards István

2 1

[Libvir] [PATCH] docs spelling fixes
by Eduardo Habkost 10 Sep '07

10 Sep '07

Small spelling fixes on docs/format.html. --- libvirt/docs/format.html 16 Jul 2007 21:30:30 -0000 1.25 +++ libvirt/docs/format.html 6 Sep 2007 17:29:51 -0000 @@ -59,7 +59,7 @@ </ul>The format of the devices and their type may grow over time, but the following should be sufficient for basic use:A <code>disk</code> device indicates a block device, it can have two values for the type attribute either 'file' or 'block' corresponding to the 2 -options availble at the Xen layer. It has two mandatory children, and one +options available at the Xen layer. It has two mandatory children, and one optional one in no specific order:<ul><li>source with a file attribute containing the path in Domain 0 to the file or a dev attribute if using a block device, containing the device name ('hda5' or '/dev/hda5')</li> @@ -72,7 +72,7 @@ number of children in no specific order:<ul><li>source: indicating the bridge name</li> <li>mac: the optional mac address provided in the address attribute</li> <li>ip: the optional IP address provided in the address attribute</li> - <li>script: the script used to bridge the interfcae in the Domain 0</li> + <li>script: the script used to bridge the interface in the Domain 0</li> <li>target: and optional target indicating the device name.</li> </ul>A <code>console</code> element describes a serial console connection to the guest. It has no children, and a single attribute <code>tty</code> which @@ -237,11 +237,11 @@ <li>Virtual network Provides a virtual network using a bridge device in the host. Depending on the virtual network configuration, the network may be - totally isolated,NAT'ing to aan explicit network device, or NAT'ing to + totally isolated, NAT'ing to an explicit network device, or NAT'ing to the default route. DHCP and DNS are provided on the virtual network in all cases and the IP range can be determined by examining the virtual network config with '<code>virsh net-dumpxml <network - name></code>'. There is one virtual network called'default' setup out + name></code>'. There is one virtual network called 'default'' setup out of the box which does NAT'ing to the default route and has an IP range of <code>192.168.22.0/255.255.255.0</code>. Each guest will have an associated tun device created with a name of vnetN, which can also be @@ -311,7 +311,7 @@ </li> <li>TCP tunnel A TCP client/server architecture provides a virtual network. One VM - provides the server end of the netowrk, all other VMS are configured as + provides the server end of the network, all other VMS are configured as clients. All network traffic is routed between the VMs via the server. This mode is also available to unprivileged users. There is no default DNS or DHCP support and no outgoing network access. To provide outgoing @@ -411,7 +411,7 @@ </features> </guest> ... -</capabilities></pre>The fist block (in red) indicates the host hardware capbilities, currently +</capabilities></pre>The fist block (in red) indicates the host hardware capabilities, currently it is limited to the CPU properties but other information may be available, it shows the CPU architecture, and the features of the chip (the feature block is similar to what you will find in a Xen fully virtualized domain -- Eduardo

4 3

[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 07 Sep '07

07 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 07 Sep '07

07 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 07 Sep '07

07 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 07 Sep '07

07 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 07 Sep '07

07 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 06 Sep '07

06 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

[Libvir] [PATCH]OpenVZ Enhancements - Cleaned up
by Shuveb Hussain 03 Sep '07

03 Sep '07

Hi, Attached are the OpenVZ driver enhancements. Cleanups have been done according to Daniel .V's suggestions. Please see my previous mail for summary. Cheers, Shuveb Hussain http://www.binarykarma.com

2 2