Claudio Bley | 18 Dec 22:31 2014
Picon

[libvirt] [PATCH] docs: split typedef and struct definition for apibuild.py

The members of struct virSecurityLabel[1] and struct
virSecurityModel[2] were not shown in the libvirt API docs because the
corresponding <field> elements were missing from the libvirt-api.xml.

The reason is that apibuild.py does not cope well with typedef's using
inline struct definitions. It fails to associate any info about the
struct with the typedef and consequently cannot write out the members
of the struct.

Splitting the typedef and the struct definition into seperate
statements as it is done for other structs works around this problem.

[1]: http://libvirt.org/html/libvirt-libvirt-host.html#virSecurityLabel
[2]: http://libvirt.org/html/libvirt-libvirt-host.html#virSecurityModel
---
Seems I had to run "make" twice inside the docs folder before the changes
were picked up.

Besides, my email address has changed. If this this patch gets ACKed,
I'd also adjust the AUTHORS file in a separate trivial patch.

include/libvirt/libvirt-host.h | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/include/libvirt/libvirt-host.h b/include/libvirt/libvirt-host.h
index 53b529f..0704672 100644
--- a/include/libvirt/libvirt-host.h
+++ b/include/libvirt/libvirt-host.h
 <at>  <at>  -108,12 +108,13  <at>  <at>  typedef virStream *virStreamPtr;
  * a virSecurityLabel is a structure filled by virDomainGetSecurityLabel(),
(Continue reading)

Daniel P. Berrange | 18 Dec 17:35 2014
Picon

[libvirt] [PATCH] disable vCPU pinning with TCG mode

Although QMP returns info about vCPU threads in TCG mode, the
data it returns is mostly lies. Only the first vCPU has a valid
thread_id returned. The thread_id given for the other vCPUs is
in fact the main emulator thread. All vCPUs actually run under
the same thread in TCG mode.

Our vCPU pinning code is not at all able to cope with this
so if you try to set CPU affinity per-vCPU you end up with
wierd errors

error: Failed to start domain instance-00000007
error: cannot set CPU affinity on process 24365: Invalid argument

Since few people will care about the performance of TCG with
strict CPU pinning, lets just disable that for now, so we get
a clear error message

error: Failed to start domain instance-00000007
error: Requested operation is not valid: cpu affinity is not supported
---
 src/qemu/qemu_process.c | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index b067f18..e2ccc4e 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
 <at>  <at>  -2231,6 +2231,40  <at>  <at>  qemuProcessDetectVcpuPIDs(virQEMUDriverPtr driver,
     int ncpupids;
     qemuDomainObjPrivatePtr priv = vm->privateData;
(Continue reading)

Daniel P. Berrange | 18 Dec 17:35 2014
Picon

[libvirt] [PATCH] Don't setup fake CPU pids for old QEMU

The code assumes that def->vcpus == nvcpupids, so when we setup
fake CPU pids for old QEMU with nvcpupids == 1, we cause the
later code to read off the end of the array. This has fun results
like sche_setaffinity(0, ...) which changes libvirtd's own CPU
affinity, or even better sched_setaffinity($RANDOM, ...) which
changes the affinity of a random OS process.
---
 src/qemu/qemu_process.c | 9 ++++-----
 src/util/virprocess.c   | 1 +
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index d683918..b067f18 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
 <at>  <at>  -2240,10 +2240,8  <at>  <at>  qemuProcessDetectVcpuPIDs(virQEMUDriverPtr driver,
         qemuDomainObjExitMonitor(driver, vm);
         virResetLastError();

-        priv->nvcpupids = 1;
-        if (VIR_ALLOC_N(priv->vcpupids, priv->nvcpupids) < 0)
-            return -1;
-        priv->vcpupids[0] = vm->pid;
+        priv->nvcpupids = 0;
+        priv->vcpupids = NULL;
         return 0;
     }
     qemuDomainObjExitMonitor(driver, vm);
 <at>  <at>  -2462,7 +2460,8  <at>  <at>  qemuProcessSetVcpuAffinities(virDomainObjPtr vm)
     virDomainVcpuPinDefPtr pininfo;
(Continue reading)

Ján Tomko | 18 Dec 13:04 2014
Picon

[libvirt] [PATCH 0/2] Fix disk hotplug refactoring fallout

https://bugzilla.redhat.com/show_bug.cgi?id=1175668

Ján Tomko (2):
  Fix hotplugging of block device-backed usb disks
  Remove redundant cleanup in qemuDomainAttachVirtioDiskDevice

 src/qemu/qemu_hotplug.c | 26 ++------------------------
 1 file changed, 2 insertions(+), 24 deletions(-)

--

-- 
2.0.4

--
libvir-list mailing list
libvir-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Michal Privoznik | 18 Dec 12:46 2014
Picon

[libvirt] [PATCH] qemu: Create memory-backend-{ram, file} iff needed

Libvirt BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1175397
QEMU BZ:    https://bugzilla.redhat.com/show_bug.cgi?id=1170093

In qemu there are two interesting arguments:

1) -numa to create a guest NUMA node
2) -object memory-backend-{ram,file} to tell qemu which memory
region on which host's NUMA node it should allocate the guest
memory from.

