- Devel - libvirt List Archives

Re: [libvirt] pci-stub error and MSI-X for KVM guest
by Chris Wright 08 Jan '10

08 Jan '10

* Fischer, Anna (anna.fischer(a)hp.com) wrote: > So, when setting a breakpoint for the exit() call I'm getting a bit closer to figuring where it kills my guest. Thanks, this helps clarify what is happening. > Breakpoint 1, exit (status=1) at exit.c:99 > 99 { > Current language: auto > The current source language is "auto; currently c". > (gdb) bt > #0 exit (status=1) at exit.c:99 > #1 0x0000000000470c6e in assigned_dev_pci_read_config (d=0x259c6f0, address=64, len=4) assigned_dev_pci_read_config(..., 64, 4) ^^ This is a libvirt issue. When you use virt-manager it has libvirtd fork/exec qemu-kvm. libvirtd will drop privileges and run qemu-kvm as user qemu (or perhaps root if you've edited qemu.conf). Regardless of the user, it clears capabilities. Reading PCI config space beyond just the header requires CAP_SYS_ADMIN. The above is reading the first 4 bytes of device dependent config space, and the kernel is returning 0 because qemu doesn't have CAP_SYS_ADMIN. Basically, this means that device assignment w/ libvirt will break MSI/MSI-X because qemu will never be able to see that the host device has those PCI capabilities. This, in turn, renders VF device assignment useless (since a VF is required to support MSI and/or MSI-X). Granting CAP_SYS_ADMIN for each qemu instance that does device assignment would render the privilege reduction useless (CAP_SYS_ADMIN is the kitchen sink catchall of the Linux capability system). Hmmph...

2 2

[libvirt] [PATCH] esx: Dump the raw response in case of an SOAP fault
by Matthias Bolte 08 Jan '10

08 Jan '10

