- Devel - libvirt List Archives

[libvirt] Tunnelled migration
by Chris Lalancette 30 Sep '09

30 Sep '09

At long last, now that the stream stuff is committed to the tree, I can repost the tunnelled migration patches. Note that these patches will conflict in some places with danpb's previously posted "PEER2PEER" patches, but it should be easy to resolve the differences.

2 15

[libvirt] Fix apibuild.py warnings
by Matthias Bolte 30 Sep '09

30 Sep '09

apibuild.py warns about misformatted function comment for virStreamEventAddCallback, virStreamEventUpdateCallback and virStreamEventRemoveCallback. The attached patch adds the missing ':' and contains the resulting changes in docs/libvirt-api.xml and docs/libvirt-refs.xml Matthias

3 2

[libvirt] [PATCH] minor fix's
by Pritesh Kothari 30 Sep '09

30 Sep '09

Hi All, Just minor fix's. Regards, Pritesh

3 2

[libvirt] [PATCH 0/7] Add support for qcow2 backing files to sVirt
by Mark McLoughlin 30 Sep '09

30 Sep '09

Hey, https://bugzilla.redhat.com/497131 shows that sVirt cannot currently handle qcow2 files with a backing store. Because we do not re-label the backing store, qemu cannot read it. The fix is fairly straightforward - when we go to re-label a file, check its header and if it has a backing store, re-label that too. Most of this series involves moving the header probing code from the storage driver into libvirt_util so that the security driver can use it. Cheers, Mark.

3 28

[libvirt] Fix memleaks in libvirtd's message processing
by Matthias Bolte 30 Sep '09

30 Sep '09

I tracked down a memleak in libvirtd's message processing. The leak was introduced in commit 47cab734995fa9521b1df05d37e9978eedd8d3a2 "Split out code for handling incoming method call messages". This commit changed the way qemud_client_message objects were reused. Before this commit: - qemudWorker() removes a message from dispatch queue and passes it to remoteDispatchClientRequest() - remoteDispatchClientRequest() handles the message and reuses the same message for the response. If an error occurs the same message is used to report it (rpc_error label). If another error occurs while trying to report the first error remoteDispatchClientRequest() would return -1 and the message will be freed in qemudWorker() After this commit: - qemudWorker() removes a message from dispatch queue and passes it to remoteDispatchClientRequest() - remoteDispatchClientRequest() calls remoteDispatchClientCall() if the message it is an remote call or otherwise respond with a new error message by calling remoteSerializeReplyError() and the original message leaks - remoteDispatchClientCall() handles the message and reuses the same message for the response. If an error occurs it calls remoteSerializeReplyError() and the original message leaks. If a fatal error occurs remoteDispatchClientCall() returns -1 and the original message will be freed in qemudWorker() To fix this leak the original message has to be freed if remoteSerializeReplyError() succeeds. If remoteSerializeReplyError() fails the original message will be freed in qemudWorker(). In addition I came across another leak in remoteSerializeError(). If an error occurs while serializing the initial error the message leaks. To fix this leak the message has to be freed in case of an XDR error. Matthias

2 2

[libvirt] virtio network problems with kvm guests with 2.6.26 kernel
by Jim Paris 29 Sep '09

29 Sep '09

Hi, After upgrading libvirt on one system, my kvm guests running a 2.6.26 kernel with virtio networking could no longer communicate with the network. It seems that the problem is caused by newer libvirt versions unconditionally enabling GSO support by setting IFF_VNET_HDR [1]. However, support for this feature is apparently broken in 2.6.26. Ubuntu seems to have also discovered this problem [2] and they currently work around it by removing GSO support from kvm [3]. Currently, I'm running with a patched libvirt that never sets IFF_VNET_HDR, and it's working fine once again. While this is not a libvirt problem per se, it certainly violated the principle of least surprise given that libvirt was the only thing that changed! But I don't know if there's much that libvirt can do to avoid this problem, as it's really something that needs to get fixed in kvm, or the guest needs to be upgraded, or switched away from virtio. At the very least, maybe this info helps someone else who runs across the same problem. -jim [1] http://www.redhat.com/archives/libvir-list/2009-January/msg00642.html [2] https://bugs.launchpad.net/kvm/+bug/331128 [3] http://patches.ubuntu.com/k/kvm/extracted/virtio-net_disable_gso.patch