Combining these two together we can instruct qemu to create a
guest NUMA node that is tied to a host NUMA node. And it works
just fine. However, depending on machine type used, there might
be some issued during migration when OVMF is enabled (see QEMU
BZ). While this truly is a QEMU bug, we can help avoiding it. The
problem lies within the memory backend objects somewhere. Having
said that, fix on our side consists on putting those objects on
the command line if and only if needed. For instance, while
previously we would construct this (in all ways correct) command
line:

    -object memory-backend-ram,size=256M,id=ram-node0 \
    -numa node,nodeid=0,cpus=0,memdev=ram-node0

now we create just:

    -numa node,nodeid=0,cpus=0,mem=256

because the backend object is obviously not tied to any specific
host NUMA node.
(Continue reading)

Chunyan Liu | 18 Dec 10:14 2014

[libvirt] [PATCH 0/2] fix xen HVM pae|apic|acpi features parser

According to xm.config manual, HVM pae|apic|acpi feature default
is 1 (enabled). But in conversion from xm config to libvirt xml,
if xm config doesn't contain pae|apic|acpi, it sets default value
to 0, this causes some problems in HVM guest.

Update parser codes to set HVM pae|apic|acpi default value to 1
to match xm config convension.

Add tests data to test it.

Chunyan Liu (2):
  xenconfig: set HVM pae/apic/acpi/ default to 1
  Add tests to xmconfigtest

 src/xenconfig/xen_common.c                         |  6 +--
 .../xmconfigdata/test-fullvirt-default-feature.cfg | 23 +++++++++++
 .../test-fullvirt-default-feature.cfg.out          | 26 ++++++++++++
 .../xmconfigdata/test-fullvirt-default-feature.xml | 48 ++++++++++++++++++++++
 tests/xmconfigtest.c                               |  9 +++-
 5 files changed, 108 insertions(+), 4 deletions(-)
 create mode 100644 tests/xmconfigdata/test-fullvirt-default-feature.cfg
 create mode 100644 tests/xmconfigdata/test-fullvirt-default-feature.cfg.out
 create mode 100644 tests/xmconfigdata/test-fullvirt-default-feature.xml

--

-- 
1.8.4.5

Eric Blake | 18 Dec 00:18 2014
Picon

[libvirt] [PATCH] qemu: fix memory leak in blockinfo

Coverity flagged commit 0282ca45 as introducing a memory leak;
in all my refactoring to make capacity probing conditional on
whether the image is non-raw, I missed deleting the unconditional
probe.

* src/qemu/qemu_driver.c (qemuStorageLimitsRefresh): Drop
redundant assignment.

Signed-off-by: Eric Blake <eblake <at> redhat.com>
---

Pushing as a trivial fix.

 src/qemu/qemu_driver.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 89578e1..ebbb656 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
 <at>  <at>  -11116,9 +11116,6  <at>  <at>  qemuStorageLimitsRefresh(virQEMUDriverPtr driver,
                                                        buf, len)) < 0)
             goto cleanup;
     }
