- Devel - libvirt List Archives

[libvirt] [PATCH] Fix delayed event delivery when SASL is active
by Daniel P. Berrange 17 Mar '11

17 Mar '11

When SASL is active, it was possible that we read and decoded more data off the wire than we initially wanted. The loop processing this data terminated after only one message to avoid delaying the calling thread, but this could delay event delivery. As long as there is decoded SASL data in memory, we must process it, before returning to the poll() event loop. This is a counterpart to the same kind of issue solved in commit 68d2c3482fa16801f8e6ca5c42698319bb87f385 in a different area of the code * src/remote/remote_driver.c: Process all pending SASL data --- src/remote/remote_driver.c | 25 ++++++++++++++++++++----- 1 files changed, 20 insertions(+), 5 deletions(-) diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index 064fc8b..4245fee 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -10426,12 +10426,27 @@ remoteIOHandleInput(virConnectPtr conn, struct private_data *priv, ret = processCallDispatch(conn, priv, flags); priv->bufferOffset = priv->bufferLength = 0; /* - * We've completed one call, so return even - * though there might still be more data on - * the wire. We need to actually let the caller - * deal with this arrived message to keep good - * response, and also to correctly handle EOF. + * We've completed one call, but we don't want to + * spin around the loop forever if there are many + * incoming async events, or replies for other + * thread's RPC calls. We want to get out & let + * any other thread take over as soon as we've + * got our reply. When SASL is active though, we + * may have read more data off the wire than we + * initially wanted & cached it in memory. In this + * case, poll() would not detect that there is more + * ready todo. + * + * So if SASL is active *and* some SASL data is + * already cached, then we'll process that now, + * before returning. */ +#if HAVE_SASL + if (ret == 0 && + priv->saslconn && + priv->saslDecoded) + continue; +#endif return ret; } } -- 1.7.4

2 1

[libvirt] [PATCH] remote: Add missing virCondDestroy calls
by Matthias Bolte 17 Mar '11

17 Mar '11

The virCond of the remote_thread_call struct was leaked in some places. This results in leaking the underlying mutex. Which in turn leaks a handle on Windows. Reported by Aliaksandr Chabatar and Ihar Smertsin. --- See https://www.redhat.com/archives/libvir-list/2011-March/msg00789.html for the report. src/remote/remote_driver.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index 82e094b..8aa8801 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -8609,6 +8609,7 @@ remoteStreamPacket(virStreamPtr st, xdr_destroy (&xdr); ret = remoteIO(st->conn, priv, 0, thiscall); + ignore_value(virCondDestroy(&thiscall->cond)); VIR_FREE(thiscall); if (ret < 0) return -1; @@ -8617,6 +8618,7 @@ remoteStreamPacket(virStreamPtr st, error: xdr_destroy (&xdr); + ignore_value(virCondDestroy(&thiscall->cond)); VIR_FREE(thiscall); return -1; } @@ -8746,6 +8748,7 @@ remoteStreamRecv(virStreamPtr st, } ret = remoteIO(st->conn, priv, 0, thiscall); + ignore_value(virCondDestroy(&thiscall->cond)); VIR_FREE(thiscall); if (ret < 0) goto cleanup; @@ -9719,6 +9722,7 @@ prepareCall(struct private_data *priv, error: xdr_destroy (&xdr); + ignore_value(virCondDestroy(&rv->cond)); VIR_FREE(rv); return NULL; } @@ -10818,6 +10822,7 @@ call (virConnectPtr conn, struct private_data *priv, } rv = remoteIO(conn, priv, flags, thiscall); + ignore_value(virCondDestroy(&thiscall->cond)); VIR_FREE(thiscall); return rv; } -- 1.7.0.4

3 3

[libvirt] FW: Using dlls for Windows provided in http://libvirt.org/sources/win32_experimental/Libvirt-0.8.7-2.exe
by Aliaksandr Chabatar 17 Mar '11

17 Mar '11

Hello libvirt-list, We have a problem. It concerns CPU usage of libvirt library in Windows. It's not a problem in Linux. See attach. At the moment we have a workaround for item 1 - we just calculate the number of handles which are leaked and restart our service if the number exceeds 10.000 As for item 2 - we have no real workaround. In 99.99% it should not happen, but there is still 0.01% In libvirt.log you can find more info as suggested by Daniel. ================================================================ In the attached file, you will find detailed information regarding the case 100 percent CPU usage. Our test was performed on the following system: Windows XP SP3; Libvirt-0.8.8; Run the following command: virsh -c qemu+tcp: / /172.17.46.88:135/system Port 135 was one of the ports on which our service is trying to connect. ================================================================ Could you help us here? Thanks Alexander -----Original Message----- From: Aliaksandr Chabatar Sent: Tuesday, March 15, 2011 3:52 PM To: Ihar Smertsin Subject: FW: [libvirt] Using dlls for Windows provided in http://libvirt.org/sources/win32_experimental/Libvirt-0.8.7-2.exe Hi Ihar, Could you provide more information (log files, see below) so we could address this issue to libvir-list(a)redhat.com ? Mfg Alexander -----Original Message----- From: Daniel P. Berrange [mailto:berrange@redhat.com] Sent: Tuesday, March 15, 2011 3:08 PM To: Aliaksandr Chabatar Cc: Hempfer, Siegfried; Boehme, Alfred; Schnizer, Monika Subject: Re: [libvirt] Using dlls for Windows provided in http://libvirt.org/sources/win32_experimental/Libvirt-0.8.7-2.exe On Tue, Mar 15, 2011 at 04:01:31PM +0200, Aliaksandr Chabatar wrote: > Dear Daniel, > > I have another question. It concerns CPU usage of libvirt library > in Windows. It's not a problem in Linux. See attach. > > At the moment we have a workaround for item 1 - we just calculate > the number of handles which are leaked and restart our service if > the number exceeds 10.000 It sounds like we have some crazy resource leak in a piece of code. I'm not too familiar with Windows, but if you re-send this mail of yours to libvir-list(a)redhat.com, I expect one of the community members who knows Windows will be able to advise. > As for item 2 - we have no real workaround. In 99.99% it should > not happen, but there is still 0.01% Yeah, that sounds like some piece of code is missing correct error checking. It would be useful to try and obtain a couple of stack traces when it is showing 100% cpu usage. Or capture a libvirt debug log, eg by setting an environment variable in your client application LIBVIRT_LOG_FILTERS="1:libvirt 1:util 1:remote" LIBVIRT_LOG_OUTPUTS="1:file:libvirt.log" Again, sending this log + the info from your mail to the libvir-list would be best. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

2 2

[libvirt] [PATCH] docs: Document first release with spice and qxl
by Cole Robinson 17 Mar '11

17 Mar '11

--- docs/formatdomain.html.in | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 0c7c965..0835472 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -1566,6 +1566,7 @@ qemu-kvm -net nic,model=? /dev/null to use. It is possible to set a limit on the validity of the password be giving an timestamp <code>passwdValidTo='2010-04-09T15:51:00'</code> assumed to be in UTC. NB, this may not be supported by all hypervisors. + "spice" since 0.8.6. When SPICE has both a normal and TLS secured TCP port configured, it @@ -1632,8 +1633,9 @@ qemu-kvm -net nic,model=? /dev/null <dt><code>model</code></dt> <dd> The <code>model</code> element has a mandatory <code>type</code> - attribute which takes the value "vga", "cirrus", "vmvga", "qxl", - "xen" or "vbox", depending on the hypervisor features available. + attribute which takes the value "vga", "cirrus", "vmvga", "xen", + "vbox", or "qxl" (since 0.8.6) + depending on the hypervisor features available. You can also provide the amount of video memory in kilobytes using <code>vram</code> and the number of screen with <code>heads</code>. </dd> -- 1.7.4

2 1

[libvirt] [PATCH] qemu: Fix copy&paste error messages in text monitor
by Jiri Denemark 17 Mar '11

17 Mar '11

--- src/qemu/qemu_monitor_text.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_monitor_text.c b/src/qemu/qemu_monitor_text.c index 5df7933..91ecc8b 100644 --- a/src/qemu/qemu_monitor_text.c +++ b/src/qemu/qemu_monitor_text.c @@ -2055,7 +2055,7 @@ try_command: if (qemuMonitorHMPCommand(mon, cmd, &reply) < 0) { qemuReportError(VIR_ERR_OPERATION_FAILED, - _("failed to close fd in qemu with '%s'"), cmd); + _("failed to attach drive '%s'"), drivestr); goto cleanup; } @@ -2324,7 +2324,7 @@ int qemuMonitorTextAddDrive(qemuMonitorPtr mon, if (qemuMonitorHMPCommand(mon, cmd, &reply) < 0) { qemuReportError(VIR_ERR_OPERATION_FAILED, - _("failed to close fd in qemu with '%s'"), cmd); + _("failed to add drive '%s'"), drivestr); goto cleanup; } @@ -2425,8 +2425,8 @@ int qemuMonitorTextSetDrivePassphrase(qemuMonitorPtr mon, } if (qemuMonitorHMPCommand(mon, cmd, &reply) < 0) { - qemuReportError(VIR_ERR_OPERATION_FAILED, - _("failed to close fd in qemu with '%s'"), cmd); + qemuReportError(VIR_ERR_OPERATION_FAILED, "%s", + _("failed to set disk password")); goto cleanup; } -- 1.7.4.1