3 4

[libvirt] [PATCH] Minor comment changes.
by Laine Stump 29 Sep '09

29 Sep '09

Fix some minor grammer (and one other) nits in comments that end up in generated API reference documentation. No functional/binary differences. --- src/libvirt.c | 24 ++++++++++++------------ 1 files changed, 12 insertions(+), 12 deletions(-) diff --git a/src/libvirt.c b/src/libvirt.c index ca8e003..ce3d6ba 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -592,9 +592,9 @@ virRegisterNetworkDriver(virNetworkDriverPtr driver) /** * virRegisterInterfaceDriver: - * @driver: pointer to a interface driver block + * @driver: pointer to an interface driver block * - * Register a interface virtualization driver + * Register an interface virtualization driver * * Returns the driver priority or -1 in case of error. */ @@ -5365,7 +5365,7 @@ error: /** * virNetworkGetXMLDesc: * @network: a network object - * @flags: and OR'ed set of extraction flags, not used yet + * @flags: an OR'ed set of extraction flags, not used yet * * Provide an XML description of the network. The description may be reused * later to relaunch the network with virNetworkCreateXML(). @@ -5545,7 +5545,7 @@ error: /** * virInterfaceGetConnect: - * @iface: pointer to a interface + * @iface: pointer to an interface * * Provides the connection pointer associated with an interface. The * reference counter on the connection is not increased by this @@ -5819,7 +5819,7 @@ error: /** * virInterfaceGetName: - * @iface: a interface object + * @iface: an interface object * * Get the public name for that interface * @@ -5842,9 +5842,9 @@ virInterfaceGetName(virInterfacePtr iface) /** * virInterfaceGetMACString: - * @iface: a interface object + * @iface: an interface object * - * Get the MAC for a interface as string. For more information about + * Get the MAC for an interface as string. For more information about * MAC see RFC4122. * * Returns a pointer to the MAC address (in null-terminated ASCII @@ -5867,11 +5867,11 @@ virInterfaceGetMACString(virInterfacePtr iface) /** * virInterfaceGetXMLDesc: - * @iface: a interface object - * @flags: and OR'ed set of extraction flags, not used yet + * @iface: an interface object + * @flags: an OR'ed set of extraction flags, not used yet * * Provide an XML description of the interface. The description may be reused - * later to recreate the interface with virInterfaceCreateXML(). + * later to redefine the interface with virInterfaceDefineXML(). * * Returns a 0 terminated UTF-8 encoded XML instance, or NULL in case of error. * the caller must free() the returned value. @@ -6100,7 +6100,7 @@ error: * This method is typically useful for applications where multiple * threads are using a connection, and it is required that the * connection remain open until all threads have finished using - * it. ie, each new thread using a interface would increment + * it. ie, each new thread using an interface would increment * the reference count. * * Returns 0 in case of success, -1 in case of failure. @@ -6121,7 +6121,7 @@ virInterfaceRef(virInterfacePtr iface) /** * virInterfaceFree: - * @iface: a interface object + * @iface: an interface object * * Free the interface object. The interface itself is unaltered. * The data structure is freed and should not be used thereafter. -- 1.6.2.5

1 1

[libvirt] [PATCH] bug in vboxDomainDestroy in vbox driver
by Pritesh Kothari 29 Sep '09

29 Sep '09

Hi All, There is bug in vboxDomainDestroy() where in the while powerdown the method doesn't wait till its completion. Fix in the attached patch. Regards, Pritesh

2 1

[libvirt] Libvirtd on Non Linux?
by Yushu Yao 29 Sep '09

29 Sep '09

Hi Experts, Just wondering is it possible now to run libvirt deamon on non-linux platforms (mainly windows and mac)? If yes, are there instructions on how to build it. If no, what was the roadblock? I'm trying to find a tool that can control the VMM for desktop/laptop users under win/mac/linux. Mainly for automation of deployment of some appliances. The best tool I've heard is libvirt, but couldn't find any doc on using it for other platforms. Any help is greatly appreciated. -Yushu

2 1

[libvirt] [PATCH] in Vbox driver, OpenHardDisk is called with NULL instead of ""
by Florian Vichot 29 Sep '09

29 Sep '09

This patch replaces the use of NULL with empty strings ("") in a call to OpenHardDisk, which otherwise fails with E_INVALIDARG. Florian

3 2