Currently only the faultcode and faultstring are deserialized, the detail part is ignored. The implementation of many new SOAP types would be necessary to deserialize the detail part correctly. As an intermediate solution the raw response is dumped to the debug log. --- src/esx/esx_vi.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/esx/esx_vi.c b/src/esx/esx_vi.c index bad987c..9cade3d 100644 --- a/src/esx/esx_vi.c +++ b/src/esx/esx_vi.c @@ -692,6 +692,12 @@ esxVI_Context_Execute(virConnectPtr conn, esxVI_Context *ctx, "HTTP response code %d for call to '%s'. " "Fault: %s - %s", (*response)->responseCode, methodName, fault->faultcode, fault->faultstring); + + /* FIXME: Dump raw response until detail part gets deserialized */ + VIR_DEBUG("HTTP response code %d for call to '%s' [[[[%s]]]]", + (*response)->responseCode, methodName, + (*response)->content); + goto failure; } else { if (virAsprintf(&xpathExpression, -- 1.6.0.4

2 1

[libvirt] [PATCH] Replace old CVS references with GIT
by Matthias Bolte 08 Jan '10

08 Jan '10

--- HACKING | 6 +++--- docs/FAQ.html.in | 2 +- docs/bugs.html.in | 6 +++--- docs/contact.html.in | 4 ++-- docs/deployment.html.in | 4 ++-- docs/hacking.html.in | 6 +++--- src/Makefile.am | 2 +- 7 files changed, 15 insertions(+), 15 deletions(-) diff --git a/HACKING b/HACKING index 3fb1113..0c65dad 100644 --- a/HACKING +++ b/HACKING @@ -15,14 +15,14 @@ should work: or: - cvs diff -up > libvirt-myfeature.patch + git diff > libvirt-myfeature.patch (3) Split large changes into a series of smaller patches, self-contained if possible, with an explanation of each patch and an explanation of how the sequence of patches fits together. -(4) Make sure your patches apply against libvirt CVS. Developers -only follow CVS and don't care much about released versions. +(4) Make sure your patches apply against libvirt GIT. Developers +only follow GIT and don't care much about released versions. (5) Run the automated tests on your code before submitting any changes. In particular, configure with compile warnings set to -Werror: diff --git a/docs/FAQ.html.in b/docs/FAQ.html.in index a436e78..50f798d 100644 --- a/docs/FAQ.html.in +++ b/docs/FAQ.html.in @@ -119,7 +119,7 @@ packages as well as the public headers to compile against libxenstore.</p> </li> <li> - <em>I use the CVS version and there is no configure script</em> + <em>I use the GIT version and there is no configure script</em> <p>The configure script (and other Makefiles) are generated. Use the autogen.sh script to regenerate the configure script and Makefiles, like:</p> diff --git a/docs/bugs.html.in b/docs/bugs.html.in index 380bcff..fa557a8 100644 --- a/docs/bugs.html.in +++ b/docs/bugs.html.in @@ -16,7 +16,7 @@ <p> If you are using official libvirt binaries from a Linux distribution check below for distribution specific bug reporting policies first. - For general libvirt bug reports, from self-built releases, CVS snapshots + For general libvirt bug reports, from self-built releases, GIT snapshots and any other non-distribution supported builds, enter tickets under the <code>Virtualization Tools</code> product and the <code>libvirt</code> component. @@ -64,8 +64,8 @@ </p> <ul> - <li>The version number of the libvirt build, or date of the CVS - checkout</li> + <li>The version number of the libvirt build, or SHA1 of the GIT + commit</li> <li>The hardware architecture being used</li> <li>The name of the hypervisor (Xen, QEMU, KVM)</li> <li>The XML config of the guest domain if relevant</li> diff --git a/docs/contact.html.in b/docs/contact.html.in index 4b9f532..5d055b1 100644 --- a/docs/contact.html.in +++ b/docs/contact.html.in @@ -12,8 +12,8 @@ <a href="https://www.redhat.com/mailman/listinfo/libvir-list">associated Web</a> page and follow the instructions. Patches with explanations and provided as attachments are really appreciated and will be discussed on the mailing list. - If possible generate the patches by using <code>cvs diff -up</code> in a CVS - checkout. + If possible generate the patches by using <code>git diff</code> in a GIT + clone. </p> <h2>IRC discussion</h2> diff --git a/docs/deployment.html.in b/docs/deployment.html.in index 47c4892..94c480f 100644 --- a/docs/deployment.html.in +++ b/docs/deployment.html.in @@ -25,10 +25,10 @@ # make install </pre> - <h2>Built from CVS / GIT</h2> + <h2>Built from GIT</h2> <p> - When building from CVS it is necessary to generate the autotools + When building from GIT it is necessary to generate the autotools support files. This requires having <code>autoconf</code>, <code>automake</code>, <code>libtool</code> and <code>intltool</code> installed. The process can be automated with the <code>autogen.sh</code> diff --git a/docs/hacking.html.in b/docs/hacking.html.in index af63411..43a79f7 100644 --- a/docs/hacking.html.in +++ b/docs/hacking.html.in @@ -19,13 +19,13 @@ or: </p> <pre> - cvs diff -up > libvirt-myfeature.patch + git diff > libvirt-myfeature.patch </pre></li> <li>Split large changes into a series of smaller patches, self-contained if possible, with an explanation of each patch and an explanation of how the sequence of patches fits together.</li> - <li>Make sure your patches apply against libvirt CVS. Developers - only follow CVS and don't care much about released versions.</li> + <li>Make sure your patches apply against libvirt GIT. Developers + only follow GIT and don't care much about released versions.</li> <li><p>Run the automated tests on your code before submitting any changes. In particular, configure with compile warnings set to -Werror:</p> <pre> diff --git a/src/Makefile.am b/src/Makefile.am index 8ef0e81..dbf708b 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -367,7 +367,7 @@ if HAVE_RPCGEN # Maintainer-only target for re-generating the derived .c/.h source # files, which are actually derived from the .x file. # -# For committing protocol changes to CVS, the GLIBC rpcgen *must* +# For committing protocol changes to GIT, the GLIBC rpcgen *must* # be used. # # Support for non-GLIB rpcgen is here as a convenience for -- 1.6.0.4

2 2

[libvirt] [PATCH] don't test "res == NULL" after we've already dereferenced it
by Jim Meyering 08 Jan '10

08 Jan '10

As the log says, once we've dereferenced it, there's no point in comparing to NULL. >From 463eaf1027a154e71839a67eca85b3ada8b817ff Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Wed, 6 Jan 2010 12:45:07 +0100 Subject: [PATCH] don't test "res == NULL" after we've already dereferenced it * src/xen/proxy_internal.c (xenProxyCommand): It is known to be non-NULL at that point, so remove the "ret == NULL" guard, and instead add an assert(ret != NULL), in case future code changes cause the condition to becomes false. Include <assert.h>. --- src/xen/proxy_internal.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/src/xen/proxy_internal.c b/src/xen/proxy_internal.c index ec4522b..42b6e91 100644 --- a/src/xen/proxy_internal.c +++ b/src/xen/proxy_internal.c @@ -1,7 +1,7 @@ /* * proxy_client.c: client side of the communication with the libvirt proxy. * - * Copyright (C) 2006, 2008, 2009 Red Hat, Inc. + * Copyright (C) 2006, 2008, 2009, 2010 Red Hat, Inc. * * See COPYING.LIB for the License of this software * @@ -11,6 +11,7 @@ #include <config.h> #include <stdio.h> +#include <assert.h> #include <stdlib.h> #include <unistd.h> #include <errno.h> @@ -444,7 +445,8 @@ retry: /* * do more checks on the incoming packet. */ - if ((res == NULL) || (res->version != PROXY_PROTO_VERSION) || + assert (res != NULL); + if ((res->version != PROXY_PROTO_VERSION) || (res->len < sizeof(virProxyPacket))) { virProxyError(conn, VIR_ERR_INTERNAL_ERROR, "%s", _("Communication error with proxy: malformed packet\n")); -- 1.6.6.387.g2649b1

3 9

[libvirt] [PATCH] let "configure --disable-shared" work once again
by Jim Meyering 08 Jan '10

08 Jan '10

Per this thread: http://thread.gmane.org/gmane.comp.emulators.libvirt/19672 here's a patch that solves both problems: >From 1b330b3070f904dfc1c380151afa3aaf2a121cd3 Mon Sep 17 00:00:00 2001 From: Jim Meyering <jim(a)meyering.net> Date: Thu, 7 Jan 2010 21:07:42 +0100 Subject: [PATCH] let "configure --disable-shared" work once again Without this change, ./autogen.sh --disable-shared && make would evoke a "can not build a shared library" failure for libvirtmod.la. However, without the -shared link option in python/Makefile.am, it was possible to install non-functional python support. Instead, make --disable-shared also disable building python. * configure.ac: Make --disable-shared imply --without-python and silently override --with-python. * python/Makefile.am (libvirtmod_la_LDFLAGS): Do not use -shared. This reverts 8838ee39ab1c2bb7fffe93bfda220692664e8be6. --- configure.in | 4 ++++ python/Makefile.am | 2 +- 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/configure.in b/configure.in index 3f2f8ff..3e98035 100644 --- a/configure.in +++ b/configure.in @@ -1813,6 +1813,10 @@ AC_ARG_WITH([qemu-group], AC_DEFINE_UNQUOTED([QEMU_USER], ["$QEMU_USER"], [QEMU user account]) AC_DEFINE_UNQUOTED([QEMU_GROUP], ["$QEMU_GROUP"], [QEMU group account]) +if test "$enable_shared:$with_python" = no:yes; then + AC_MSG_WARN([you've used --disable-shared; so disabling python support]) + with_python=no +fi # Only COPYING.LIB is under version control, yet COPYING # is included as part of the distribution tarball. diff --git a/python/Makefile.am b/python/Makefile.am index 58c6729..04342b7 100644 --- a/python/Makefile.am +++ b/python/Makefile.am @@ -39,7 +39,7 @@ libvirtmod_la_SOURCES = libvirt-override.c typewrappers.c libvirt.c libvirt.h # need extra flags here libvirtmod_la_CFLAGS = @WARN_PYTHON_CFLAGS@ -libvirtmod_la_LDFLAGS = -module -avoid-version -shared -L$(top_builddir)/src/.libs \ +libvirtmod_la_LDFLAGS = -module -avoid-version -L$(top_builddir)/src/.libs \ @CYGWIN_EXTRA_LDFLAGS@ libvirtmod_la_LIBADD = $(mylibs) \ @CYGWIN_EXTRA_LIBADD@ @CYGWIN_EXTRA_PYTHON_LIBADD@ -- 1.6.6.425.g4dc2d

3 9

[libvirt] [PATCH] Disallow building Python bindings if shared libraries are disabled.
by Diego Elio Pettenò 08 Jan '10

08 Jan '10

Patch concept by Jim Meyering <jim(a)meyering.net>, moved before the Python testing, and changed the message a bit to explain the problem. --- configure.in | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/configure.in b/configure.in index 3f2f8ff..5275412 100644 --- a/configure.in +++ b/configure.in @@ -1466,6 +1466,11 @@ dnl AC_ARG_WITH([python], [ --with-python Build python bindings (on)],[],[with_python=yes]) +if test "$enable_shared:$with_python" = no:yes; then + AC_MSG_WARN([Disabling shared libraries is incompatible with building Python extensions.]) + with_python=no +fi + PYTHON_VERSION= PYTHON_INCLUDES= if test "$with_python" != "no" ; then -- 1.6.6

2 1

[libvirt] fix build failure with --disable-shared
by Jim Meyering 08 Jan '10

08 Jan '10

Laine Stump noticed a failure to build with --disable-shared and found that removing the unconditional "-shared" option in python/Makefile.am would fix it. The change below reverts 8838ee39ab1c2bb7fffe93bfda220692664e8be6, so Diego, if your goal (with the reverted change) was more than to avoid seemingly-unnecessary work, please tell us what it was. >From 1de9c4a9a4175c9f1eb9302ad7fa9867e8a242a4 Mon Sep 17 00:00:00 2001 From: Laine Stump <laine(a)laine.org> Date: Thu, 7 Jan 2010 21:07:42 +0100 Subject: [PATCH] let "configure --disable-shared" work once again Without this change, ./autogen.sh --disable-shared && make would evoke a "can not build a shared library" failure for libvirtmod.la. * python/Makefile.am (libvirtmod_la_LDFLAGS): Do not use -shared. --- python/Makefile.am | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/python/Makefile.am b/python/Makefile.am index 58c6729..04342b7 100644 --- a/python/Makefile.am +++ b/python/Makefile.am @@ -39,7 +39,7 @@ libvirtmod_la_SOURCES = libvirt-override.c typewrappers.c libvirt.c libvirt.h # need extra flags here libvirtmod_la_CFLAGS = @WARN_PYTHON_CFLAGS@ -libvirtmod_la_LDFLAGS = -module -avoid-version -shared -L$(top_builddir)/src/.libs \ +libvirtmod_la_LDFLAGS = -module -avoid-version -L$(top_builddir)/src/.libs \ @CYGWIN_EXTRA_LDFLAGS@ libvirtmod_la_LIBADD = $(mylibs) \ @CYGWIN_EXTRA_LIBADD@ @CYGWIN_EXTRA_PYTHON_LIBADD@ -- 1.6.6.425.g4dc2d

4 12

[libvirt] [PATCH] Qemu: ask for memory preallocation with large pages
by Daniel Veillard 08 Jan '10

08 Jan '10

The -mem-prealloc flag should be used when using large pages This ensures qemu tries to allocate all required memory immediately, rather than when first used. The latter mode will crash qemu if hugepages aren't available when accessed, while the former should gracefully fallback to non-hugepages. * src/qemu/qemu_conf.c: add -mem-prealloc flag to qemu command line when using large pages Daniel diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index 824055f..d3da776 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -2108,6 +2108,7 @@ int qemudBuildCommandLine(virConnectPtr conn, def->emulator); goto error; } + ADD_ARG_LIT("-mem-prealloc"); ADD_ARG_LIT("-mem-path"); ADD_ARG_LIT(driver->hugepage_path); } -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

2 2

[libvirt] DNAT, bridge, iptables and network
by Mihamina Rakotomandimby 08 Jan '10

08 Jan '10

Manao ahoana, Hello, Bonjour, My server has 3 public IPs: IP1, IP2, IP3. I intend to create 3 bridges: virbr1, virbr2, virbr3. Each bridge will NAT from 3 to 5 KVM guests. About IP1: I would like incoming connexion on IP1 to: - IP1:80 to be DNAT'd to one virbr1 VM, specialized on HTTP - IP1:3306 to be DNAT'd to another virbr1 VM, specialized on MySQL - IP1:53 to be DNAT'd to another virbr1 VM, specialized on DNS Same about IP2 and IP3. Should I assign a public IP address to each brdige? I think "no" because there will be a problem of network segment: --> What range will I give to the guests? I think my only solution is to give private IPs (192.168.X.X) to the brigdes (3 separate subnets), and use iptables with something like: iptables -t nat -A PREROUTING -p tcp -m tcp -d $IP1 --dport 80 \ -j DNAT --to-destination $VIRBR1_HTTP_GUEST iptables -t nat -A PREROUTING -p tcp -m tcp -d $IP1 --dport 3306 \ -j DNAT --to-destination $VIRBR1_MySQL_GUEST iptables -t nat -A PREROUTING -p udp -d $IP1 --dport 53 \ -j DNAT --to-destination $VIRBR1_DNS_GUEST Should be alright? More informations: I use Ubuntu 9.10 Misaotra, Thanks, Merci. -- Architecte Informatique chez Blueline/Gulfsat: Administration Systeme, Recherche & Developpement +261 34 29 155 34 / +261 33 11 207 36

1 0

[libvirt] [Patch v0.5] iSCSI Multi-IQN (Libvirt Support)
by Shyam Iyer 08 Jan '10

08 Jan '10

This patch set realizes the multi-IQN concept discussed in an earlier thread http://www.mail-archive.com/libvir-list@redhat.com/msg16706.html And here .. http://www.mail-archive.com/libvir-list@redhat.com/msg17499.html The patch realizes an XML schema like the one below and allows libvirt to read through it to create storage pools. These XMLs when created using a virtualization manager realize unique VM to storage LUN mappings through a single console and thus opening up possibilities for the following scenarios - * possibility of multiple IQNs for a single Guest * option for hypervisor's initiator to use these IQNs on behalf of the guest Change Log from v0.4: 1) Set default tab space to 4(Hopefully this is corrected this time ;) ) 2) Review comments from Dave Allan a) Use output of "iscsiadm -m iface" to search for existing iqn names in the iface files. 3) Create new unique iface file names for user provided iqn names if the iqns are not present in the existing iface files. Change Log from v0.3: 1) Set default tab space to 4 2) Use Case Description for Commit Log 3) Review comments from Dave Allan a) No initiator iqn in the xml would mean use of the default initiator iqn name b) Initiator iqn provided would mean a unique session to be created using the provided iqn name. c) Single iSCSI session per pool 4) Added syntax in doc/schemas/storagepool.rng There are no new errors introduced by this patch with "make check" and "make syntax-check" tests. Signed-off-by: Sudhir Bellad <sudhir_bellad(a)dell.com> Signed-off-by: Shyam Iyer <shyam_iyer(a)dell.com>

2 1