-    if (!(meta = virStorageFileGetMetadataFromBuf(src->path, buf, len,
-                                                  format, NULL)))
-        goto cleanup;
     if (format == VIR_STORAGE_FILE_RAW)
         src->capacity = src->physical;
     else if ((meta = virStorageFileGetMetadataFromBuf(src->path, buf,
(Continue reading)

Boris Fiuczynski | 17 Dec 16:47 2014
Picon

[libvirt] [PATCH v2] Buffer size too small when reading sysinfo

On a system with 160 CPUs the /proc/cpuinfo size grows beyond
the currently set limit of 10KB causing an internal error.

This patch increases the buffer size to 1MB.

Signed-off-by: Boris Fiuczynski <fiuczy <at> linux.vnet.ibm.com>
---
 src/util/virsysinfo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/util/virsysinfo.c b/src/util/virsysinfo.c
index 1bb6392..789c3bc 100644
--- a/src/util/virsysinfo.c
+++ b/src/util/virsysinfo.c
 <at>  <at>  -50,7 +50,7  <at>  <at>  static const char *sysinfoCpuinfo = "/proc/cpuinfo";
 #define SYSINFO_SMBIOS_DECODER sysinfoDmidecode
 #define SYSINFO sysinfoSysinfo
 #define CPUINFO sysinfoCpuinfo
-#define CPUINFO_FILE_LEN (10*1024)	/* 10KB limit for /proc/cpuinfo file */
+#define CPUINFO_FILE_LEN (1024*1024)	/* 1MB limit for /proc/cpuinfo file */

 /* only to be used test programs, therefore not in sysinfo.h */
 extern void virSysinfoSetup(const char *dmidecode, const char *sysinfo,
--

-- 
1.9.3

Lin Ma | 17 Dec 11:34 2014

[libvirt] [PATCH] virsh: add transient interfaces check for iface-unbridge

iface-unbridge(netcf interface backend) checks multiple interfaces
attaching based on static configuration.
If guests interfaces(says tun/tap devices) are attaching to the bridge,
iface-unbridge doesn't check them, It causes the bridge is removed
although it's in use by other guests.

Please refer to:
https://bugzilla.suse.com/show_bug.cgi?id=813117

Signed-off-by: Lin Ma <lma <at> suse.com>
---
 tools/virsh-interface.c | 24 +++++++++++++++++++++---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/tools/virsh-interface.c b/tools/virsh-interface.c
index 5f848b6..63ba5bb 100644
--- a/tools/virsh-interface.c
+++ b/tools/virsh-interface.c
 <at>  <at>  -1040,11 +1040,11  <at>  <at>  cmdInterfaceUnbridge(vshControl *ctl, const vshCmd *cmd)
     const char *br_name;
     char *if_type = NULL, *if_name = NULL;
     bool nostart = false;
-    char *br_xml = NULL;
+    char *br_xml = NULL, *br_xml_transient_if = NULL;
     xmlChar *if_xml = NULL;
     int if_xml_size;
-    xmlDocPtr xml_doc = NULL;
-    xmlXPathContextPtr ctxt = NULL;
+    xmlDocPtr xml_doc = NULL, xml_doc_transient_if = NULL;
+    xmlXPathContextPtr ctxt = NULL, ctxt_transient_if = NULL;
(Continue reading)

Chunyan Liu | 17 Dec 09:48 2014

[libvirt] [PATCH V3 0/5] support sending sysrq key

xend/libxl support sending sysrq key to guest kernel but not support
sending any key sequence as virDomainSendKey is expected to do. To
add equivalant sysrq functionality in libvirt for xen/libxl, add a new
virDomainSendSysrq API and add related codes to virsh, remote driver,
xen/libxl driver.

Changes to V2:
  * change parameter from 'const char *key' to 'char key'.
  * add 'flags' parameter to virDomainSendSysrq API.
  * update codes to fit for above changes.

  V2 is here:
  http://www.mail-archive.com/libvir-list <at> redhat.com/msg106106.html

Chunyan Liu (5):
  Add public API virDomainSendSysrq
  implement remote protocol for domainSendSysrq
  virsh: add 'sysrq' command
  libxl: implement .domainSendSysrq method
  xen: add .domainSendSysrq method

 include/libvirt/libvirt-domain.h |  3 +++
 src/driver-hypervisor.h          |  4 +++
 src/libvirt-domain.c             | 39 +++++++++++++++++++++++++++++
 src/libvirt_public.syms          |  5 ++++
 src/libxl/libxl_driver.c         | 25 +++++++++++++++++++
 src/remote/remote_driver.c       |  1 +
 src/remote/remote_protocol.x     | 14 ++++++++++-
 src/remote_protocol-structs      |  6 +++++
 src/rpc/gendispatch.pl           | 12 +++++++++
(Continue reading)

Nehal J Wani | 17 Dec 01:16 2014
Picon

[libvirt] [PATCHv7 0/4] Introduce API to query IP addresses for given domain

This feature has been requested for a very long time. Since qemu guest
agent gives us reliable results, now the wait is over.

The RFC was first proposed by Michal Privoznik:
     http://www.redhat.com/archives/libvir-list/2012-February/msg00437.html
A patch was submitted, using structs:
     https://www.redhat.com/archives/libvir-list/2012-June/msg00220.html
Another patch was submitted, using XML:
     https://www.redhat.com/archives/libvir-list/2012-June/msg00904.html

Neither of the patches were accepted, probably due to lack of extensibility
and usability. Hence, we thought of using virTypedParameters for reporting
list of interfaces along with their MAC address and IP addresses. The RFC
can be found here:
     https://www.redhat.com/archives/libvir-list/2013-July/msg00084.html

The idea of extensibility was rejected and rendered out of scope of
libvirt. Hence, we were back to structs.

This API is called virDomainInterfaceAddresses which returns a dynamically
allocated array of virDomainInterface struct. The great disadvantage is
once this gets released, it's written in stone and we cannot change
or add an item into it.

The virsh CLI supports two methods:

* Return information (list of all associated interfaces with MAC address
     and IP addresses) of all of the domain interfaces by default (if
     no interface name is provided)

(Continue reading)


Gmane