- Devel - libvirt List Archives

[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