2 1

[libvirt] [PATCH] do not return -1 when human-monitor-command is not supported
by Wen Congyang 17 Mar '11

17 Mar '11

It is not a fatal error if some monitor command is not supported. So we should not return -1 when human-monitor-command is not supported. Set reply_str to "unknown command: 'human-monitor-command'", and the caller can deal this error the same as the command that we want to run by human-monitor-command. Signed-off-by: Wen Congyang <wency(a)cn.fujitsu.com> --- src/qemu/qemu_monitor_json.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index 13d12c8..7ec4ce7 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -694,6 +694,16 @@ qemuMonitorJSONHumanCommandWithFd(qemuMonitorPtr mon, if (!cmd || qemuMonitorJSONCommandWithFd(mon, cmd, scm_fd, &reply) < 0) goto cleanup; + if (qemuMonitorJSONHasError(reply, "CommandNotFound")) { + *reply_str = strdup("unknown command: 'human-monitor-command'"); + if (!*reply_str) { + virReportOOMError(); + goto cleanup; + } + ret = 0; + goto cleanup; + } + if (qemuMonitorJSONCheckError(cmd, reply)) goto cleanup; -- 1.7.1

2 1

[libvirt] [PATCH] spec: Guess rhel/fedora macros from dist
by Jiri Denemark 17 Mar '11

17 Mar '11

--- If anyone knows how to make rpm to evaluate %(...) immediately and not at every appearance of rhel/fedora, that would be really cool. libvirt.spec.in | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 02be928..bfc9206 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1,5 +1,11 @@ # -*- rpm-spec -*- +# if neither fedora nor rhel was defined, try to guess them from %{dist} +%if !0%{?rhel} && !0%{?fedora} +%define rhel %(echo "%{?dist}" | sed -ne 's/^\\.el\\([0-9]\\+\\).*/\\1/p') +%define fedora %(echo "%{?dist}" | sed -ne 's/^\\.fc\\?\\([0-9]\\+\\).*/\\1/p') +%endif + # A client only build will create a libvirt.so only containing # the generic RPC driver, and test driver and no libvirtd # Default to a full server + client build -- 1.7.4.1

3 10

[libvirt] /sys/devices/system/cpu/cpu0/topology/physical_package_id: No such file or directory (was: Re: Need help with virt_install)
by Richard W.M. Jones 17 Mar '11

17 Mar '11

On Wed, Mar 16, 2011 at 12:12:24PM -0700, JD wrote: > /virt-install \ > --connect qemu:///system \ > --name Fedora_14_i386 \ > --ram 500 \ > --disk path=/dev/sdc \ > --network network:default \ > --arch i386 \ > --os-variant fedora14 \ > --vnc \ > --location > http://mirrors.kernel.org/fedora/releases/14/Fedora/i386/os/ > > Starting install.../ / > Retrieving file .treeinfo... | 2.4 kB > 00:00 ... > Retrieving file vmlinuz... | 7.1 MB > 00:05 ... > Retrieving file initrd.img... | 60 MB > 00:45 ... > ERROR internal error Process exited while reading console log output: > libvir: error : cannot open > /sys/devices/system/cpu/cpu0/topology/physical_package_id: No such file > or directory > > Domain installation does not appear to have been > successful. If it was, you can restart your domain > by running 'virsh start Fedora_14_i386'; otherwise, please > restart your installation./ > > > is the missing /sys/devices/system/cpu/cpu0/topology/physical_package_id > caused by kernel configuration settings? > > > The relevant installed packages are: > > libguestfs-tools-1.6.2-1.fc13.4.i686 > python-virtinst-0.500.4-1.fc13.noarch > python-virtinst-0.500.4-1.fc13.noarch > virt-ctrl-1.0.1-4.fc12.i686 > libguestfs-tools-1.6.2-1.fc13.4.i686 > virt-mem-0.3.1-9.fc12.i686 > libguestfs-tools-1.6.2-1.fc13.4.i686 > virt-mem-0.3.1-9.fc12.i686 > python-virtinst-0.500.4-1.fc13.noarch > libguestfs-tools-1.6.2-1.fc13.4.i686 > python-virtinst-0.500.4-1.fc13.noarch > libguestfs-tools-1.6.2-1.fc13.4.i686 > libguestfs-tools-1.6.2-1.fc13.4.i686 > libguestfs-tools-1.6.2-1.fc13.4.i686 > libguestfs-tools-1.6.2-1.fc13.4.i686 > virt-manager-0.8.5-1.fc13.noarch > virt-mem-0.3.1-9.fc12.i686 > libvirt-client-0.8.2-2.fc13.i686 > virt-mem-0.3.1-9.fc12.i686 > libguestfs-tools-1.6.2-1.fc13.4.i686 > libguestfs-tools-1.6.2-1.fc13.4.i686 > libguestfs-tools-1.6.2-1.fc13.4.i686 > virt-top-1.0.4-3.fc13.i686 > virt-mem-0.3.1-9.fc12.i686 > virt-viewer-0.2.1-1.fc13.i686 > libguestfs-tools-1.6.2-1.fc13.4.i686 > libvirt-client-0.8.2-2.fc13.i686 (CCing libvir-list) I would say that this is a bug in libvirt. Since you are using quite an old version, can you try upgrading to the new libvirt in Fedora 14/15 and see if that fixes it? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top

1 0

Re: [libvirt] [Qemu-devel] KVM call minutes for Mar 15
by Chris Wright 17 Mar '11

17 Mar '11

* Anthony Liguori (anthony(a)codemonkey.ws) wrote: > On 03/15/2011 09:53 AM, Chris Wright wrote: > > QAPI <snip> > >- c library implementation is critical to have unit tests and test > > driven development > > - thread safe? > > - no shared state, no statics. > > - threading model requires lock for the qmp session > > - licensiing? > > - LGPL > > - forwards/backwards compat? > > - designed with that in mind see wiki: > > > > http://wiki.qemu.org/Features/QAPI > > One neat feature of libqmp is that once libvirt has a better QMP > passthrough interface, we can create a QmpSession that uses libvirt. > > It would look something like: > > QmpSession *libqmp_session_new_libvirt(virDomainPtr dom); Looks like you mean this? -> request QmpSession -> client libvirt <- return QmpSession <- client -> QmpSession -> QMP -> QEMU So bypassing libvirt completely to actually use the session? Currently, it's more like: client -> QemuMonitorCommand -> libvirt -> QMP -> QEMU > The QmpSession returned by this call can then be used with all of > the libqmp interfaces. This means we can still exercise our test > suite with a guest launched through libvirt. It also should make > the libvirt pass through interface a bit easier to consume by third > parties. This sounds like it's something libvirt folks should be involved with. At the very least, this mode is there now and considered basically unstable/experimental/developer use: "Qemu monitor command '%s' executed; libvirt results may be unpredictable!" So likely some concern about making it easier to use, esp. assuming that third parties above are mgmt apps, not just developers. thanks, -chris

3 2

[libvirt] Network Interface: How to disable virbr0 correctly?
by Jake Xu 17 Mar '11

17 Mar '11

Hi all, Recently, I have been using libvirt to create virtual machines on ESX servers. It has been very well until to the point where I couldn't find any way to disable/remove the virbr0 interface properly. We use static configuration for VMs on ESX so we do not need to use virbr0 interface and we do not want libvirt to configure iptables as a result of the newly created virbr0 interface. I have tried to remove/rename the /etc/libvirt/qemu/networks/autostart.xml file, and that prevents virbr0 being installed. However, that also seems to prevent the second interface eth1 being configured properly. After libvirt defines a VM, eth0 and eht1 are both installed, but only eth0 is configured properly. The eth1 does not appear in the /etc/sysconfig/network-script/ifcfg-xxx file. It seems to me that the 'autostart.xml' file interrupts the configuration of the eth1 interface. Can anyone please advise how I can do this properly? Thanks a lot, Jake

3 6